Provision a tenant
Before you start
Platform administration access, including platform.tenant.create to create a
tenant and platform.tenant.admin.grant to grant its first administrator.
This operates across tenants and is a different authorization scope from tenant administration — a tenant administrator cannot reach it, however privileged within their own tenant.
1. Create the tenant
Give it a slug and a display name. The slug appears in URLs and identifies the tenant at sign-in; it is not easily changed later.
The permission catalog is seeded as part of creation, so roles can be composed immediately rather than after a separate step.
2. Grant the first administrator
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 brand-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 identity's email and name are read from the provider itself, so a caller cannot fabricate an identity that does not exist there.
You can grant a group instead of an individual, which is usually better: membership then follows your existing joiner and leaver process.
3. Install configuration
Install a seed pack so the tenant has a data model, reference data, rules, and roles rather than starting empty.
4. Hand over
From here the tenant administers itself: its own users, roles, ABAC policies, and configuration. Platform administration is not needed for day-to-day operation.
5. Suspending and restoring
| Action | Effect |
|---|---|
| Suspend | Access blocked; data retained; reversible |
| Reactivate | Access restored |
| Delete | Soft-deleted and restorable |
Suspension is the right tool for a billing or compliance hold. It is reversible and non-destructive, so it carries none of the risk of deletion.
Next
Last verified against commit 74cecd91 (2026-08-03)