Workspace Deletion Workflow

Close a whole workspace without one click erasing everyone's work.

involved User Accounts

What it adds

An owner-only deletion flow with an explicit inventory, a recovery window, and cascading cleanup across internal and external systems.

What your agent is told to do

1
Restrict deletion to owners and require recent re-authentication plus typing the workspace name. This is the most destructive action in the product and should feel like it.
2
Show an inventory before confirming: how many members lose access, what happens to billing, how many files and records are affected, which integrations disconnect, and which shared links die.
3
Schedule the deletion rather than executing it. Mark the workspace as pending deletion, block access to it, notify every member and admin, and only purge after a stated recovery window.
4
Allow any owner to cancel during that window, and restore the workspace to exactly its previous state — not a default one.
5
Cancel the subscription at the point of scheduling, not at purge, so nobody pays for a workspace they have closed.
6
Make the purge idempotent and resumable, working in batches, so a failure halfway through can simply be re-run.
7
Do NOT leave external systems behind. Storage objects, search indexes, cache entries, queued jobs, and third-party resources are part of the delete, and they are what gets forgotten.

Edge cases it handles

A member who belongs only to this workspace needs somewhere to land after the purge — decide whether their user account survives.
Legal holds, open disputes, and retention obligations must block or delay the purge, and the requester must be told why.
Data the customer wants must be offered as an export before the window closes, not after the records are gone.
Shared public links must stop resolving as soon as deletion is scheduled, not at purge — access ends when the owner says it ends.
The workspace name or slug should not be immediately reusable; hold it until the purge completes, or old links resolve to a stranger's workspace.
External deletions can partially fail and must be retried without re-deleting what already succeeded; record progress per system.
Very large workspaces must not attempt a single transactional delete — batch it and keep the workspace unreachable throughout.

Definition of done

Only an owner can delete, after re-authentication and typing the workspace name.
An inventory of members, billing, data, integrations, and links is shown before confirmation.
Deletion is scheduled with a stated recovery window and every member is notified.
Cancelling within the window restores the previous state exactly.
Billing stops when deletion is scheduled.
The purge is batched, idempotent, and resumable, and covers storage, indexes, caches, jobs, and third-party resources.
Shared links stop working as soon as deletion is scheduled.
The feature matches the existing design system.
No existing functionality is broken.

Related features

User Roles

Domain Verification

Account Settings

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.