How delete works — soft-delete and the trash window

In one sentence

Clicking Delete on a regulated record doesn't destroy it immediately — every delete is a two-stage process: a soft-delete hides the record and moves it to Trash for 90 days, then a daily purge permanently removes it. This article explains what comes back when you Restore within the window, what survives after purge, and which records can't be deleted at all.

Why soft-delete

For a regulated QMS, immediate hard-delete on every click is a problem:

• A misclick on the wrong record could lose months of investigation work, with no recovery and no trail of the loss.
• Inspectors care about every state a record has been in. "It was deleted accidentally" is a story you'd rather have data for than recall.
• Cross-module references (a CAPA linked to an NCR, a MOC linked to a Risk) would become orphaned the moment one side disappears mid-flow.

Soft-delete solves all three by adding a 90-day window between click Delete and gone forever. The Delete button still feels like delete to the user — the record disappears from lists, searches, and pickers immediately. But behind the scenes the record is preserved with a deletion timestamp, and an admin can restore it the whole time. Only after 90 days (or a manual early purge) is the record permanently removed.

What "soft-delete" actually does

When you click Delete on a regulated record:

1. The system marks the record deleted, stamping the time and the user who clicked Delete.
2. A deleted event is appended to the record's History tab with your name, role, and the timestamp.
3. The record stops appearing in normal views — the application filters it out everywhere, and an independent database-level access rule blocks it as a backstop. (Two layers of defense for the audit posture.)
4. The record surfaces in Trash, available to admins with the Manage trash permission for 90 days.

Behavior the user sees:

• The record is gone from the list page they were on, from search, from picker dropdowns, from cross-module reports.
• Existing references to the record (a link from another module, a Document Downloads entry) typically render as (deleted) rather than breaking.
• The record's direct URL still exists but resolves to a "this record has been deleted" notice unless the viewer has admin access.

Restore — what comes back

When an admin clicks Restore in Trash:

• The deletion marks are cleared on the record.
• The record reappears in lists, search, and pickers immediately.
• Cross-module links reconnect automatically — every link that pointed to (or from) this record was preserved during the trash window and is functional again. A "this NCR is linked to MOC-2026-0119" relationship that existed before the delete is intact after the restore.
• Attachments, comments, History entries, approval state, version history are all restored together. None of these were ever stripped during the trash window — they were just associated with a hidden record.
• A Restored event is appended to the History tab so the lifecycle reads deleted → restored clearly.

What does not come back: nothing. The record is restored to the state it was in the moment you deleted it, including any in-flight approval steps or pending comments.

Why some records can't be deleted at all

The system blocks delete on a small set of terminal-status records — the records that represent decisions everyone in the org is meant to be able to rely on:

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

For these, the Delete button is hidden or disabled. They're meant to live in the system forever as the historical record of a decision. If you genuinely need to remove one (a mis-imported obsolete doc, an MOC closed in error), you'd revert it back to an earlier non-terminal status first — which is itself a logged event — and delete from there.

This isn't an arbitrary safety rail; it's a regulatory posture. A signed approval that disappears later is a chain-of-custody break. Soft-delete protects the in-flight records you might want back; terminal-status records get protected differently — by not being deletable at all.

Why some lifecycle records aren't in Trash

Two notable exceptions to the soft-delete pattern:

• Suppliers and clients use an Inactive flag instead. Their list page has a Show inactive toggle; an inactive supplier still appears with a badge, and an admin can reactivate from the detail page. The naming overlap with deletion is historical — the concept here is "inactive since," not "in trash."
• Risks with active cross-module linkage can't be deleted at all. If a risk is referenced by an open MOC, FMEA, or NCR, the delete is blocked outright until the linkage is removed. The existing linkage gate is preserved on top of the soft-delete pattern.

After the 90-day window

If a deleted record isn't restored within 90 days (or is manually purged sooner), the daily auto-purge permanently removes it:

• The record itself and its child content (history entries, version snapshots, etc.) are deleted.
• Cross-module references from attachments, links between records, notifications, and Ask the Library conversation links are cleaned up.
• The activity log entries for the record's lifecycle stay behind. That's where "did this record ever exist?" gets answered post-purge.

Storage objects (external-document PDFs, image attachments) aren't always cleaned at purge time — that's a known limitation. See the Trash article for details.

Inspector framing — why this matters

Two §11.10(e) audit-trail commitments are reinforced by the soft-delete design:

• Every regulated-record lifecycle event is captured, including deletion. A hard-delete world makes "who deleted this and when?" impossible to answer once the record is gone. Soft-delete makes it the History tab's job — and the History tab is append-only, protected at the application, database, and immutability-rule layers.
• The deletion can be undone for 90 days without breaking referential integrity. A regulator asking "was this NCR really lost?" gets either a "yes, here it is, here's its restore record" or a "yes it was purged on date X, here's the activity-log trail of the lifecycle" — never a "we don't know."

Related

• Trash — the operational page where deleted records live
• Record history — where delete and restore events appear on each record
• Audit log access — admin viewer for who has read trash and history
• Roles & permissions — the Manage trash permission