Employee offboarding

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Offboard: departing engineer (last day Friday)

  Parent issue; sub-issues cover SSO, repos, laptop, and handover.

  P13pt

• Revoke all SSO and admin access

  • security
  P01pt

• Reassign owned issues and docs

  P22pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Offboarding initiated

  Then

  Generate the access-revocation and asset-return checklists

• When

  Last day reached with access not revoked

  Then

  Escalate to security immediately

Access revocation is the second column, before asset return and before knowledge transfer, and the ordering is the point. Everything else on this board can slip a week without consequence; credentials that outlive employment are a security finding, an audit exception, and occasionally an incident. The board is arranged so the irreversible-risk work happens first and the recoverable work happens after, which is the opposite of how offboarding naturally runs — the laptop is visible and the forgotten API token is not.

1. 1.Open the card the day notice is given

   Offboarding has lead time too: knowledge transfer needs weeks, not the final afternoon, and access revocation needs a complete list assembled in advance. Starting on the last day guarantees the handover is a rushed document nobody reads. For involuntary departures the timeline compresses to hours, which is exactly why the checklist must already exist.

2. 2.Revoke from a real inventory, not from memory

   Single sign-on covers the applications behind it and nothing else. The gaps are the accounts that live outside it: production database credentials, cloud provider access, API tokens, shared password vault entries, code repositories, package registries, third-party tools bought on a card. Maintain that list as an artifact between departures, because reconstructing it under time pressure is how something gets missed.

3. 3.Treat shared credentials as compromised

   If the leaver knew a shared password, a service account, or a signing key, revoking their personal access does nothing. Those need rotation, and rotation usually requires coordination with whoever depends on them. This is the most commonly skipped step in offboarding and the one with the longest tail of risk.

4. 4.Reassign ownership explicitly, not implicitly

   Issues, documents, dashboards, recurring meetings, on-call slots, vendor relationships and any automation running under their account all need a named new owner. Unowned artifacts do not announce themselves; they surface months later when something breaks and nobody knows who to ask. Walk the list with the leaver while they are still available to explain it.

5. 5.Close the card only when every branch is verified

   Closed should mean somebody confirmed each revocation actually took effect, the hardware is physically back, and the handover was received by a named person rather than posted into a channel. The escalation on access lingering past the last day exists because that is the specific failure an auditor will ask about, and because it is the one with real consequences.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• Your identity provider automates deprovisioning. If suspending someone in the HRIS or identity platform cascades to every connected application automatically, that is strictly better than a human checklist — it is faster, complete, and logged. Use the board only for what cannot be automated, such as physical assets and handover.
• The offboarding is contentious or legally sensitive. Terminations involving disputes, investigations or litigation holds need legal guidance on timing, evidence preservation and communication. A standard checklist executed on autopilot can destroy data somebody was obliged to retain.
• Departure details would be broadly visible. The existence of a card naming a departing employee, sometimes before they have told colleagues, is information that leaks. If your workspace cannot restrict this board to the people running the process, keep it somewhere that can.
• You have a dedicated IT service-management tool. ITSM platforms model the joiner-mover-leaver process with approvals, asset records and an audit trail as a first-class workflow. Running a parallel board splits the record of what was actually revoked.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• Okta and identity providers

  The correct place for access revocation is the identity layer, where suspending an account propagates to every federated application at once and produces a log of it. That is a categorically stronger mechanism than a checklist executed by a person under time pressure.

  Where Okta and identity providers is better: Automated deprovisioning is better in every respect — faster, complete, auditable, and immune to human oversight. Anything reachable through your identity provider should be handled there, and this board should only track what is not.

• Rippling and HRIS platforms

  Modern HR platforms tie the employee record to device management and app provisioning, so a termination date triggers account suspension and device wipe from the same action that ends payroll. The unified record means nothing is duplicated between systems.

  Where Rippling and HRIS platforms is better: Having one termination action drive payroll, benefits, access and devices removes the coordination this board is designed to manage. If you have such a platform, its offboarding workflow is the system of record and this is redundant.

• A checklist document

  Most companies offboard from a document, duplicated per departure. It is simple and it works up to a point; the limitation is that a document does not know when a step is overdue, and copies diverge from the master so improvements made during one departure never reach the next.

  Where A checklist document is better: A document is faster to write, easier to review in full, and can explain why each step exists — context a card title cannot carry. For a company doing two departures a year, it is a defensible choice.