A checklist with no owner on the day it matters
Onboarding a new hire is visible. Somebody is waiting for a mailbox and a calendar, so a gap gets fixed within hours. Offboarding has no such feedback loop. The employee is gone, the manager has moved on, and a step that never ran looks exactly like one that did.
That is why the failures are quiet. A former employee keeps a login the SSO revocation missed. A shared drive loses its owner, and the team finds out weeks later when a document cannot be opened. A paid seat keeps billing into the next quarter. A written runbook depends on a person working it by hand on a day they are already busy. A ticket queue splits the same steps across several people and several days.
The steps themselves are small. Finishing all of them, in order, on the day of the departure, is the part that gets dropped. Hand that part to something that runs the same list every time and reports what it did not finish. The two workflows below are ones Kortix's own team runs, and both stop where a person has to confirm.
Onboarding starts from the record, and the access waits
A new-hire record fires a signed webhook into the project. Each firing starts a fresh session, seeded with the role, the team and the start date. One hire gets one run, and nothing carries over from the last one.
The agent reads the role. It prepares the Google Workspace account with the aliases and group memberships that role calls for. It invites the person to the Slack channels their team works in. It files a first-week checklist as a Linear project.
Two of those steps grant access, so both wait. Account creation and group membership stop at an approval gate before anything is provisioned. A person confirms the account and the memberships in one place. The new hire arrives on day one with access somebody signed off on. The standard for which groups a role needs lives in the agent's skills, where the next run reads it.
Offboarding runs from a scheduled check across four systems
The departure signal is an Okta group that HR adds people to. The agent reads that group on a schedule, so access starts coming down the same day a departure is marked. Nobody has to remember the ticket.
Each check starts its own session, and every new departure it finds becomes its own case. Five leavers in one week are five runs. One isolated sandbox per session. Each session has its own isolated machine and branch.
For each case, the agent works one checklist. It revokes SSO in Okta and pulls the app assignments that hang off the account. It removes the person from the GitHub org and its teams. It reassigns document and shared-drive ownership in Google Drive, then suspends the Workspace account. It releases the paid seats across the connected tools. Then it posts the completed checklist, with every step it took and every step still pending with a person.
The handover waits, and deletion stays out of scope
Transferring ownership away from a person stops at a human approval gate. Documents change hands, and a mistaken handover is expensive to unwind, so a person confirms it before it runs. Every reversible step around it completes on its own.
Account deletion is never part of the checklist, gated or otherwise. The workflow suspends the account, which ends access and keeps the record. A deletion that is genuinely needed goes to a person outside this run. That line is deliberate. Deleting is the one step on a departure list that cannot be checked afterwards, and it is the step nobody needs the agent to take.
What a person is still deciding
Four calls stay with the HR team. A person approves the account and the memberships that give a new hire access. A person approves the transfer of a drive. A person handles the deletion case, along with the exceptions the checklist cannot reason about: someone on parental leave, a contractor with no Okta record, a shared mailbox two teams were using. And a person owns the policy itself, meaning which systems are in scope, the order to work them in, which steps are reversible, and how ownership should be reassigned.
That last one is the work that improves the run. When an exception exposes a missing rule, the rule gets written once, and the next departure picks it up.
Connectors into the systems that already hold the record
The reach comes from connectors to Okta, Google Workspace, Google Drive and GitHub, plus Slack and Linear on the onboarding side. Nothing is migrated. The HR record stays in the HR system and Okta stays the identity provider. The work moves to an agent that can reach the systems the record cannot. That is a shorter project than a new suite, and the systems of record stay where the rest of the company expects them.
What does move is the policy. The checklist, the order of steps, the reversibility notes and the reassignment rule sit in the project with the agent, in files the team edits. Per-resource permissions for people and agents. Roles, groups, and an audit trail. Who may revoke access in Okta is a line in that configuration, so a reviewer can diff it. A dashboard edit can commit to the default branch without a merge, and the repository still holds the version to compare. Approval gates you set. Off until you set them. The gate belongs on the handover and on any call that provisions an account.
Where Okta's own lifecycle work ends
Okta documents rule-based lifecycle work on the identity side. Account creation, updates and deactivation are set per application, and changes can be triggered from HR or IT systems. The catalog lists 6,500+ applications (okta.com). Its Google Workspace entry adds authentication and provisioning. Connector actions there include suspending an account or assigning a license, and the workflow templates include one that reassigns Drive files during deprovisioning (okta.com).
Read those pages closely and the shape is clear. Okta supplies the identity event and a rule for each application. The drive handover or the license step arrives as a workflow a team assembles and maintains. For a company whose departure work sits entirely inside identity, that is enough. The gap opens further out. The run has to decide which groups a role needs from a written standard. It has to work four systems in one order, file the checklist where the team will read it, and name what is still pending. That run needs a policy file and an agent that follows it.
The record a departure leaves
Each run ends with a page. It lists what was revoked, what changed hands, what was reclaimed, what waits on a person, and who approved it. A month later that page answers the question an auditor or a manager asks, without anyone reconstructing it from memory. The governance page covers how the approvals, roles and files fit together.
The checklist, the policy behind it and the permissions it runs under are files in a repository the company owns. Open source. Read it, fork it, audit it.