Administration at a glance
Two scopes, deliberately apart
| Scope | Operates on | Reachable by |
|---|---|---|
| Platform | All tenants | Platform administrators only |
| Tenant | One tenant's own configuration and users | That tenant's administrators |
Platform operations cross tenant boundaries and run under a different authorization scope entirely. A tenant administrator cannot reach them, however privileged within their own tenant.
Tenant lifecycle
| State | Access | Data | Reversible |
|---|---|---|---|
| Active | Normal | Retained | — |
| Suspended | Blocked | Retained | Yes |
| Deleted | Blocked | Retained, soft-deleted | Yes |
Suspension is the right tool for a billing or compliance hold: reversible and non-destructive.
The bootstrap problem
A new tenant has no users. Sign-in cannot create the first one, because it resolves tenants a user is already a member of — which for a new tenant is none.
So the first administrator is granted explicitly, by naming an identity in your identity provider. Only the provider's identifier is supplied; the details are read from the provider, so a caller cannot fabricate an identity.
Granting a group is usually better — membership then follows your existing joiner and leaver process.
After that grant, the tenant administers itself.
Identity is mirrored, never created
| Path | Creates |
|---|---|
| Sign-in | A user, on first authentication into a tenant they can reach |
| Administrative mirror | A user, from a named provider identity |
| Group sync | Groups, from the provider |
There is no path that creates a user from arbitrary input — enforced at the database level, not only in application code.
Configuration snapshots
A snapshot stores a configuration payload. There is no apply, restore, rollback, or diff. It is a record, not a recovery mechanism — do not plan a recovery procedure around it.
Next
Last verified against commit 1e1de1ad (2026-08-03)