Thirty Days and Three Tables That Survive
Deleting a workspace is a thirty-day request rather than an action, it can be cancelled for as long as it has not started, and exactly three tables survive it — including the record of the deletion itself.
Our take
The two decisions that matter in a deletion pipeline are how long somebody has to change their mind and what evidence outlives the data. Thirty days is generous and it should be — a workspace deleted in anger on a Friday is a workspace somebody wants back on Monday, and the cost of holding it is storage. The more interesting decision is the second. Three tables survive a purge, and one of them is the record of the deletion request itself, which means the answer to "was this workspace deleted, when, by whom and why" outlives every byte of the workspace. That is the difference between deleting data and destroying the account of having deleted it, and only one of those is defensible.
A workspace does not get deleted. It gets scheduled, and then thirty days later something happens.
The states, and what each one means
| Request state | Workspace state | Reversible? |
|---|---|---|
| Scheduled | Pending deletion | Yes — cancelling returns the workspace to active. |
| Ready for purge | Deleting | No. The point of no return has been passed deliberately. |
| Processing | Deleting | No. |
| Completed | — | No. |
| Cancelled | Active | The request ended without a purge. |
| Failed | — | Something went wrong and the request is on the record as having done so. |
The separation between scheduled and ready-for-purge is the whole safety design. Scheduling is what a customer does; arming is a separate step that refuses to run unless the request is still in the scheduled state. So a cancellation and an arming cannot both take effect, and the transition to irreversible is an explicit act rather than the expiry of a timer.
Two people cannot schedule two deletions
Scheduling locks the workspace row and then looks for an existing active request under a lock as well. That sounds like defensive engineering for an unlikely case, and it is exactly the case where an unlikely race produces the worst outcome available: two requests, one cancelled and one not, and a workspace that is deleted after somebody was told it would not be.
Cancelling puts it back, carefully
Cancelling marks the request cancelled and returns the workspace to active — but only if it is still pending deletion. A workspace that has already moved on to another state is left where it is rather than dragged backwards.
That conditional is the kind of thing that looks like pedantry and prevents a specific bad outcome: a late cancellation on a request that has already been armed would otherwise reactivate a workspace whose purge is under way.
Undoing a state you no longer occupy is not an undo.
What survives
Three tables are excluded from the purge, described in the code as system-level evidence that must survive. Two of them are structural and one is the interesting one.
- The migrations record, which describes the shape of the database rather than anybody's data.
- The workspace record itself, so the identifier is not reissued and a reference to it from outside does not resolve to somebody else.
- The deletion request, which is the account of what happened: when it was scheduled, by whom, for what reason, when it completed, and the workspace's email address as it stood at the time.
That third one is worth defending explicitly, because it is data about a customer surviving a request to remove their data. The alternative is a system that can destroy a workspace and then cannot say that it did — which fails the first question anybody asks afterwards, and fails it in a way that looks like evasion whether or not it is.
Files are enumerated, not inferred
Removing rows is the easy half. The harder half is the files those rows pointed at, and here they are listed explicitly: for each table, the column holding a path and the storage it lives on.
That list runs from the obvious to the easily forgotten — profile photographs on workspaces, users, items, suppliers and customers; document vault files and compliance packs, each carrying its own storage location per record; report exports; workflow task attachments; quotation, adjustment and payment attachments; invoice files; till receipts; and the general attachments table.
An explicit list has an obvious weakness — a new file column has to be added to it — and one decisive strength: it is readable. Anybody can check whether a particular kind of file is covered, which is impossible with an inferred sweep and is precisely the question that matters when somebody asks whether their documents were actually removed.
The preview reads the same lists
Before a deletion runs, an impact preview reports what will be removed. It is built from the same exclusion list and the same file columns as the purge itself rather than describing them separately.
That is the correct construction and the reason is general: a preview maintained independently of the operation it previews is a document that starts accurate and drifts, and the drift is invisible until somebody relies on it. Deriving both from one description means the preview cannot describe a purge that will not happen.
The reminders in between
Each morning, scheduled requests whose date is still in the future and which have not already been reminded today produce an email to the workspace, gated by that workspace's own notification setting. So thirty days is not thirty days of silence — it is a daily reminder that something is due to happen, with a cancellation available throughout.
What AWRA OpsHub does today
- A thirty-day default grace period between scheduling a workspace deletion and it becoming irreversible.
- Scheduling under a lock on both the workspace and any existing active request, so two simultaneous requests cannot be created.
- A snapshot of the workspace's email address stored with the request, so the record survives changes to the workspace itself.
- Six request states and a separate workspace state, with the transition from reversible to irreversible as an explicit act that refuses to run on anything but a still-scheduled request.
- Cancellation returning the workspace to active only where it is still pending deletion, so a late cancellation cannot reactivate a purge already under way.
- Three tables excluded from the purge as system-level evidence: the schema record, the workspace record, and the deletion request itself.
- An explicit list of every table and column holding a file path, with the storage each one lives on, including per-record storage for vault files and compliance packs.
- An impact preview built from the same exclusion list and the same file columns as the purge, so it cannot describe an operation that will not happen.
- A daily reminder to a workspace with a scheduled deletion still in the future, gated by that workspace's own notification setting.
- A failed state on the request, so a purge that did not complete is on the record rather than absent from it.
More we can add to your workspace
- A customer-visible countdown on the workspace itself, showing the scheduled date and the cancellation route without waiting for the daily email.
- An export offered as part of scheduling, so a workspace leaving takes its own data with it as a matter of course.
- A second approval on arming the purge, matching the separation of duties applied to permanent deletion of individual records.
- A per-table completion record, showing what the purge actually removed rather than what it set out to remove.
- A detection for a file column absent from the list, so a new attachment feature cannot quietly fall outside the purge.
- A stated position on backups, describing how long a purged workspace persists in infrastructure snapshots.
Where we point you to a specialist
- We will keep the deletion request itself out of the purge. A system that can destroy a workspace and then cannot say that it did fails the first question anybody asks afterwards, and the record of an erasure is not the same thing as the data that was erased.
- We will not make the transition to irreversible automatic on the expiry of a timer. Arming a purge is a deliberate act with its own refusal to run on anything but a still-scheduled request, because a countdown that fires on its own removes the last moment a person could intervene.
- What your own retention obligations require you to keep before deleting a workspace is a legal question for your advisers, and the export you take before scheduling is yours to arrange. We will preview exactly what is going and hold the schedule while you do it.
A customer-visible countdown on the workspace is the smallest piece with the largest effect — thirty days is only a grace period if the person who needs it knows it is running.
Leaving with your data
The pipeline is careful and the evidence is right. What would complete it is making the wind-down as legible to the customer as it is to the operator.
A visible countdown
The scheduled date and the cancellation route on the workspace itself, rather than only in a daily email.
An export at scheduling
A workspace leaving takes its own records with it as part of the process, rather than as something to remember beforehand.
A second name on the arming
The same separation of duties applied to permanent deletion of individual records, applied to the irreversible step here.
We publish scope, not dates.
Scope workspace deletionFive questions to ask before deleting a workspace
How long do I have to change my mind?
A good answer sounds like
A stated period.
What ours actually is
Thirty days by default, with a daily reminder while it runs and cancellation available throughout.
What makes it irreversible?
A good answer sounds like
A deliberate act, not a timer.
What ours actually is
An explicit arming step that refuses to run unless the request is still in the scheduled state.
What survives the purge?
A good answer sounds like
A short, justified list.
What ours actually is
Three tables: the schema record, the workspace record so its identifier is not reused, and the deletion request as the account of what happened.
Are files removed as well as records?
A good answer sounds like
Yes, and enumerated.
What ours actually is
An explicit list of every table and column holding a path, with the storage each lives on — readable, so you can check whether a particular kind of file is covered.
Can I see what will be removed first?
A good answer sounds like
Yes, from the same source.
What ours actually is
An impact preview built from the same exclusion list and file columns as the purge, so it cannot describe an operation that will not happen.
Take your export before you schedule
Thirty days is plenty of time and it is much easier to arrange an export while a workspace is still fully working. It is the one step the pipeline does not do for you.
Talk through leavingFrequently asked questions
Can we cancel a scheduled deletion?
Yes, at any point while the request is still scheduled. Cancelling marks the request cancelled and returns the workspace to active — conditionally, so a workspace that has already moved past that state is left where it is rather than dragged backwards. A daily reminder runs throughout the period so the option is not forgotten.
Does the deletion happen automatically after thirty days?
The date is when it becomes due; making it irreversible is a separate, deliberate step that refuses to run on anything except a still-scheduled request. That separation exists so a countdown cannot fire on its own and remove the last moment a person could intervene.
What is kept after a workspace is purged?
Three tables: the schema record, the workspace record itself so its identifier is never reissued to somebody else, and the deletion request — when it was scheduled, by whom, why, when it completed, and the workspace's email as it stood at the time. That last one is deliberately kept, because a system that can destroy a workspace and not say that it did fails the first question anybody asks afterwards.
Are our uploaded documents actually deleted?
Yes, and the coverage is checkable rather than assumed. Every table and column holding a file path is listed explicitly along with the storage it lives on — profile photographs, vault files, compliance packs, report exports, workflow attachments, quotation, adjustment and payment attachments, invoices and till receipts. An explicit list means you can read it and confirm your case is covered.
Can we see what will be removed before it happens?
Yes. An impact preview is produced from the same exclusion list and the same file columns the purge itself uses, rather than being maintained separately. That construction matters: a preview kept independently of the operation drifts from it, and the drift is invisible until somebody relies on it.
What about backups?
Backups are infrastructure rather than something this pipeline describes, and we would rather say so than imply a guarantee the code does not make. If your obligations require a stated position on how long a purged workspace persists in snapshots, that is a conversation to have explicitly rather than an assumption to carry.
