Owner & org admin guide

An owner holds the whole organization on one org-wide row: every venue, every permission, and the commercial contract — payment account, subscription and refund approvals. An org admin (ORG_ADMIN) holds the identical permission set; the practical difference is that only an owner can be the owner: receiving and transferring ownership is an owner-only act, and the last active owner cannot be removed by anyone.

How you become an owner

There are exactly two ways, and neither is an invitation:

1. Founding. Creating an organization makes its creator the org-wide OWNER. This is what happens when you register at /app/register and then create your organization and first venue through Add a venue (/app/venues/new) — the venue is born DRAFT (private) and stays private until its publication review is approved by a platform operator.
2. Transfer. A sitting owner transfers ownership to an existing member (below). Granting OWNER through any other path is refused everywhere as a PERMISSION_DENIED escalation attempt.

You can walk the role without an account first: the live demo Owner card (“Enter the console”) signs you in instantly as the org-wide owner of a seeded demo venue. Every demo sign-in provisions a fresh, single-entry account, replaces any current console session, and is rate-limited per network.

Your scope is the organization

OWNER and ORG_ADMIN are the only roles allowed to sit on org-wide membership rows; they can never be scoped to a single venue (the database itself enforces both shapes). Authority is still recomputed per request against your live membership row — the session never carries venue power — so demoting or removing you takes effect on your next click.

People and ownership

• Invite anyone, anywhere. Grant ORG_ADMIN, MANAGER, HOST, DOOR, FINANCE or READ_ONLY, org-wide or per venue. Re-granting the same scope replaces the row; changes land on the member’s next request.
• Last-owner rule. You cannot be removed or demoted while you are the last active owner. The system refuses with LAST_OWNER: “The last owner cannot be removed. Transfer ownership first.”
• Transfer ownership. Choose a target who is already a member. Their rows are replaced by one org-wide OWNER row and your row becomes ORG_ADMIN: “Ownership transferred; the previous owner is now an org admin.” Cross-org transfers are impossible — the target must already belong.
• Access ends when you say so. Removing a membership, revoking sessions, or a password reset (which invalidates every live session immediately) all land at once.

See Organizations, teams & invitations.

Venues and publication

Create venues, rename public addresses (the previous slug keeps redirecting permanently), upload profile media (JPEG/PNG/WebP up to 5 MB, re-encoded and stored privately), request publication when a venue is ready, and take a venue back offline. One honest cut: the venue’s descriptive prose has no in-product editor yet — profile text is seeded, not self-edited, in this release. See Venues, slugs & publication.

Everything a manager can do, you can do too

Floor plan, offerings and schedules, policy versions, request decisions, cancellations and no-shows, arrivals and corrections, the waitlist, guest notes, privacy cases, CSV import and export, reports, service sheets, reminder settings and refund requests — the manager guide (Manager guide) describes the daily work; your org-wide row carries all of it for every venue in the organization, plus the four ownership-only powers below.

Payment account (payments.account.connect)

Connect the venue’s payment account through provider-hosted onboarding: you start it, the provider’s own page collects the credentials, and DineGlobe never sees or stores them — the onboarding URL is shown once and never persisted. Then refresh capability truth to store the provider’s answer: charges and payouts on or off, the settlement currency (a mismatch with the venue currency is named), and whether paid intake is ready — “PAID INTAKE READY — a DEPOSIT policy may now be activated.” versus a plain “paid intake blocked”.

Capability is refused, never faked: country approval, the approved route and a real (non-sandbox) provider are each checked before any provider call. See Payments (pilot posture).

Subscription billing (billing.manage, billing.read)

One monthly per-venue plan with a 30-day trial and a 7-day dunning grace. You start the trial, stop renewal (the venue keeps every entitlement it paid for through the end of the period) and read the subscription state — intake open or suspended, with the reason. When billing suspends new intake, existing bookings, guest cancellation, refunds and export stay available by design. Entitlements change only through signature-verified billing events; a browser success return proves nothing. See Subscription billing.

Refund approvals and the delegation threshold (payments.refund.approve)

Refunds are two-person money by default:

• With no threshold configured (the fail-closed default), every human refund waits for your approval. The approver can never be the requester — you cannot approve your own refund, and a second attempt is refused as a conflict.
• Set a delegation threshold (in exact integer minor units) so refunds at or below it ride the requester’s own authority; above it, they still wait for you. Clearing the threshold returns to fail-closed.
• Decide — approve releases the intent for execution, decline cancels it; the decision row is immutable evidence.
• Both your decision and the requester’s request demand MFA verified within the last 30 minutes on the live session — MFA_REQUIRED: “Refunds demand fresh MFA — re-verify within the last 30 minutes.”

See Refunds.

Platform-subject privacy cases

Each venue’s manager runs that venue’s privacy workflow. When a privacy case concerns a platform-level subject rather than a venue dataset, the execution requires the ownership tier — an org-wide membership. The workflow itself (verify, execute to the lawful minimum, holds, retention) is in Privacy, retention & deletion.

Security posture of your account

Staff sessions live server-side and are revoked the moment you sign out or a password reset lands; an account holds at most 10 active sessions and the oldest falls off first. Two-step verification is a time-based authenticator code with 10 one-time recovery codes shown exactly once at enrollment. Set it up in Account & security (/app/account) — see Your account & security. One reserved permission to know about: audit.read is registered for the ownership tier but no screen consumes it in this release — it is listed as a known limit, not a working surface, in What works today & known limits.

What an owner cannot do

• Reach into another organization. Cross-tenant is a plain 404 — the same answer as a venue that does not exist.
• Approve their own refund, or approve anything while their session lacks fresh MFA.
• Skip the publication review. Even the owner cannot self-publish a venue; approval is a platform-operator act.
• Act on the platform axis. Platform roles are a separate authority that no tenant row confers — see Platform operator guide.

The pilot in one paragraph

This deployment runs an unpaid pilot: free bookings only, SMS off, and no email actually sends (jobs dead-letter visibly). Payments machinery is complete and exercised against sandbox providers, which is why the capability truth above reports honest blockers instead of green ticks. The operator’s pinned scope note applies: Single-market pilot evidence only: one approved country and its listed capabilities do not constitute global support; unlisted countries and capabilities stay disabled. The full picture is in What works today & known limits.