Team roles and permissions for Egyptian stores

Apply least-privilege access to reduce risk and operational mistakes.

Compliance and scale

The day you stop running a store alone is the day access becomes a real decision. A confirmation agent calling buyers, a packer printing labels, a part-time accountant reconciling InstaPay against the bank, a cousin who edits product photos in the evening — each one needs to get into your dashboard, and the lazy answer is to hand everybody a full admin login. That is exactly how a store ends up with five people who can issue refunds, export every customer's phone number, and change prices, when only one of them ever should. Least privilege flips the default: each person gets the narrow set of permissions their job actually requires, and nothing else.

This lesson is about controlling team access, not about hardening your own owner account — that subject, including two-factor authentication, lives in its own lesson linked at the end. Here we cover why over-granting is a quiet operational and compliance risk in an Egyptian store, how to map the permission keys Storix exposes onto the real jobs people do, and the offboarding discipline that closes the door the moment someone leaves. The aim is a team that can move fast on its own work without anyone holding power they will never use.

Why least privilege is worth the effort

Over-granted access rarely announces itself; it sits quietly until the day it costs you. Tightening it up front is cheaper than explaining a leak or a bad refund after the fact.

  • Mistake blast radius shrinks. A packer who cannot touch pricing can never accidentally publish a product at 9 EGP instead of 900. The fewer buttons a role can press, the fewer ways a tired evening shift can go wrong.
  • Money controls stay tight. Refunds, COD reconciliation, payout details, and discount creation are where cash leaks. Limit those permissions to the one or two people who own finance, so a refund is always a decision, not a reflex anyone can make.
  • Customer data stays protected. Your order list holds names, phone numbers, and governorate addresses — personal data you are responsible for under Egypt's data-protection expectations. A content editor has no business exporting the full customer database; restricting that export is basic hygiene.
  • The audit trail stays meaningful. When each person signs in as themselves with a scoped role, your activity and audit log tells you who did what. Shared logins turn that log into noise and make any future incident impossible to trace.

Map roles to the jobs people actually do

Start from the work, not from the menu. Write down each person and the one sentence that describes their job, then grant only the areas that sentence touches. A typical Egyptian store settles into a handful of profiles:

  1. Order confirmer. Sees and updates orders, reads customer contact details to make confirmation calls and WhatsApp messages, adds order tags. No access to pricing, payouts, or settings.
  2. Dispatch and shipping. Works orders and shipments, prints labels, books couriers like Bosta or ShipBlu, updates delivery status. No finance, no catalogue editing.
  3. Catalogue and content. Creates and edits products, photos, descriptions, and collections. Never sees customer data, refunds, or payout settings.
  4. Finance / accountant. Reads orders and the finance area, reconciles InstaPay and wallet against the bank, handles VAT records, may issue refunds. Often a part-timer who needs deep money access but nothing to do with publishing the storefront.
  5. Support. Reads orders and customer history to answer questions, can add notes, but cannot delete records or change money.

Resist the urge to invent a role per person. A small set of clean profiles is easier to reason about and far easier to audit than ten bespoke logins.

Grant only what the job needs

  • Invite people individually. Every team member signs in under their own identity — never a shared store@ mailbox and password passed around on WhatsApp. Shared credentials destroy accountability and cannot be revoked for one person.
  • Start narrow, widen on request. Grant the minimum the role needs on day one. It is trivial to add a permission when someone genuinely needs it, and awkward to claw one back after the fact.
  • Keep admin rare. Full administrative control — the keys to settings, finance, and team management itself — belongs to the owner and at most one deeply trusted second. Most "admin" requests are really a request for one specific permission.
  • Review quarterly. Every few months, or before a peak like Ramadan when you onboard temporary help, read down your team list and ask of each person: do they still do this job, and do they still need this access? Trim anything that has gone stale.

Close the door when someone leaves

Offboarding is where least privilege is won or lost, and it is the step busy merchants forget. A departed seasonal packer who still has a live login is a standing risk to your orders and customer data long after their last shift.

  1. Revoke on the last day, not eventually. The moment someone leaves — a quit, a let-go, or the end of a Ramadan contract — remove or disable their access that same day.
  2. Reassign before you delete. If their account owned anything, hand it over first so nothing breaks, then deactivate.
  3. Rotate any shared secret they touched. If a courier, payment, or marketing integration used a credential they knew, change it. This is also the right moment to confirm the owner account's own protections, covered in the security lesson below.
  4. Confirm it in the log. Check your audit log to verify the access is gone and note the offboarding, so a future review has a clean record.

Related lessons

This Storix Academy lesson is published as "Team roles and permissions for Egyptian stores". Every step below is written for merchants selling online in Egypt, so apply one change at a time and measure the result before moving on.