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](/docs/concepts/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](/docs/concepts/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:

```js
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](/docs/concepts/authorization) model tells you *what* the user may do with it.

## Related

- [Users](/docs/users) — the members that make up an organization.
- [Roles & permissions](/docs/permissions) — how org roles map to access.
- [Backend requests](/docs/backend) — reading and enforcing the active org server-side.