# Multi-tenant model

## Option A: Organizations (one tenant)

Each customer is an Organization in a single tenant. Shared connections or per-org connections, org_id in tokens, JIT membership for onboarding.

Choose when: standard B2B SaaS, customers want SSO with their IdP (enterprise connection per org), you want one codebase and one config to operate.

Watch: connection enablement is per-org; the organization parameter must be passed on every login; token validation must check org_id.

## Option B: Tenant per customer

Each customer gets their own Auth0 tenant.

Choose when: regulatory isolation (data residency per customer), customers demand their own Auth0 dashboard/admin boundary, or radically different auth config per customer that Organizations cannot express.

Cost: N tenants to configure, monitor, and keep in sync. Use the deploy CLI or Terraform to stop config drift; do it by hand and the tenants WILL diverge.

## Option C: Single tenant, no orgs

One shared user pool, application-level tenancy in your own data model.

Choose when: consumer app or simple B2B where customers do not need isolated login contexts or their own IdPs. Simplest to operate; do not add Organizations ceremony you do not need.

## Decision inputs

- Do customers bring their own IdP? Yes -> Organizations (or tenants).
- Data residency per customer? Yes -> tenants in the right regions.
- Team size for auth ops? Small -> fewer tenants, prefer Organizations.

## Checklist

- Decision written down with the reasons; it is expensive to reverse.
- If tenants: config-as-code from day one.