Skip to main content

​
Retention policies

A policy is the unit of “delete these documents after this long”. You’ll typically build the first few policies during setup, then leave day-to-day editing to your super-users.

​
What’s on a policy

The policy editor is organised into General, Criteria, Approval, and Advanced tabs.
When Requires approval is on, always configure at least one approver group. A policy that requires approval but has no approver groups will accept approval from anyone who holds the approvals permission, which defeats the gate.

​
Matching criteria

The criteria editor builds a matching expression from these building blocks, either in a visual tree editor or as JSON. Combine them with AND, OR, and NOT groups. An All documents rule must include at least one exclusion — a rule that would match every document with no exclusions is rejected, so you can’t accidentally target the whole archive. Validation runs as you build. Warnings (for example, “this matches every active document”) surface inline; hard errors block saving.

​
Editing a policy

Every save creates a new version of the policy, and previous versions are kept so you can see how a policy changed over time. When an edit changes the criteria, the editor asks how to treat documents the policy is already tracking:
  • Preserve existing document states — documents already tagged continue under the new version. Safe default.
  • Re-evaluate all documents — drop the policy’s currently tagged documents and let the next processing cycle re-tag against the new criteria.
Documents that have already moved past Tagged — pending approval, approved, deleted, rescued, excluded, or quarantined — are never re-evaluated either way, so an in-flight approval batch or a deletion history is never disturbed.
Retention policy editor showing the criteria tree with the Policy Criteria Changed prompt offering Re-evaluate or Preserve

​
Calculate the period from a business date

In General → Retention period calculated from, choose Document Date, Stored Date, or an available date keyword. Use a business-date keyword when the retention rule starts from a date such as Contract end date, rather than when the file was created or stored. For a seven-year period from Contract end date, select that keyword and enter seven years. The resulting cutoff still combines with the rest of the policy criteria; selecting a keyword does not bypass them. Simulate documents with different document, stored, and business dates. Include a missing business date and any repeating date values so you can confirm eligibility before enabling the policy. Use is empty or is not empty keyword criteria when presence itself matters; these operators do not take a comparison value.

​
Simulation

Run a simulation before enabling any new or materially changed policy. Simulations are read-only — they tag nothing and delete nothing. A simulation reports:
  • The total number of documents the policy would tag
  • A sample you can spot-check
  • A flag when the sample was capped
When the sample is capped, read the total to judge real impact, not the size of the sample. Review both before enabling the policy.
Retention simulation result showing the total number of matched documents and a sample table

Approvals, holds & quarantine

How approval batches gate deletions, the three ways to stop a deletion — rescue, exclude, and legal hold — and how to handle quarantined documents.