Retention Schedules
A retention schedule says how long a kind of record is kept and from when. It is the difference between having a retention policy and operating one.
Where to find it
Architect Panel → Data:
- Retention & Disposal — the console — what is due, what is held, what has gone
- Retention Schedules — the schedules themselves
- Record Retention — the per-record retention state
- Destruction Certificates — the evidence that disposal happened
The trigger matters as much as the period
"Seven years" is meaningless without saying seven years from what. Case closure, last activity, a child reaching 25, the end of a contract, date of death — the trigger determines the date, and choosing the wrong one is how records are destroyed years early or kept for decades.
Write the trigger down in the schedule's description as well as configuring it. The person reviewing this in five years will not be you.
Implement the schedule you already have
Most organisations already have a retention schedule written by somebody who understood the legal obligations. Implement that rather than inventing one here. Where it is ambiguous, resolve the ambiguity with whoever owns it before encoding it — a configuration is a decision, and encoding an ambiguity just hides who made it.
Review before disposal
Configure a review step for anything consequential. Disposal is irreversible, and a schedule that runs straight from due to destroyed gives nobody the chance to notice that a case is still live, subject to a complaint, or about to be needed.
The review should be a genuine look. A queue of four hundred items with an "approve all" button is not a review, so size the batches to what a person can actually assess.
Destruction certificates
What is destroyed leaves a certificate: what, when, under which schedule, authorised by whom. That record is what demonstrates the policy operates, and it is what an information request or an audit will ask for.
This is not in tension with disposal. The certificate holds the fact of destruction and its authority — not the content that was destroyed.
Worked example — a council
Planning applications are kept permanently. Complaints are kept six years from closure. Safeguarding records are kept until the subject reaches 25, so the trigger is a date of birth on the record rather than closure. Each schedule has a review step, and the reviews are worked monthly by the information governance officer in batches of no more than fifty.
Test on something safe first
Run the schedule against a small, non-sensitive category and confirm what it proposes matches what you expect. A schedule with the wrong trigger looks entirely reasonable right up until it disposes of the wrong thing — and by then there is nothing to inspect.
Recommendations
- Start in preview. Read what it would do for a full cycle before arming anything.
- One schedule per genuinely different rule, not per datastore. Two datastores with the same rule share a schedule.
- Review the schedule annually against your published policy — they drift apart quietly.
- Never disable a review step to clear a backlog. The backlog is the review working.