DineGlobeDocs

Organizations, teams & invitations

Create an organization, invite staff with the right roles, understand the manager grant ceiling, the one-owner rule and ownership transfer.

OwnerOrg adminManager

An organization is the company that owns your venues on DineGlobe. Staff belong to the organization through memberships, and every permission a person has is decided by their membership row — never by the page they visited. This page walks through creating the organization, inviting members with the right role and scope, the ceiling on what a manager may grant, transferring ownership, and the rules that protect the last owner. What each role may actually do day to day is described in Roles & what they can do.

Create your organization

You create an organization as part of adding your first venue: register an account at /app/register, sign in at /app/login, then open /app/venues/new and choose Create a new organization….

Field What it is Rules/limits
Organization name The legal or trading name of your company. 1–160 characters.

The account that creates the organization automatically becomes its org-wide OWNER. There is no separate “organizations” screen — an organization always exists together with at least one venue. The operator panels take the organization id as an input — keep it handy.

Roles and the two membership shapes

The role list is fixed: OWNER, ORG_ADMIN, MANAGER, HOST, DOOR, FINANCE, READ_ONLY. Memberships come in exactly two shapes, and the database enforces which roles may sit on which shape:

Role Where it can live What it is for
OWNER Org-wide only The company owner; the only role that can hold or receive ownership.
ORG_ADMIN Org-wide only Same powers as the owner, minus ownership itself.
MANAGER Venue-scoped only Runs one venue: setup, inventory, schedules, policies, request decisions.
HOST Venue-scoped only Books, edits and runs service on the floor.
DOOR Venue-scoped only Records arrivals and watches the floor.
FINANCE Venue-scoped only Payment views and refund requests.
READ_ONLY Venue-scoped only Read-only access for auditors or observers.

An org-wide row covers the whole organization; a venue-scoped row applies to one venue only, and one person can hold rows on several venues. You cannot mix the shapes: OWNER/ORG_ADMIN are refused on a venue-scoped row, and every other role is refused on an org-wide row.

Invite a member

Invitations are issued from the operator panels at /app/panels, form “Invite staff by email” in the Invitations (DEV-008 panel). The invitee must already have a DineGlobe account with a verified email address — the invitation attaches to that account when it is accepted.

Field What it is Rules/limits
Organization id Which organization the invite belongs to. Required.
Invitee email The account to attach the membership to. Must match a verified, non-disabled account at acceptance.
Venue id Scope of the new membership. Leave empty for an org-wide invite (only OWNER/ORG_ADMIN roles); set it for a venue-scoped invite.
Role The role granted on acceptance. Defaults to HOST.

An invitation is a one-time secret with a 7-day lifetime. The secret is stored only as a hash, is never displayed anywhere in the app, and travels to the invitee as an email link. Sending a new invitation for the same email replaces the previous pending one and restarts its 7-day clock. When the invitee opens the link and submits the secret (form “Accept an invitation”), the membership becomes active and replaces any existing membership that person held in the same scope.

During the pilot no email provider is configured, so invitation emails are composed but do not actually arrive. Coordinate the link with your platform operator out of band until a provider is connected.

If a link is reused, expired or already accepted, acceptance fails with TOKEN_INVALID — ask for a fresh invitation; nothing about the old one is recoverable.

Change or remove a member

Use “Change a member’s role” (Invitations panel) or “Assign a membership” / “Remove a membership” (Tenancy (DEV-007 panel)) with the organization id, the member’s user id and — for venue-scoped rows — the venue id. Re-assigning the same organization + user + venue scope replaces that single row; it never duplicates. Role changes take effect on the member’s next request, because DineGlobe re-reads live membership rows on every call rather than trusting a cached role.

Removing a person’s last membership revokes their access immediately. The one exception is the owner rule below.

The manager grant ceiling

MANAGER holds the staff-management permission for its venue, but the service caps what a manager may grant. Inside their own venue a manager can grant only:

  • HOST
  • DOOR
  • READ_ONLY

A manager can never mint another MANAGER, a FINANCE, an ORG_ADMIN or an OWNER. Org-wide grants (ORG_ADMIN) additionally require the actor to hold an org-wide OWNER or ORG_ADMIN row. Attempting to grant OWNER through assign or update is refused with PERMISSION_DENIED (403) in every case — ownership moves only through the transfer flow below.

Transfer ownership

Ownership is transferred deliberately, never granted as an ordinary role:

  1. Make sure the target already is a member of the organization (invite them first if not).
  2. As the current owner, run “Transfer ownership” (Tenancy panel) with the organization id and the target’s user id.
  3. The target’s org-wide rows are replaced by a single org-wide OWNER row (venue-scoped rows are left untouched), and the transferring owner becomes an org-wide ORG_ADMIN.

Error codes you may meet:

  • TRANSFER_TARGET_NOT_MEMBER (422) — the target has no membership yet. Invite them, then transfer.
  • PERMISSION_DENIED (403) — only the current owner can transfer.

The last-owner rule

An organization must always keep at least one active owner. Removing or demoting the last owner is refused with LAST_OWNER (422). The remedy is the same in every case: transfer ownership to another member first, then remove or change the old owner.

Denials look boring on purpose

Two conventions protect every organization on the platform:

  • Reading or changing something in another organization returns NOT_FOUND (404) — the same answer as a wrong id, so nothing about other companies is ever confirmed to exist.
  • Being signed in but lacking the role returns PERMISSION_DENIED (403).

If you expected access and see a 404, confirm with your owner that you were added to the right organization and venue.