The Documents You Will Wish You Had Copied

Take a copy on the last day of anything that lives in a system that will change, because a reference to where a record lives is not a record. The rota system is replaced, the messaging history rolls off after ninety days, the intranet page is edited in place, and the thing the organisation needed turns out to have been overwritten by its own successor.

The recordkeeping discipline in “The Documents You Will Wish You Had Copied” should also apply to workforce technology. When a team assesses a practical route to remote workforce management software in relation to remote workforce management software, it should document purpose, access, retention and deletion, then preserve only the evidence needed for the handover, payment or review decision.

This is the quietest failure in the whole exit process. Nothing goes wrong at the time, and two years later a position that was perfectly evidenced cannot be evidenced at all.

For an independent reference relevant to “The Documents You Will Wish You Had Copied”, consult the IAPP employee-monitoring resources. Use it to test record quality, access, retention, fair process and exception handling against the organisation’s real departure workflow.

What has a limited life

• Messaging platforms, where history is often retained for a fixed and short period.
• Rota, scheduling and time systems, which get replaced every few years.
• Access and door logs, which are usually retained for weeks rather than years.
• Intranet policy pages, which are edited rather than versioned.
• Vendor and third-party systems, where retention is set by somebody else.
• Mailboxes, which may be deleted on a schedule of their own.
• Call and ticket systems, where records attach to an account that gets disabled.

Each of those is a plausible source of evidence in a dispute about hours, conduct, instructions or what somebody was told. Each disappears on a timetable nobody involved in the exit knows.

The policy version problem

A policy relied on in a process has to be produced in the version that applied. An intranet page cannot do that: it shows what the rule is now.

Taking a dated copy at the point it is relied on, and filing it, solves this for the case in hand. Keeping an archive of superseded versions solves it generally, and is one of the cheapest things on this site to start doing.

Message threads

Conversations in a messaging platform are frequently the clearest evidence of what was asked, when, and what was said in response — and they are also the most likely to vanish, because retention is set centrally and nobody thinks about it when somebody leaves.

Where a thread matters, export it with its metadata rather than screenshotting it. A screenshot of a conversation is weak evidence and an export is not much more work, which is a distinction worth knowing before it is needed rather than afterwards.

Taking the copy properly

A copy that is worth having carries its own context: what system it came from, the date range, who extracted it, when, and what it is. A folder of undated screenshots is barely better than nothing.

Where a record is extracted for a process, the extraction should itself be recorded. If the question later is whether the record was complete or selective, the answer is in how it was taken.

Deciding what to copy

Not everything, which is the reason this fails — the instruction "copy anything that might matter" produces either nothing or an unusable archive.

The practical rule is narrower: copy what was relied on, what was disputed, and anything in a system with a retention period shorter than the file's. Three categories, and the third is the one that requires somebody to know what the retention periods actually are.

Who does it

Not HR, in most cases, because HR has no access to the rota system, the door logs or the messaging export. The copy has to be requested from whoever owns the system, which means it has to be on the checklist as a line with a named owner and a date.

Requested after the last day, it may already be too late — and the gap between the last day and somebody realising they need a record is reliably longer than the shortest retention period in the estate.

Asking the system owners once

Nobody in a people function knows how long the door-access system keeps its logs, and nobody in facilities knows why it would matter. The information exists and has never been exchanged.

Ask every system owner once: what do you hold about individuals, and for how long? The answers fit on a page, they are useful for several purposes beyond this one, and they make it possible to know which records have to be copied at an exit and which can be left where they are.

What this is really about

Every item here is an instance of one pattern: the organisation's memory is distributed across systems that each have their own idea of how long things last, and an exit is the moment that distribution matters.

Nobody designed it that way and nobody owns the whole of it. The exit checklist is the only place where the question gets asked at all, which is why the copy has to be taken then. It cannot be retrofitted, and the discovery that it cannot always arrives at the worst possible time.