Retention Schedules

A retention schedule says how long a kind of record is kept and from when. It is the difference between a policy and a document describing a policy.

Where to find it

These features have no dedicated Architect Panel section of their own. They are configured through their datastores, opened from All Datastores, and most of what a caseworker sees appears on the record itself rather than on an admin screen.

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 — the trigger determines the date, and getting it wrong is how records are destroyed early or kept for decades.

Map to your existing schedule

Most organisations already have a retention schedule written by somebody who understood the obligations. Implement that rather than inventing one here. Where it is ambiguous, that ambiguity is worth resolving with the person who owns it before it is encoded.

Review before disposal

Configure a review step for anything consequential. Disposal is irreversible, and a schedule that goes straight from due to destroyed gives nobody the chance to notice that a case is still live. The review should be a real look, not a bulk approve.

The task

The Retention and Disposal task assesses what is due, raises reviews and carries out disposal. It ships disabled and runs daily. Enable it only once your schedules and review steps are configured and tested — this is the one task whose mistakes cannot be undone.

Test it on something safe

Run it against a small, non-sensitive category first and confirm what it proposes matches what you expect. A schedule with the wrong trigger looks completely reasonable right up until it disposes of the wrong thing.