Trash, Recovery, and Legal Holds

Deleting a record in AWRA moves it to Trash, reached from the sidebar, instead of removing it. Twenty-four record types across eleven modules work this way, from items, vendors, customers and assets to employees, projects, ticket categories, expenses, CRM leads, customer quotes, supplier contracts, budgets and custom fields. Restoring brings the record back with its original identifiers rather than as a copy, so the invoices, movements and reports that referred to it are correct again.

Three separate permissions govern Trash: one to view and restore, one to permanently delete, and one to approve somebody else’s permanent delete. A workspace can therefore run a full recovery centre in which nobody at all can destroy a record. Where a parent was deleted with its children, such as a customer with its contacts and addresses or a project with its milestones and sprints, restoring the parent brings the set back.

Budgets are a good example of why restore matters. Deleting a spending cap moves it to Trash; restoring it puts it back in force, so procurement budget checks and Budget vs Actual read it again from that moment. In practice: a finance assistant deletes the wrong department’s Q4 budget on a Friday. On Monday the budget owner opens Trash, finds it under Finance, checks the impact preview and restores it, and the requisitions raised over the weekend are checked against the cap again.

Open any record in Trash and the impact preview shows what it is attached to, what would come back with it on restore, what a permanent delete would affect, and any blockers. Before every permanent delete AWRA also checks what depends on the record elsewhere: saved reports built on its dataset, active workflows that fire on its events, and ledger lines and journal batches that reference it. Postings stay posted whatever you delete; the preview names the ones that would point at a record that no longer exists. The preview is on the web and in the mobile app, and seeing it needs no destructive permission.

Every permanent delete asks for a written reason of at least ten characters, on the web and through the API, and the reason is kept with the record’s history. On the twelve record types rated high or critical, such as users, assets, employees, items, customers and budgets, the delete becomes a request instead: someone holding Approve trash deletes reads the reason and decides, and the person who asked can neither approve it nor carry it out. A scheduled purge is not a request and records its own reason.

Some deletes are refused outright. Around ninety named dependency checks block a permanent delete while history still needs the record, for example an item with stock movements or an asset with custody history, and each refusal says which check stopped it. In practice: an administrator tries to destroy an old test customer and a real one in the same afternoon. The test customer has no history, so the request with its reason goes to the approver and is executed. The real customer is refused because invoices still reference it, and the right action is to leave it in Trash or mark it inactive.

A legal hold marks a trashed record, or a whole record type, as something that must not be destroyed: a dispute, an audit or an investigation. While a hold is active a permanent delete is refused rather than discouraged. Each hold carries its reason, who placed it and an optional expiry, so a litigation hold does not quietly become permanent, and releasing it records who released it and why. A type-scope hold also covers records deleted after it was placed.

Retention policies decide when trashed records are eventually purged. They are off by default; once switched on, each record type has a window between one day and ten years. A scheduled purge applies them, can be run in dry mode to report what a real run would remove, and writes a report for every run. Retention and holds stack: a purge or a permanent delete is refused if either applies, and the screen names which one blocked it. A failed purge raises an alert at the first failure and goes critical at three, and it also lands in the operations exception inbox with an owner and an SLA clock.

Every deletion, restore, hold, approval and purge is written to the trash lifecycle ledger with the actor, the surface, the route and the related audit entry, and that ledger can be included in a compliance evidence pack. In practice: before an annual audit the finance manager places a type-scope hold on expenses for the year under review. The nightly purge skips them, the run report says so, and when the audit closes the hold is released with a note and the normal window resumes.

Some documents never go to Trash because the correct fix is to cancel, void or reverse them so the trail shows both the mistake and the correction. The Trash page has a section, Recovering records Trash does not hold, with a playbook for each area: RFQs, quotations and purchase orders are cancelled; invoices, credit notes and sales orders are voided; POS sales are reversed at the till; journals, supplier bills and payments are reversed; saved and scheduled reports are recreated; draft emails and the monthly digest are recreated; and hardware assets in the older register restore from their own screen. You only see the playbooks for areas your permissions cover.

The Analytics & recovery button on the Trash page opens trash analytics: who deleted what, by person, module and record type, what is due for purge in the next seven days, and the delete approvals still in flight, over the last 30 days or any period up to a year. It needs the manage trash permission and is also in the mobile app. A separate watch raises an alert on unusual permanent-delete volume, at ten in a period or three times the normal rate.

In practice: a branch manager reports that last week’s supplier invoice has vanished. Trash analytics shows no supplier bill deletions at all, and the finance playbook explains why: bills are never deleted into Trash. The accountant finds the bill was reversed with a journal, posts the corrected one, and the question is closed with both postings visible in the ledger.