Auth, membership, invitations and billing all need organization boundaries in the data model and the session, not only in the UI.

  1. 01Request
  2. 02Session → active organization
  3. 03Role check
  4. 04Tenant-scoped query
  5. 05Response
The active organization comes from the session, never from a free-form client ID.

Session-scoped active organization

API and UI should resolve the active organization from the session, not from a free-form client ID. That single rule prevents most cross-tenant data leaks and simplifies authorization.

Enforce boundaries twice

Every tenant-owned table carries an organization key. Application checks filter by it, and database policies enforce it again, so one missed filter does not become a data leak. Tests try cross-tenant access on purpose.

Membership and roles as product surface

Invitations, admin roles and personal organizations are product features. Treat them with the same care as customer-facing flows: clear states, honest errors, and tests around the hard paths.

Billing sits on the same boundary

Subscriptions attach to organizations. Design that early even if you ship billing later; retrofitting tenancy into billing costs more than leaving a clean seam.

Migrating an existing product

  1. Add organization keys to tenant-owned tables.
  2. Backfill existing data into a default organization per customer.
  3. Enforce the keys in queries and database policies.
  4. Remove old code paths once tests pass on production-like data.

The Ledger case describes how we built authentication, authorization and subscription features in a financial product. For architecture planning, explore our product engineering and architecture services.