Role-Based Permissions for Restaurants: Who Sees What

Why role-based permissions in a restaurant are about order, not just security

Role-based permissions in a restaurant mean every team member sees only the screens their job needs and can perform only the actions their job calls for. Waiters handle tables and orders, cashiers handle payment, and managers handle the menu, pricing and reports. On paper the split is obvious. In practice, in a small restaurant everyone ends up on the same tablet, with the same login, looking at the same screen, because in the middle of a rush saying "can you open that check for me" is faster than setting up access.

The cost of that speed is invisible, because nobody questions permissions during service. But when the till is off at month end, when someone asks why a comp was given, or when a price turns out to have been changed and nobody knows by whom, the answer "we all used the same account" closes none of those questions. Permissions are not set up to blame anyone. They exist so that the answers to these questions are known before anyone has to ask.

What goes wrong when there are no permission boundaries

None of the situations below requires bad intent. Most are ordinary accidents caused by the lack of a boundary:

• A price change made by the wrong person. A waiter who wants to update one item's price edits the wrong line, and nobody notices until the first guest check closes.
• Comps with no clear owner. If comps and discounts are open to everyone, you can no longer tell which ones were genuine guest-satisfaction gestures and which ones were used to cover a register mistake.
• Unnecessary data visibility. If revenue, per-item profitability and staff performance sit on every screen, that creates friction inside the team.
• Access that stays open after someone leaves. With a shared account, closing that gap means resetting everyone's password.

We covered the same logic on the residential side in role-based permissions for community management. In a restaurant, actions happen faster and in a more crowded setting, so the simpler the model, the less it slows service.

Waiter, cashier and manager: who sees what

Restaurants already run on three layers. When the permission model carries that natural split into the system, it is easy to learn and easy to defend.

Waiter: tables and orders

A waiter's job is the tables in their own section. They take orders and move them along, answer waiter calls, move tables and open checks. None of that requires editing menu prices, opening the stock page or seeing the day's revenue. The narrower the waiter's screen, the lower the chance of tapping the wrong thing mid-service.

Cashier: payment and closing the check

The cashier carries everything the waiter can do plus payment authority: splitting the check, taking cash and card payments, printing receipts and closing the check. Comps and discounts also live at this layer, as permission-gated actions. We covered the mechanics of splitting in splitting the check methods for restaurants; what matters here is that these actions run from the cashier role, not from a waiter account. Every moment money changes hands is tied to a single role.

Manager: menu, rules and reports

The manager runs the menu, price rules, floor plan, stock and recipes, invites staff and assigns roles, and sees all reports, the audit log and settings. In other words, everything that changes the structure sits in this role. How many people hold it should be a deliberate decision: the fewer people with the manager role, the easier it is to trace the source of any change.

| Role | Sees / does | Does not need | | --- | --- | --- | | Waiter | Tables in their section, orders, waiter calls | Price editing, stock, revenue reports | | Cashier | Payment, check splitting, comps and discounts, receipts | Menu structure, staff roles | | Manager | Menu, stock, reports, audit log, staff | Platform-level settings |

Why comp and discount authority deserves separate thought

When people talk about permissions in a restaurant, comps and discounts come up first, because they are the one action that is worth money, instant and hard to undo. A good model limits them in two ways. First, only authorised roles can do them. Second, every comp and discount leaves a record.

In App-Rest, line comps and check discounts apply as an amount or a percentage, only authorised roles can grant them, and the action is refused if any share of the check has already been paid. Each one lands in the audit log. The benefit is that answering "who gave this comp?" does not mean interrogating anyone; the record is already there. We wrote separately about why an audit trail matters in why audit logs matter. Permissions narrow down who could have done something, and the audit log answers who did. Without both working together, one of the two questions stays open.

The order to set roles up in

For a restaurant building its permission model from scratch, a practical sequence looks like this:

1. Write down roles before people. Start with "what should a waiter see" rather than "what should Ahmet see". When the person changes, the role stays.
2. Keep the manager count to a minimum. Give the authority to change structure only to people who genuinely need it.
3. Give every team member their own login. A shared account removes the precondition for both permissions and auditing. Team members join with an invite code and their roles are assigned or revoked in the panel, so there is no shared password to change when someone starts or leaves.
4. Think about section responsibility alongside the role. A waiter receives only the orders and calls from their own section. The role defines what they can do, and the section defines where they do it.
5. Define branch boundaries explicitly. In multi-branch businesses, making sure staff reach only their own branch is the least discussed and most important part of a permission model.

Why privilege escalation must be blocked in the data layer

Hiding a button is not a permission; it only makes the button invisible. Real permissions work when the rule is enforced in the data layer rather than at the screen level. In App-Rest each role sees only its own screens and actions, and because privilege escalation is blocked in the data layer, a staff member cannot change their own role or reach another branch.

For an owner, this means that not seeing a menu on screen and being unable to perform the action behind it are not the same thing, and the second is the one you should rely on. Someone who edits an address by hand to reach a page they should not have, and someone who taps the wrong button by accident, run into the same rule.

Permissions, cash close and small teams

Permissions are the ground other routines stand on. At end-of-day cash close, who counted and who approved is tied to roles, as we described in restaurant end-of-day cash reconciliation. The model also needs a periodic look: when seasonal staff join, a new branch opens, or a cashier becomes a manager, roles should be updated. Reviewing who holds the manager role every quarter is enough for most venues.

With a team of three, this much separation can feel excessive. But permissions are a habit that gets harder to correct as the business grows. A restaurant that starts with a waiter, cashier and manager split does not rebuild the system when it opens a second branch.

If you would like to see how roles and teams can be set up in App-Rest, turn your current routine into a permission matrix, or discuss a setup for your branch count, you can look at the App-Rest product page and then get in touch with us.