Once a tenant is decommissioned, two paths sit in front of you. You can recreate — provision a fresh tenant under the same slug, getting back the URL but with all-new data — or you can delete the historical record entirely so the slug is freed and the audit trail removed. Each makes sense in different contexts.
Recreate — same slug, fresh start
Section titled “Recreate — same slug, fresh start”The most common move after decommission. The slug production was retired on Monday; on Tuesday you provision a new "production" tenant under your organisation and traffic flows to https://production-<org>.<domain> again. No data carries over. The new tenant has its own users, applications, configuration, audit log.
To recreate, just create a new tenant with the same slug as the decommissioned one — same flow as any first-time provision. See Provision a new tenant. The platform accepts the slug because the previous tenant is no longer holding it.
The org audit log retains every event from the previous tenant under that slug — tenant.provisioning.completed, the decommission, everything. A new tenant under the same slug starts a fresh chain of events. If someone asks "who used production between January and March?" you can still answer them from the audit feed.
What recreate is NOT:
- It's not a restore. Users, applications, sessions from the old tenant aren't recovered. The slug is the only thing that carries over.
- It's not a rename. If you want a different slug, just pick one. Recreate-with-different-slug is just "create a new tenant" — the recreation framing only matters when you're reusing the old slug.
- It's not free. Provisioning runs the full saga again — fresh storage, fresh identity store, fresh workloads. Same cost as any first-time provision.
Hard delete — remove the record entirely
Section titled “Hard delete — remove the record entirely”If you want the slug truly gone and the tenant record removed from your platform — no archived row, no historical reference — there's a hard delete on the decommissioned tenant. This is the path for tenants you never want appearing in any list, even a filtered one.
Available only when the tenant is in Decommissioned state. From the detail page (or the Tenants list with the "include decommissioned" filter on), the action button reads Delete permanently in the Actions section, separated from other actions with explicit destructive styling.
What hard delete does:
- Removes the tenant row from the catalog. It will no longer appear in any list, filtered or not.
- Removes the resource-allocation record (which was already drained at decommission time).
- Frees the slug for any organisation to use, including yours.
What hard delete does NOT touch:
- The org audit log. Audit events naming this tenant id are retained per your retention policy. The historical record of "who did what" survives.
- External integrations. If you piped audit events to a SIEM or webhook target, those entries are unaffected.
Most teams should stop at decommission. The decommissioned record costs nothing (no resources held) and answers any "what happened to that tenant in 2024?" question cleanly. Reach for hard delete only when:
- Compliance specifically requires the tenant record removed (rare; usually compliance requires the opposite).
- The slug needs to be available to a different organisation in a shared platform.
- You're cleaning up a sprawling list of test tenants from before a clear naming convention.
Decision flow
Section titled “Decision flow”Quick way to decide:
- Customer churned but might come back. Suspend (reversible). If they don't come back in N months, decommission.
- Customer is definitely gone. Decommission. Leave the record decommissioned.
- Test tenant, definitely done with it. Decommission. Hard delete optional.
- Slug needed back for a new customer. Decommission the old one, then provision the new tenant with that slug.
- Cleaning up tenant sprawl from a test-environment past. Decommission first, then hard delete in a batch.