# 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.