Deletion Protection and the 30-Day Trash: Designing for the Mistake You Haven't Made Yet
Nobody plans to delete the wrong case. Everybody eventually does. The system should assume it.
Every destructive action in Herarx is designed on one assumption: sooner or later, someone will do it by accident, in a hurry, or because they were told to by someone who should not have asked. The question is not how to prevent that — it cannot be prevented — but how to make it survivable.
Layer one: Trash
Deleting a case, a file or a contact moves it to Trash for thirty days. It is out of the way but intact: the case's fields, files, contacts and timeline all restore together. After thirty days, purge. Nothing skips Trash.
Layer two: "Delete permanently" is a separate act
Emptying Trash early is a deliberate click with a password confirmation, and for secured cases a second factor. It is never a side-effect of something else. If you have not typed your password, nothing is gone for good.
Layer three: Deletion protection
Settings → Security → Deletion protection adds a waiting room. When it is on, a permanent deletion unlocks only after a confirmation step — a code sent to you, and in organisations a waiting period after the owner asks to turn protection off. The Trash page lists pending permanent deletions with their state: details requested, paused because someone objected, ready to confirm.
Members can request details or object. The owner upholds or cancels. Every step lands in the deletion oversight log. It slows down the one person who wants everything gone tonight — which is exactly the person it should slow down.
Secured cases: disclosure requests
Advanced-Security cases are invisible to non-members, which raises a hard question: how does a supervisor object to the deletion of something they cannot see? A watcher can file a disclosure request against a pending deletion; the case's members decide whether to disclose enough to let the objection be judged. The case is never opened silently.
Layer four: are-you-sure, everywhere it counts
Removing a member, disconnecting a mailbox, clearing a table, cancelling an e-sign request, purging a template: each has its own confirmation with the consequence spelled out. We resisted for a long time on the grounds that confirmation dialogs are annoying. Then we counted the support tickets that began "I didn't realise that would…". Annoying won.
What we do not do
We do not keep a shadow copy after a permanent deletion. When you confirm that a case is gone, it is gone from the live database; backups age out on their own schedule. Anything else would make our retention promises meaningless.
