Roles & what they can do
The seven staff roles, the guest credential types and the five platform roles — exactly who can do what, on which screen, and what denial looks like.
Everything you may do in DineGlobe follows from three separate kinds of authority: staff roles inside an organization, guest credentials that unlock exactly one thing each, and platform roles for the people operating the service itself. Authority is always decided server-side, against live membership rows, at the moment of every request — a URL, a cookie or a request parameter never grants it.
The seven staff roles
| Role | Scope | In one line |
|---|---|---|
| OWNER | Org-wide | The organization’s owner: every permission, plus ownership itself. |
| ORG_ADMIN | Org-wide | The same permissions as OWNER, but cannot hold or receive ownership. |
| MANAGER | Per venue | Runs a venue: bookings, request decisions, the floor, privacy cases, imports and exports. |
| HOST | Per venue | Takes bookings and runs the floor at the door. |
| DOOR | Per venue | Records arrivals and sees a contact-free view of the day; nothing else. |
| FINANCE | Per venue | Money views and the refund workflow. |
| READ_ONLY | Per venue | Sees bookings and reports; changes nothing. |
Only OWNER and ORG_ADMIN may sit on org-wide memberships. The other five roles exist only as venue-scoped rows, and one user may hold rows on several venues. Authority is recomputed for the exact requested scope on every request — a session never carries venue authority with it.
The OWNER/ORG_ADMIN difference is ownership, not permissions: only an OWNER can hold or receive ownership, transfers are a deliberate owner-to-member act that demotes the transferring owner to ORG_ADMIN, and the last active owner cannot be removed or demoted by anyone until ownership moves.
The permission matrix
There are 21 registered permissions; anything not registered is denied to everyone, owners included. The matrix below is pinned by the release suite — if the live registry ever drifts from it, the release fails — so this table is enforced, not descriptive.
| Permission | OWNER | ORG_ADMIN | MANAGER | HOST | DOOR | FINANCE | READ_ONLY |
|---|---|---|---|---|---|---|---|
venues.manage |
✓ | ✓ | ✓ | – | – | – | – |
staff.manage |
✓ | ✓ | ✓¹ | – | – | – | – |
reservations.read |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
reservations.write |
✓ | ✓ | ✓ | ✓ | – | – | – |
reservations.approve |
✓ | ✓ | ✓ | – | – | – | – |
checkin.record |
✓ | ✓ | ✓ | ✓ | ✓ | – | – |
checkin.correct |
✓ | ✓ | ✓ | – | – | – | – |
visits.manage |
✓ | ✓ | ✓ | ✓ | – | – | – |
waitlist.manage |
✓ | ✓ | ✓ | ✓ | – | – | – |
payments.account.connect |
✓ | ✓ | – | – | – | – | – |
billing.manage |
✓ | ✓ | – | – | – | – | – |
billing.read |
✓ | ✓ | – | – | – | – | – |
payments.refund.execute |
✓ | ✓ | ✓ | – | – | ✓ | – |
payments.refund.approve |
✓ | ✓ | – | – | – | – | – |
exports.download |
✓ | ✓ | ✓ | – | – | ✓ | – |
audit.read |
✓ | ✓ | – | – | – | – | – |
privacy.case.process |
✓ | ✓ | ✓ | – | – | – | – |
data.import |
✓ | ✓ | ✓ | – | – | – | – |
data.export |
✓ | ✓ | ✓ | – | – | – | – |
reporting.read |
✓ | ✓ | ✓ | – | – | ✓ | ✓ |
reporting.serviceSheet |
✓ | ✓ | ✓ | ✓² | – | – | – |
¹ A manager holds staff.manage but may only grant HOST, DOOR and READ_ONLY in their own venue. ² A host’s service-sheet right is bound to the current business date, checked when the export is created and again at download.
Two honest gaps: exports.download and audit.read are registered and granted in the matrix, but no command consumes them in the current version yet — artifact downloads re-authorize reporting.* or data.export instead. Don’t expect a screen for them.
Who can grant what
- Granting OWNER anywhere is refused outright (403). Ownership moves only through the transfer flow.
- Org-wide grants require the actor to hold an org-wide OWNER or ORG_ADMIN row themselves.
- Venue grants re-check
staff.managefor that exact venue; a manager may then grant only HOST, DOOR and READ_ONLY — never another MANAGER, FINANCE, ORG_ADMIN or OWNER. - Re-granting the same scope replaces the single membership row rather than duplicating it, and a role change takes effect on the affected user’s next request.
What denial looks like
- A venue outside your organization, or where you hold no membership, reads exactly like a missing page: 404 (
NOT_FOUND). Existence is never revealed. - A role gap inside your own scope: 403
PERMISSION_DENIED. - An unauthenticated console visit redirects to /app/login; a dead session on a handler surface is a generic 401
UNAUTHENTICATED. - A consumed, expired, replaced or unknown guest link always answers the same way: “This link is no longer valid — request a fresh one by email.” (
TOKEN_INVALID) — no hint which of the four it was. - Platform commands without a platform role: 403. With a role but a session without verified two-step: 401
MFA_REQUIRED.
Guest credentials (four kinds, none of them staff accounts)
| Credential | Lifetime | What it unlocks |
|---|---|---|
| Booking-management link token | 24 hours, carried in the /b#… link fragment |
Nothing by itself. A one-time exchange starts a capability session. Reissuing the link invalidates every earlier link and session. |
| Guest capability session | 60 minutes, scoped to one reservation | View that booking, reconfirm it, cancel it under the accepted policy, download the calendar file. Never a staff session — guest actors are refused on every staff command. |
| Waitlist queue token | Until venue-local midnight after the business day | A one-time exchange into a 60-minute session scoped to one queue entry: accept a table offer or withdraw. |
| Check-in pass | One live pass per booking; reissuing rotates it | Authorizes nothing on its own. Every scan still needs staff holding checkin.record, inside the window from 60 minutes before the booked start to the planned end. |
The booking and waitlist credentials reject each other’s secrets with the same generic denial, and the check-in pass is invisible to both exchanges.
Platform roles (a separate axis)
Platform authority is never inferred from a staff membership. Every platform command requires an active platform role, a live session with verified two-step authentication, and a written reason; every use is audited. There is no impersonation surface — the platform module mints nothing on anyone’s behalf.
| Role | Powers |
|---|---|
| SUPPORT | The support-case workflow: open, escalate, resolve, list, inspect. Inspect shows a safe view — case metadata and venue-level counts, zero guest personal data. |
| TRUST_OPERATOR | Publication decisions (approve makes a venue PUBLISHED), country capability flags for payment and SMS (evidence mandatory, deny by default), and suspend/resume of new booking intake at a venue. |
| PRIVACY_OFFICER | Reads support cases like SUPPORT. Actual execution of venue privacy rights stays with the venue’s own privacy.case.process role. |
| PLATFORM_FINANCE | Deliberately excluded from case reading; sits in the operations-readiness reader set. |
| SECURITY | Grants, reactivates and deactivates platform roles; runs the quality, release, launch and performance suites and keeps the risk register. |
Operations-readiness surfaces — alert thresholds and backup evidence — are readable by all five roles.
Which guide should I read
- Guest guide — booking, the self-service link, cancellations.
- Host guide — bookings, arrivals, the floor.
- Door guide — arrivals and check-in only.
- Manager guide — running a venue day to day.
- Owner & org admin guide — organizations, ownership, staff.
- Finance guide — money views and refunds.
- Read-only guide — observation without change.
- Platform operator guide — the five platform roles in practice.