Admin

Trash — recoverable delete

Deleting a record sends it to Trash, where it can be restored for 90 days before it's permanently removed — a safety net that turns delete from a one-way action into something you can undo.

For
Org admins
Find it at
Sidebar → Trash (admin-only)
Reading time
5 min

In one sentence

Trash is the org-wide bin for records that have been deleted across the regulated modules — every deleted NCR, audit, MOC, FMEA, JHA, meeting, risk, exemption, and document lands here with one-click restore available for 90 days, after which a daily purge permanently removes it.

Three things to remember
  • Delete has a 90-day undo window. Clicking Delete on a regulated record hides it from normal views and moves it to Trash with the actor and timestamp recorded. You have 90 days to restore it; after that, a daily purge removes it permanently. The record's body is gone post-purge, though activity-log traces of its lifecycle remain.
  • Restore brings the record back exactly as it was — within the window. All cross-module links, comments, attachments, history, and approvals come back with it. Nothing is lost while the record sits in Trash.
  • Suppliers and clients are different. They don't go to Trash — they use an Inactive flag instead. An inactive supplier still appears on the list with a badge so an admin can flip them back. The terminology overlap is historical, not a bug.

Where Trash lives

Sidebar → Trash. Admin-only — the page is gated on the Manage trash permission, which the default Admin role has and Standard User doesn't. If you've built a custom role for cleanup responsibilities, grant Manage trash to give them access without full admin.

The page shows up to 500 deleted records org-wide, newest deletion first.

What's in Trash

Nine regulated module types can land in Trash:

  • Non-conformances (NCRs)
  • Audits
  • Management of Change (MOCs)
  • FMEAs
  • JHAs
  • Meetings
  • Risks (from the Risk Register)
  • Exemptions
  • Documents (both internal SOPs and external regulatory docs)

Each entry carries:

  • A module badge so you can scan by type.
  • The record reference (NCR-2026-0418, MOC-2026-0119, ISO 9001:2015 — Clause 8.3, etc.) and label.
  • Deleted at — when the delete happened, with a relative timestamp.
  • Deleted by — the admin who clicked Delete. Snapshotted at write time so deleting that user later doesn't erase the trail.
  • An auto-purge countdown badge — "Auto-purges in 12 days". The countdown goes amber at 7 days remaining and red the moment it's overdue, so an entry about to disappear catches your eye on a quick scan.

Restoring a record

Click Restore next to the record. The record comes back in its full prior state:

  • Status, approvals, version history — all restored exactly as they were.
  • Cross-module links (NCR ↔ MOC, audit ↔ finding ↔ action, etc.) reconnect on both sides.
  • Comments, attachments, History tab entries — all restored.
  • The user list pickers that filter on the record will see it again on the next page load.

The restore is captured as a History event on the record itself — "Restored from trash by Alice Cooper at 14:22" — so an inspector reading the audit trail can see both the delete and the restore as distinct events.

Manually purging early

Most of the time you let auto-purge do its work. But if you have a record you genuinely want gone immediately (an accidental upload with sensitive content, for example), click Purge next to the record.

Purge is permanent — there's no recovery after this. The system asks you to confirm before proceeding.

Bulk-select with checkboxes if you need to purge several at once. The Restore-all and Purge-all toolbar actions appear when you have a selection.

Auto-purge — 90 days

A daily auto-purge at 03:00 UTC sweeps Trash and permanently removes every record that's been there more than 90 days. The countdown badge on each entry reflects how many days that record has left.

The 90-day window is currently hard-coded — it's the same for every org, every module, every record. It can be revisited if your regulatory environment needs a longer or shorter retention; raise it with your account contact.

What happens at purge time

When a record is purged (either manually or by the daily auto-purge), the system removes:

  • The record itself and its body content.
  • Attachments owned by the record.
  • Cross-module links to and from the record.
  • Notifications that referenced the record.
  • Ask the Library conversation links that pointed at the record — the conversations themselves stay with their owner; only the linkage is cleaned.

After the purge, the record's body is gone from the system. The fact that it existed still leaves traces in:

  • The activity log — the original create / update / delete events for the record remain.
  • The audit-log access trail — anyone who viewed the record's history during the trash window is recorded.

So a regulator asking "was there ever a record with this reference?" gets a "yes, and here's the lifecycle including the deletion and purge" answer, even after the record's body is gone.

Storage isn't fully cleaned at purge time

For external documents, the underlying PDF in object storage isn't deleted when the record is purged today. The document record goes away; the file lingers in storage. This is a known limitation. If you're purging an external doc because the file must go (a customer-restricted PDF, for example), raise a support request to manually clean storage too.

What's not in Trash

Suppliers and clients. Both use an Inactive toggle instead of delete-to-trash — historical naming overlap notwithstanding. An inactive supplier or client:

  • Still appears on the list page with an Inactive badge.
  • Is hidden from new picker dropdowns.
  • Keeps every existing cross-module link intact.
  • Can be reactivated by flipping the toggle from the detail page.

So if you can't find a deleted supplier in /trash, that's expected — go to the Suppliers list, toggle "Show inactive" on, and you'll find them.

Terminal-status records can't be deleted at all. The system refuses to send these to Trash:

  • Approved, Implementing, or Closed MOCs
  • Closed audits
  • Approved or Obsolete FMEAs
  • Approved or Archived JHAs
  • Closed meetings
  • Approved or Obsolete documents

These are permanent records of decisions made — they belong in the historical trail forever. The delete button is hidden or disabled on these records. If you genuinely need a terminal-status record gone, you have to manually revert it back to an earlier status first (which is itself logged), then delete from there.

Risks with active cross-module linkage also block delete — the existing "this risk is linked to an open MOC" gate is preserved on top of the soft-delete change.

Two-layer protection against accidental reads

Trashed records are hidden from regular views by two independent layers:

  • At the application — every list, detail page, and search filters trashed records out.
  • At the database — an access rule on each regulated table independently blocks trashed records from showing up in any query.

Either alone would protect you; together, they're inspector-grade defense in depth. A code path that forgets to add the application filter is still caught by the database rule; a misconfigured access rule is still caught by the application filter.

Permissions

  • Reading the Trash page — requires the Manage trash permission.
  • Deleting a record (sending it to Trash) — uses each module's existing delete permission. The delete itself isn't part of this article; the destination is.
  • Restoring — Manage trash.
  • Purging early — Manage trash.
← Previous
Signature manifestation
Next →
How delete works — soft-delete and the trash window
Was this helpful?
Suggest an edit →