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.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.

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

Where to read next
Approvals, holds & quarantine
How approval batches work, the three ways to stop a deletion, and what to do with quarantined documents.
