Organizations bring B2B multi-tenancy inside your app. Where the platform hierarchy (tenant, project, environment) is your infrastructure, organizations model your customers — each one a group of users with its own memberships, roles, and invitations, all living inside a single environment.
Organizations vs. platform multi-tenancy
These are two different layers, and it helps to keep them distinct:
- Platform multi-tenancy — Tenant -> Projects -> Environments. This is how you separate your own stages and apps. Each environment has its own signing keys, connections, and user store.
- Organizations — a grouping within one environment's user store. This is how your app separates its business customers. All organizations in an environment share the same user store and authentication config.
A single sign-on flow, one user store, many organizations.
Memberships
A user becomes part of an organization through a membership. One user can belong to several organizations at once, and a membership carries the user's org-scoped roles. Removing a membership revokes the user's access to that organization without affecting their account or their membership in others.
Org-scoped roles
Roles assigned through a membership apply only within that organization. The same user can be an admin in one organization and a member in another. How those roles translate into concrete access is defined by the environment's authorization model — see Authorization. Group-to-role mappings from SSO or HRIS can assign these org roles automatically.
Invitations
Bring new members in with invitations: send an invite to an email address, and when the recipient signs in (creating a user if needed) they are added to the organization with the role you specified. Invitations are the self-serve path for a customer admin to grow their own team without you touching the console.
Driving authorization with the active organization
Because a user can span multiple organizations, a session identifies which organization is active for the current request. Read it from a session claim and scope your data access accordingly:
const session = await authdog.getSession(request);
const orgId = session.claims.org_id; // active organization
const role = session.claims.org_role; // role within that org
if (!orgId) return redirectToOrgPicker();
const invoices = await db.invoices.where({ orgId });Enforce the role on the server, not just in the UI — the active-org claim tells you which tenant's data to load, and your authorization model tells you what the user may do with it.
Related
- Users — the members that make up an organization.
- Roles & permissions — how org roles map to access.
- Backend requests — reading and enforcing the active org server-side.