Deleting an organisation is the terminal action — it removes the org and cascades through every tenant, every member, every resource attached. The audit log survives for compliance, but everything else is gone. Owner-only, with a type-to-confirm guard so it can't be triggered accidentally.
You almost certainly don't need to delete the organisation. If you're shutting down operations, the cleaner move is usually to decommission your tenants individually and leave the organisation record in place. Deletion is the right call when:
- You're winding down a corporate entity and need a clean record-removal.
- You created the organisation by mistake (wrong email, wrong slug) and the platform is fresh.
- Compliance specifically requires the org-level record gone (rare; usually retention is the requirement).
Pause before clicking. Once the cascade runs, there's no restore.
Who can delete
Section titled “Who can delete”Only the owner can delete. The single human with the owner role badge on the Members page. Admins can't, viewers can't. If the owner is unavailable or has left the team, ownership has to be transferred first — that's a separate deliberate flow (deferred to a future docs topic).
How the action lives in the UI
Section titled “How the action lives in the UI”The delete affordance lives in Settings under a separately-styled Danger zone section. Clicking Delete organization opens a confirm dialog requiring you to type the organisation slug to proceed. The button stays disabled until the typed value matches exactly.
What the cascade does
Section titled “What the cascade does”Once confirmed, the platform runs:
- Decommission every tenant. Each tenant goes through the deprovisioning workflow described in Decommission a tenant. Resources released, state flipped to
decommissioned. - Remove all members. Member rows deleted, pending invitations revoked.
- Archive the organisation. Org state flips to
archived(you won't see it in any list); the row itself is retained for audit referenceability.
Total runtime depends on tenant count — each tenant's deprovisioning saga runs in parallel, so the wall-clock time is roughly the slowest single tenant's saga, not the sum.
What survives
Section titled “What survives”Two things are retained by design:
- Audit log entries for everything that ever happened in the organisation. Retained per the platform's audit retention policy.
- The org row itself, in
archivedstate. Visible only to platform operators with elevated permissions for compliance lookups.
What's gone for good:
- Every tenant's users, applications, sessions, MFA enrollments. Standard decommission applies per tenant.
- Every member. Member rows deleted.
- Plan + billing records for the active billing period. Final invoice is generated and sent.
After deletion
Section titled “After deletion”You're signed out and routed back to the marketing site. The slug is freed and can be claimed by a new signup (yours or anyone else's). The owner's email is unconstrained — they can sign up for a new organisation with the same email anytime.
There is no restore path. If you change your mind, create a new organisation and re-provision tenants from scratch.