Nine roles, one system: who can see and do what

How role-based permissions work in practice, why a branch manager should not see another branch, and what an audit trail is actually for when something goes missing.

Illustration of a key beside a tree of permissions

The first time an owner hands a tablet to a new starter, they usually ask the same question: what can this person see?

It is the right question, and the honest answer has to be specific.

Nine roles, and what each one is for

RoleExists to
AdminOwn the account: settings, menu, staff, books, everything
Branch managerRun one branch, and see only that branch
CashierTake orders and payment, and close their own shift
WaiterWork the floor and the tables assigned to them
Kitchen staffSee what to cook and mark it done
DriverSee assigned deliveries and their addresses
AccountantRead the books and the reports, not change the menu
CustomerSee their own orders, points and addresses
Platform operatorMaintain the platform itself, never one restaurant’s day-to-day

The point is not that people are untrustworthy. It is that a screen full of things you cannot act on is a screen you learn to ignore — and a cashier who is shown your food-cost margin has been given a distraction, not a tool.

Branch scoping is enforced, not requested

The most common failure in multi-branch operations is a manager who can see the whole chain because nobody restricted the query. Telling someone “only look at your own branch” is a policy. Preventing it is a system.

A branch manager’s requests are checked against their own branch id — in the route, in the query string and in the body of what they submit. If they ask for another branch’s numbers, the answer is no, regardless of which screen they found the button on.

What the audit trail is for

Two records run alongside every action:

  • The activity log — a readable list of what staff did: this cashier voided that item, this manager approved that refund, at this time.
  • The audit trail — the underlying record of what changed, including the before and after values, the user, and the request that carried it.

Neither is interesting until the day a number is wrong. Then they are the difference between a conversation about facts and a conversation about memories. This is also why a posted accounting entry is reversed rather than edited: an editable history cannot answer questions.

The rules that make it hold

Three habits do more than any permission matrix:

  1. One person, one account. A shared “cashier1” login means every void, refund and discount belongs to nobody. If you take one thing from this article, take this one.
  2. Approval on the actions that move money. Voids, refunds and discounts above a threshold should need a manager. Not because staff steal — because a required second pair of eyes catches the honest mistakes too.
  3. Remove access the day someone leaves. Offboarding is not just returning a uniform.

What protects the account itself

Under the roles sit the ordinary defences: passwords are hashed, five failed sign-in attempts lock an account for a cooling-off period, sessions can be revoked device by device, and long-lived tokens rotate rather than living forever. Sensitive endpoints are rate-limited so a script cannot grind away at a login page.

None of that is visible on a normal day, which is exactly what you want from it.

A sensible starting configuration

For a single site: one Admin (you), one Cashier account per cashier, one Kitchen account per screen — and, if you have an accountant, an Accountant login so they stop asking you for exports.

For a chain: add a Branch manager per site, and resist the temptation to make a second Admin “for convenience.” Convenience is how a chain ends up with four people who can change prices and no way to know which one did.

Run all of this from one system

POS, kitchen, inventory, recipe costing, staff and accounting — connected, and free to start.

Create your free account

← All articles

Contact us