The Delete That Keeps the Row
Forty-nine kinds of record in this product are deleted by marking them rather than removing them. Twenty of them appear in the recovery centre. The other twenty-nine keep the row, set the flag, and offer nobody a way back — including nine that have a written retention policy naming them.
There is a difference between a record that is gone and a record that is merely out of sight, and the person who deleted it cannot tell which one they just did.
Most systems have two kinds of delete. A hard delete removes the row: the data is gone, and only a database backup will bring it back. A soft delete leaves the row exactly where it was and writes a timestamp into a column saying it should no longer be shown. Everything else in the system agrees to stop seeing it. Nothing has actually been destroyed.
Soft deletion is the safer of the two and this product uses it widely — forty-nine of its record types delete this way. What makes it worth an article is the third state nobody names: a record that is soft-deleted and has no screen to bring it back from. The data is intact. The button does not exist.
What the recovery centre actually carries
Twenty record types, each registered with a module, a risk level, the permissions that gate viewing, restoring and permanently deleting it, and a retention default. This is a real registry rather than a hard-coded list, which is the reason it can be described precisely at all.
| Risk level | Record types | Retention default |
|---|---|---|
| Critical | Users, assets, asset custodians, custom field definitions, custom field options | 90 days |
| High | Items, customers, employees, projects, expenses, custom field values | 90 days, except custom field values at 30 |
| Medium | Adjustments, vendors, positions, leave types, shifts, tasks, tickets, ticket categories | 30 days, except positions, leave types, shifts and ticket categories at 90 |
| Low | Public holidays | 30 days |
The risk level is not decoration. Permanently deleting anything rated high or critical raises an approval request rather than executing, and the approval carries a segregation-of-duties rule: whoever asked cannot approve it, and whoever asked cannot execute it either. You may withdraw your own request — you simply cannot be the one who says yes to it.
Retention is written down and switched off
Every one of the twenty carries a retention default, the window can be set anywhere from one day to ten years, and automatic purging is off by default. That is the right default and worth defending: a system that starts destroying records on a schedule nobody consciously chose is a worse failure than one that keeps too much. It does mean the numbers in the table above are a policy waiting to be switched on rather than a description of what is happening to your data today.
The twenty-nine that keep the row
Now the part that is not on any screen. Twenty-nine further record types delete by marking. The row survives, the flag is set, and no recovery centre entry exists for them.
- Finance and sales documents — purchase orders, quotations, customer invoices, journal entries, budgets, project payouts.
- Payroll — payroll runs, payslips, pay components, employee compensation, employee bank details, statutory rule sets.
- Employment records — employment contracts, employee contacts, leave requests, timesheet periods.
- Attendance — attendance records, regularisations, attendance sites, overtime records, shift schedules.
- Delivery — milestones, sprints.
- Everything else — hardware assets, customer addresses, customer contacts, supplier applications, draft emails.
The data is not lost. It is simply not addressable by anyone who would want it.
This is a considerably better position than a hard delete, and the distinction is worth being precise about because it changes what recovery costs. A hard-deleted row needs a database restore, which means a point in time, which means losing everything written since. A soft-deleted row with no screen needs somebody with database access to change one column. One is a disaster-recovery exercise; the other is a support request.
The nine with a policy and no screen
Nine of the twenty-nine are a sharper case, because the trash configuration already describes what should happen to them. It sets out, per module, whether a record may be restored, whether permanent deletion is guarded by dependency checks, and what blocks a hard delete. And it names record types the recovery centre does not carry.
Named in a policy, absent from the registry
Record type The policy that names it
purchase orders finance
Under a policy blocking permanent deletion once order or receiving history exists.
quotations procurement
Same policy — recoverable master data, retain-only once tied to a document trail.
customer invoices finance
Named alongside journal entries and budgets under the finance retention rules.
journal entries finance
The record type where retain-only is least controversial and most obviously right.
budgets finance
Soft-deletes today; the row is kept and the restore is a support request.
hardware assets asset tracking
Distinct from assets, which are in the registry at critical risk. The two delete the same way and only one comes back.
customer addresses sales
Named under a policy that explicitly contemplates restoring children with their parent.
customer contacts sales
The same. Deleting a customer and restoring it is the case this policy was written for.
draft emails communications
The one on the list nobody will lose sleep over, included because the count should be honest rather than dramatic.
The check runs both ways and the reverse is clean: every record type in the recovery centre is covered by a module policy. The gap is one-directional — policy written, surface not built.
A written policy naming a record type that has no screen is the most useful kind of gap to find, because the thinking is already done. Somebody worked out that a purchase order should be recoverable until it has order or receiving history against it, and wrote it down. What is absent is the page.
What this means for you in practice
You deleted one of the twenty
Restore it yourself
It is in the recovery centre, gated by the manage-trash permission, and restoring is one action. Nothing has been purged unless somebody deliberately switched retention on.
You deleted one of the other twenty-nine
Raise it as support, quickly
The row is intact and the fix is a column, not a restore. Speed matters only because retention could later be enabled on a policy that reaches it — not because the data is decaying.
You are about to delete something important
Check which list it is on first
Thirty seconds, and it changes whether the undo is a button or an email. This is the whole practical content of the article.
You are considering switching retention on
Decide the window per record type, not once
The registry already defaults sensibly — ninety days for anything critical, thirty for the routine. Accepting those and enabling it is a reasonable default position; picking one number for everything is not.
One habit worth adopting before any of this
Deleting is almost never the right action for a record with history. Most of the twenty-nine are documents — an invoice, a payroll run, a contract — and a document that existed and should not have is better cancelled, voided or superseded than deleted, because those states are visible to the next person and a deletion is not. Reserve deletion for genuine mistakes made minutes ago.
What AWRA OpsHub does today
- A recovery centre carrying twenty record types across ten modules, each registered with its module, tenant column, title and searchable columns rather than hard-coded into a controller.
- A risk level per record type, driving an approval requirement on permanent deletion for anything rated high or critical.
- Segregation of duties on that approval: the person who requested a permanent deletion cannot approve it and cannot execute it, while remaining free to withdraw their own request.
- Separate permissions for viewing trash, restoring from it and permanently deleting, plus a distinct permission for approving a deletion.
- A retention policy per record type, adjustable from one day to ten years, switched off by default so nothing purges until somebody chooses it.
- Alerting on purge failures from the first occurrence, and on unusual permanent-deletion volume at ten in a period or three times the normal rate.
- Written module policies covering restore, dependency-guarded deletion and hard-delete blocking for ten modules, including the rules for restoring child records with a parent.
- Soft deletion on forty-nine record types in total, so a delete on any of them keeps the row rather than destroying it.
- A separate request-and-purge pipeline for deleting an entire workspace, which is deliberately not a recovery-centre record.
More we can add to your workspace
- The nine record types their own module policies already name — purchase orders, quotations, customer invoices, journal entries, budgets, hardware assets, customer addresses, customer contacts and draft emails — surfaced in the recovery centre under the rules already written for them.
- Payroll and employment records in the recovery centre — payroll runs, payslips, pay components, compensation, contracts and bank details, which soft-delete today and are the set where an accidental deletion is felt hardest.
- Attendance and timesheet records in the recovery centre, covering attendance records, regularisations, sites, overtime and shift schedules.
- A cascade view at the point of deletion, showing what else will be marked deleted alongside the record before the action is confirmed.
- A restore that brings children back with their parent, which the sales module policy already describes and which is the difference between recovering a customer and recovering a customer with their addresses and contacts.
- An indication on the delete confirmation of whether this record type is recoverable, which is the smallest change here and removes the uncertainty this whole article is about.
Where we point you to a specialist
- We would decline to make automatic purging the default. A system that begins destroying records on a schedule nobody consciously chose fails in a direction that cannot be undone, and off is the correct position for a setting of that shape.
- Where a statutory retention period applies to a payroll, tax or employment record, that period governs and we point you to your own advisers to establish it. We will hold a record for as long as you tell us to; we will not publish a default that reads as advice about how long the law requires.
- A permanent deletion executed by the same person who requested it is something we will keep refusing for high and critical record types, even where a workspace is small enough that the rule is inconvenient. Segregation of duties is worth its friction precisely on the actions that cannot be reversed.
The nine record types with a written policy and no screen are the most contained piece of work described here, because the registry is data and the rules are already decided. Adding a record type is a configuration entry rather than a new subsystem.
A registry entry, not a rebuild
The reason this is worth scoping is architectural rather than optimistic: the recovery centre reads its record types from configuration, so extending it is mostly a matter of describing a record type rather than writing a screen for it.
The nine already under policy
Purchase orders, quotations, invoices, journal entries, budgets, hardware assets, customer addresses and contacts, draft emails — each an entry naming its module, risk level, permissions and retention default.
The payroll and employment set
A larger piece, and the one worth doing carefully: these are the records with statutory retention attached, so the window matters as much as the button.
A recoverability note on the delete dialog
The cheapest item on this page. Tell the person, at the moment they click, whether an undo exists.
We publish scope, not dates.
Scope the recovery centreOur take
The machinery here is better than the coverage, and that is an unusual and quite fortunate position to be in. A registry-driven recovery centre with risk levels, per-type retention, split permissions, an approval gate on irreversible actions and genuine segregation of duties is more than most systems of this size have — and it currently serves twenty of the forty-nine record types that could use it. Nothing is being destroyed: the other twenty-nine keep their rows, which is why this is a coverage gap rather than a data-loss risk. The practical advice is one sentence long. Before you delete something you would mind losing, know which of the two lists it is on, because that decides whether your undo is a button or a conversation.
Five questions for any vendor about deletion
Which record types can I restore myself?
A good answer sounds like
A list, not a yes.
What ours actually is
Twenty, named. Ask for the list rather than the capability — "we have a recycle bin" is true of a system that covers two record types and of one that covers two hundred.
What happens to the rest?
A good answer sounds like
A clear statement of soft versus hard.
What ours actually is
Twenty-nine more soft-delete and keep the row; recovery is a support request rather than a screen. The distinction decides whether the answer is a column change or a database restore.
Does anything purge automatically, and when?
A good answer sounds like
A default, and where to change it.
What ours actually is
Retention is configured per record type from one day to ten years, and it is off by default.
Can one person permanently delete a critical record alone?
A good answer sounds like
No, and here is the approval.
What ours actually is
No for anything rated high or critical. The requester can neither approve nor execute their own request.
Will a restore bring back the child records too?
A good answer sounds like
Yes, and here is what counts as a child.
What ours actually is
The sales module policy describes it and it is on the list above as work to be commissioned. Ask this one of every vendor — it is where recycle bins most often disappoint.
Find out which list your important records are on
It is a short conversation with a definite answer, and it is worth having before somebody deletes a purchase order rather than after. If retention is something you are required to configure rather than choose, that is worth raising in the same conversation.
Talk through recoveryFrequently asked questions
If a record is not in the recovery centre, is the data gone?
Not for the twenty-nine described here. Those delete by marking, so the row remains in the database exactly as it was and only a flag has changed. Recovery is a matter of clearing that flag rather than restoring a backup, which is a materially different situation to a row that has actually been removed.
How is soft deletion different from a hard delete in practice?
The difference is what recovery costs. A hard-deleted row needs a database restore to a point in time, which brings back everything as it was at that moment and loses everything written since. A soft-deleted row needs one column changed and affects nothing else. The first is an incident; the second is a request.
Is automatic purging switched on for my workspace?
Not unless somebody has deliberately enabled it, because the configuration ships with automatic purging off. The per-record-type windows are written down and ready — thirty days for routine records, ninety for anything rated high or critical — but they take effect only once the policy is activated.
Who can permanently delete something?
Permanent deletion is a separate permission from restoring, and for anything rated high or critical it raises an approval request rather than executing directly. The person who requested it cannot approve it and cannot execute it, though they can withdraw their own request. Five record types are rated critical: users, assets, asset custodians, custom field definitions and custom field options.
Why are only twenty record types covered rather than all forty-nine?
Coverage grew module by module as the recovery centre was built, and each record type needs describing before it can appear — its module, its tenant column, what to show as a title, which permissions gate it, what its retention default should be. The registry design means adding one is configuration rather than a new screen, which is why the remaining set is a scoping question rather than a rebuild.
What about deleting a whole workspace?
That runs through its own request-and-purge pipeline rather than the recovery centre, which is deliberate. Removing an entire workspace is a different kind of action with a different approval path and a different set of consequences, and treating it as one more row in a recycle bin would understate it considerably.
