Leavers — JML off-boarding checklist

For the helpdesk team

Leavers

The leavers console at /agent/people/leavers is the trust’s structured off-boarding surface. When someone leaves, a checklist of standard steps is opened against their engagement; the console drives each step to done (or skipped) and keeps a proof trail for the audit.

Who sees what

Reading the index and a checklist is gated by people::agent — deliberately wide, so a line manager can see what off-boarding looks like for their report. Driving an off-boarding (opening a checklist, completing or skipping items) requires the tighter people::leavers::manage, which is the HR team’s permission.

How a checklist gets opened

A checklist is created against an engagement. It opens automatically when an engagement transitions to ended; HR can also open one manually before that. The action is idempotent — if an open checklist already exists for the engagement, you get that one rather than a duplicate.

The standard checklist

Each new checklist is seeded with the same item set, in workflow order. The first two are automatic — clicking Mark done runs a side-effect — and the rest are manual:

Disable platform account (automatic) — sets users.is_active=false so the account can no longer be used to log in. Existing sessions stay valid until the cookie expires; it’s reversible by an admin.
Revoke MFA enrolment (automatic) — clears the leaver’s two-factor secret, so a future re-activation forces re-enrolment.
Notify line manager — confirm the manager knows the leaving date and handover expectations.
Reclaim IT assets — laptop, phone, peripherals, keys, badge. Capture serials / asset tags in the note.
Hand over open helpdesk tickets — re-assign any tickets, changes or problems still owned by the leaver.
Configure mailbox forwarding — forward to the manager or a shared inbox for a sensible period.
Confirm reference requests handled — route any reference request through HR; record where it was answered.
Hold + minute exit interview — capture feedback in HR’s usual record; attach the minutes in the note.

Working a checklist

On a checklist, each item shows a state badge (pending, done, skipped or failed) and a bolt icon if it carries an automatic side-effect. For each pending (or failed) item you can:

Mark done — for an automatic item this runs the handler; the handler’s result (e.g. “Account deactivated (email …)”) is captured as the item’s proof note. For a manual item, your optional note is the proof.
Skip — records an optional reason and moves the item to skipped.

If an automatic handler throws, the item flips to failed with the error recorded as the note — re-attempt by clicking Mark done again (handlers are safe to retry). A person without a linked platform account is a no-op success for the account/MFA steps — there was nothing to disable.

Auto-closure

When the last pending-or-failed item reaches a terminal state (done or skipped), the checklist closes itself — status moves to completed with the closing user and time recorded. You don’t hunt for a separate close button.

Gotchas

Disabling an account doesn’t delete the user row, by design — soft-deleting would break historic audit-log joins (“who closed this ticket?”). Deactivation gives the security outcome without losing the trail.
Skipping isn’t the same as doing. A skip is recorded with its reason, so an inspector can see why a step didn’t apply rather than it silently vanishing.
Viewing a checklist is itself logged to the access log — the leaver’s off-boarding is sensitive.