Roles and capabilities — bundles of permissions you reuse across the team

A role is a bundle of permissions, given a name like Cashier or Manager, that you assign to a person on the Members page. The role decides what they can see and do in the admin: whether the till opens for them, whether they can edit a price, whether they see staff salaries, whether they can publish a social post. Instead of choosing thirty individual permissions for every new hire, you pick one role from a dropdown and you’re done.

This is an owner page. Editing roles changes what every person assigned to that role can do, on this venue and on the till — so the system limits the editor to the Owner role by default. The kitchen, the floor, and even managers don’t usually open it. You’ll come here once during setup, then a handful of times a year when the team’s shape changes.

What it does

Every action inside the admin — open the till, edit a recipe, publish a menu, see margins, log waste, bump a kitchen ticket, assign a shift, manage billing, post on Instagram — is a named capability. There are roughly seventy of them, organised into about twenty domains: Inventory, Recipes, Suppliers, Procurement, Menus, POS, Kitchen display, Printers, Waste, Production, Settings, Staff, Billing, Data Management, Roster, Audit, AI settings, AI Photo Studio, Health, Growth, Telegram bot.

A role is a chosen subset of those capabilities, given a label. The system ships with five built-in roles you can use unchanged:

Owner — every capability. The owner sees everything, edits everything, including billing and the role definitions themselves.
Manager — day-to-day operations and staff assignment. Edit the menu, run the till, take inventory, manage the team. Cannot touch billing or redefine roles.
Shift Lead — the trusted operator on the floor. Cashier powers plus a couple of extras: force-close a shift, void a sent kitchen ticket.
Cashier — opens and closes the till, takes POS orders, processes payments, reconciles the cash drawer at end of shift. Cannot edit the menu or see margins.
Staff — front-line read access plus the ability to log waste and operate the kitchen display. The default-safe role for anyone whose job doesn’t fit another label.

You can edit any of these — rename the Cashier role to Till Operator if that’s what your team calls it, add or remove individual capabilities. The five built-ins are marked System in the list; you can change their label, description, and capability bundle, but you can’t delete them (they’re the safety nets the rest of the app falls back on). You can also create your own roles for the cases the built-ins don’t cover — Head Chef, Bookkeeper, Marketing Manager, Bar Lead. A custom role behaves exactly like a system one once assigned.

The same role definitions apply in two places: to the members who sign in to the admin app via email, and to the terminal employees who clock in at the till with a PIN. Edit the Cashier role here and every PIN cashier on this venue picks up the change immediately — no second setup.

The rule

Build roles around jobs, not around people. A Bar Lead role describes a job; Marco describes a person. If a single person needs a one-off tweak (“Marco also handles social this month”), use a personal capability override on the Members page, not a new role.

How to use it

Open Admin → Settings → Roles. The page is a master-detail layout: a left rail listing every role on the venue (system roles at the top, custom roles below, each with its key and label), and a right pane showing the selected role’s full configuration.

Editing a role

Click a role on the left rail. The right pane shows the role’s label (the human name displayed in dropdowns), its optional description (use it to explain when to assign this role — your future self will thank you), and a grid of capability toggles grouped by domain. Each toggle is a switch: on means this role grants this capability, off means it doesn’t.

Above the capability grid sits a row of preset buttons — Owner, Manager, Staff, Clear. Click Manager and the toggles snap to the manager preset bundle; useful as a starting point when you’re building a new role and want sensible defaults. Tune individual toggles afterward. When the form is dirty (you’ve changed something), Save changes lights up; click it and the new bundle takes effect across every member assigned to this role.

The capability descriptions are spelled out next to each toggle — “See items and stock”, “Add, rename, deactivate items”, “Create / edit recipes”. Read them as you toggle so you know what each switch unlocks.

Creating a new role

Click + New at the top of the left rail. A small dialog asks for a label (the display name), a key (a short slug like head_chef — used internally and stable across renames), an optional description, and an initial capability bundle to seed from (Staff, Manager, Owner, or Empty). Pick the closest preset and tune later. After creation, the new role appears in the left rail and is immediately assignable on the Members page.

Deleting a custom role

Custom roles have a Delete role button at the bottom of the detail pane (system roles don’t). The system blocks the delete if any member is currently assigned to it — reassign them first, then come back. The delete is permanent; there’s no undo.

Worked example

Anna runs Pizzeria da Anna. She’s set up her members: herself as Owner, Pim as Manager, three cashiers, two kitchen staff. The five built-in roles cover most of what she needs, but she hits two cases that don’t fit.

Case one: her brother does the books on Sundays. He needs to see the sales reports, the cash reconciliation, the supplier invoices — but absolutely nothing else. None of the built-in roles fit. She opens Settings → Roles, clicks + New. Label Bookkeeper, key bookkeeper, description “Read-only access to sales, cash, and supplier invoices. No edit rights.” She picks Empty as the initial bundle so she’s not granting things by accident. In the detail pane, she toggles on analytics.view, suppliers.view, procurement.view, audit.view, and settings.view. Save. On the Members page she adds her brother and assigns him the Bookkeeper role. He signs in on Sunday morning, sees exactly the four sections he needs, and nothing else.

Case two: she wants to differentiate her Head Chef from her line cooks. The default Staff role is what the line cooks have; her head chef needs to also edit recipes and see costs. She could grant those capabilities to her head chef personally as an override, but two more line cooks are about to be promoted to head chef positions next month, so it’s worth making it a role. + New, label Head Chef, key head_chef, seed from the Staff preset. In the detail pane she adds recipes.edit, recipes.cost, inventory.edit, inventory.adjust, and production.run. Save. On the Members page she changes her head chef’s role from Staff to Head Chef; next month she’ll do the same for the two promotions, no extra setup.

Three months later she realises the default Cashier role is a little too tight — her cashiers also need to log waste when they spot a broken plate. She doesn’t want to redefine every role; she just opens the Cashier row, toggles on waste.log, and saves. All seven of her cashiers — present and future — gain the permission instantly. No member-by-member edits.

Members — where you actually assign these roles to humans, and where you tweak permissions for one person at a time.
Audit log — every role definition change is logged with the actor and timestamp.
Telegram bot — when a member connects the platform bot, the bot’s allowed actions are intersected with the member’s role capabilities, so a Cashier-role member can never make the bot do something a Manager would normally have to do.