Reference
Medium
Restaurant Admin (Owner) · Manager
Updated September 2026
Roles and permissions
What each role can do by default — owner, manager, cashier, waiter, kitchen — and how permissions layer on top.
The roles
| Role | Built for | Can access (default) |
|---|---|---|
| Owner | The restaurant admin | Everything: dashboard, orders, kitchen, tables, menu, inventory, billing, feedback, marketing, staff, printers, settings |
| Manager | Running the floor and back office | Menu (incl. edit/86/import), tables, orders (accept/void), kitchen display, billing (discount/close), inventory, staff (floor roles), reports, marketing — but not Settings |
| Cashier | The till | Menu view + 86, tables, orders (accept), billing (discount/close), inventory view, own-shift reports; lives in the POS |
| Waiter | The floor | Menu view, tables, orders (create/accept/serve) |
| Kitchen | The pass | Menu view, kitchen display; lands on the KDS at sign-in |
The platform operator (RestoQR staff) is a separate account type that manages restaurants themselves — restaurant staff never hold it.
How permissions layer
Every account's effective access is: role defaults, plus individual grants, minus individual denies. That is why one cashier can be allowed inventory-manage while another cannot. The same set is enforced by the server on every request — hiding a menu item is cosmetic; the API is the wall.
Plan is a different door
A role decides what a *person* can do; the plan decides what the *restaurant* has subscribed to. A module outside the plan says so explicitly — see Module not in plan.
Was this helpful?