How to build employee offboarding deprovisioning

What matters here

• Disabling the identity provider is not offboarding. Local accounts, API keys and personal integrations all survive it.
• Transfer before you disable. Files, calendars, workflow ownership and open records become unreachable the moment the account goes.
• Reconcile against every system instead of trusting the revoke call. A revocation that silently failed looks identical to one that worked.
• Handle the immediate case separately. A hostile departure is minutes, not a scheduled job at midnight.
• Report people who left and still hold access. That number should be zero, and if nobody produces it, it never is.

Who this is for

You run IT operations or security. Offboarding runs on a ticket somebody raises, coverage depends on who remembers which systems, and the last access review found accounts belonging to people who left last year.

How it works in practice

The path from a resignation to the access actually being gone.

1. 1

   The HRIS termination record starts the clock

   Leave date and type: standard notice, immediate, or contractor expiry. The type decides the timing.

2. 2

   Everything the person owns is inventoried first

   Files, calendars, workflow ownership, open records, API keys and personal integrations, before anything is disabled.

3. 3

   Ownership is transferred while the account still works

   A file transfer after the mailbox is disabled is a support ticket and sometimes a data loss.

4. 4

   Revocation runs across every system, not only identity

   Federated access, local accounts, API tokens, shared credentials the person knew, and anything with a personal integration.

5. 5

   Each revocation is verified, not assumed

   The call returning success and the access actually being gone are different facts.

6. 6

   A standing report lists anybody who left and still holds access

   It should read zero, and it will not on the first run.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then inventory what a person can actually hold

   You cannot revoke what you never enumerated.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow. The systems in play are Workday, Okta, Google
   Workspace, Salesforce, Jamf, Jira and Snowflake, or whatever we run in
   those seats. Before you plan anything, tell me which of them are
   already authenticated in the workspace, because I do not want a
   connector stubbed that I have not authenticated.
   
   The detail that matters most is Okta and every system that has
   local accounts, not federated ones. I need to know, for each system,
   whether access is federated, local, or both, and how API tokens are
   issued and revoked.
   
   Build me the inventory of what one person can hold. Anything not on that
   list will survive offboarding, so it is the most important artefact
   here.

2. 2

   Transfer ownership before disabling anything

   Because after the account is gone, a transfer is a support ticket.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow. Trigger on a Workday termination record.
   
   Before any revocation, inventory and transfer:
   
     Drive files and folders, to the manager unless a successor is named
     Calendar ownership for recurring meetings the person organised
     Any workflow, integration or scheduled job they own
     Open Salesforce opportunities, cases and tasks
     Jira tickets assigned or reported
     Shared mailbox and distribution list memberships
     Any API token or service account created under their name
   
   Transfer while the account still works. A file whose only owner is a
   disabled account is a support request and occasionally a data loss.

   Workflow and integration ownership is the one most often missed. A scheduled job owned by a leaver keeps running until it needs a credential refresh, then fails at the worst moment.

3. 3

   Revoke everywhere, in the right order

   The identity provider is the first system, not the only one.

   Copy

   Now revoke, ordered so nothing locks you out of the next step:
   
     1. Sessions and refresh tokens, so an open laptop stops working now
     2. API tokens and personal access tokens across every system
     3. Federated application access through Okta
     4. Local accounts in systems that do not federate, one at a time
     5. Shared credentials the person had access to, flagged for rotation
     6. The identity itself, suspended rather than deleted
     7. The device, remote locked and wiped
   
   Suspend rather than delete. Deleting an identity often orphans the audit
   trail attached to it, and that is the record you will need.

4. 4

   Handle the immediate departure as its own path

   Because a hostile exit is measured in minutes.

   Headless skills tray-gotchas tray-patterns

   Copy

   Use tray-gotchas, then build a separate immediate path.
   
   When the termination type is immediate, revocation runs first and
   transfer happens afterwards from an admin context. Sessions and tokens
   die within minutes, not at midnight on the leave date.
   
   Also handle these:
   
     Notice period. Access continues until the leave date, then goes at a
     specific time, not whenever a nightly job runs.
   
     Contractor expiry. The end date is known at the start, so schedule it
     then rather than hoping somebody raises a ticket.
   
     Rehire. The suspended identity may return. Never restore it with its
     historical access intact; re-derive from the current role profile.

5. 5

   Verify, and report the ones still holding access

   A revoke call returning success and the access being gone are different facts.

   Copy

   After each revocation, verify against the system rather than trusting the
   response. Query the access back and confirm it is gone.
   
   Then produce a standing report: every person with a termination date in
   the last 12 months who still appears in any connected system. Include
   what they hold and how long it has been.
   
   That report should read zero. It will not on the first run, and the
   first run is the point. Alert on any non-zero value instead of emailing
   it into a folder.

6. 6

   Check it end to end, then hand it to IT

   So a new system joining the estate joins the offboarding path too.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so IT operations can add a
   system to the coverage list in the visual canvas. New tools are adopted
   constantly, and every one of them that is not on the list is an account
   that survives somebody leaving.

What it connects to

Offboarding has to reach every system a person could hold, which is more than the ones that federate.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides