Roles & campus permissions

PrepTable ships with a three-role model. Every user belongs to exactly one role, and managers (and only managers) carry an additional campus assignment that scopes their access. This page explains what each role can do and how to grant campus scope correctly.

The three roles

Staff

Back-of-house workers. Can do operational reads freely and a narrow set of operational writes: marking an item unavailable on today's menu (after manager approval is logged), recording waste, updating count adjustments they've been authorized for.

Staff are not campus-scoped in this version. Every campus sees the same staff reach; the practical effect is small because staff mostly interact with the kitchen display, which is implicitly campus-scoped by whichever kitchen display they sign in to.

Manager

Campus-scoped supervisors. Can write to operational data — dayparts, placements, par levels, store-level inventory, waste, purchase orders — only for the campuses they're assigned to. Can also write to the global catalog (items, recipes, vendors) because catalog data is shared across all campuses.

A manager assigned to Harlingen and Waco sees both campuses in the campus switcher and can edit either. A manager assigned to only Harlingen sees only Harlingen in the switcher and is denied operations on Waco (the API returns a 403, the UI hides Waco data).

Admin

Application administrator. Can do everything, everywhere. The only role that can:

• Manage users (invite, demote, revoke passkeys)
• Assign campuses to managers (or revoke)
• Configure locations / campuses
• Configure API integrations and kiosk tokens
• Read the audit log

Admins are intentionally rare — typically one or two per customer. Last-admin protection is enforced: the system refuses to demote the only remaining active admin.

How campus scoping works

Campus scoping lives in a user_locations join table:

users        user_locations        locations
─────        ─────────────         ──────────
id           user_id               id
role ←─────  location_id ←──────   name
             role_at_location      code

A user with role = 'manager' and two rows in user_locations manages two campuses. Admins don't need user_locations entries; their scope is implicit and global.

The API enforces campus scope on every operational write (requireManagerOfLocation). Reads are also gated: a manager who queries another campus's inventory gets an empty list, not an error, so the UI surfaces "you don't have access here" cleanly.

Granting campus scope to a manager

1. Invitations are sent from Users → Invite user, with role chosen at invitation time.
2. After the invitee registers their passkey, an admin opens the new user's detail and clicks Assign campuses.
3. Tick the campuses this manager will own. Save.

The change is effective immediately — the manager's next page reload will see the updated campus switcher. The change is logged in the audit log.

Common setups

• Single-campus customer: there's typically one admin and one or two managers (often the dining-services director and an assistant).
• Small chain (2–4 campuses): one admin per location group, plus a "portfolio" admin who manages all of them. Campus-scoped managers under each.
• Large multi-site operator (5+ campuses): a directory-style admin team, plus a designated "lead admin" who holds the last-admin role. Campuses are managed by their local dining-services team with manager access scoped to their location only.

Edge cases the system handles for you

• Last admin: the system refuses to demote the only active admin. Promote a replacement first.
• Last passkey per user: the system refuses to remove a user's only passkey. Register a second passkey first.
• Last credential globally: the API bootstraps a kiosk service account and a first admin via a one-time invitation; neither can be removed while they're the only ones.
• Manager demoted to staff: their campus scope is automatically cleared. Their data (purchase orders they've drafted, for example) remains attributed to them in the audit log.

What this looks like in the audit log

Every role change and campus-scope change is logged with the old state, the new state, the acting admin, and the timestamp. If a manager suddenly has access to a campus they shouldn't, you can find both the grant and the revoke in the log.

Where to go next

• The audit log — what gets recorded, how to read it
• Train-the-trainer guide — facilitator notes for rolling this out to a campus team