Playbook · for IT & people ops
Employee Onboarding and Offboarding Automation: the IT Playbook
8 min read · Last reviewed August 2026
Key takeaways
- Onboarding and offboarding are the most automatable workflows in IT: known trigger, known steps, known owner for every step.
- The access matrix — role × systems × permission level — is the artifact that turns both into checklists.
- Offboarding is the security-critical half, and the half nobody files tickets for; it must trigger from the HR event, not from memory.
- Every provisioning and deprovisioning action belongs on a ticket timeline — access changes are exactly what auditors ask about.
Reading is free — the full guide is right below. Want it as a PDF to share with your team?
Ask an IT queue what a new hire looks like and it answers precisely: an account request, a laptop request, four access requests filed over two weeks as the person discovers what they cannot open, a mailing-list add, and a "my badge doesn’t work" — most filed as separate tickets, several urgent, all identical to last month’s batch.
This is the most automatable work an internal queue contains. The trigger is known in advance (the HR system knows the start date), the steps are enumerable, and every step has an owner. The same is true of offboarding, with one difference that changes its priority: onboarding failures cost productivity, offboarding failures cost security.
Build the access matrix first
The prerequisite for automating either flow is a boring spreadsheet: roles down one axis, systems across the other, permission level in each cell. An engineer gets repo access, staging credentials, the error tracker, and the on-call tool; a salesperson gets the CRM and the demo environment; everyone gets email, chat, and the HR portal.
The matrix does three jobs. It turns "what does this person need" from a judgment call into a lookup. It makes exceptions visible — every access grant outside the matrix is now a decision someone owns instead of a favour someone forgot. And it is the deprovisioning list read backwards: what was granted is exactly what must be revoked.
Onboarding: one trigger, one checklist, many owners
The shape that works: the HR event (offer signed, start date set) opens one parent ticket carrying the role’s checklist from the matrix. Each item is a task with an owner and a deadline keyed to the start date — accounts by day minus three, hardware ordered by day minus ten, access grants on day one, not before.
Automate the steps that are API calls: identity-provider account creation, group memberships, license assignment, standard app grants. What cannot be automated stays human but tracked — the checklist means nothing falls to memory, and the parent ticket means the hiring manager has one place to look instead of six tickets to chase. The day-one test of the whole flow: the new person opens their laptop and everything works, having filed zero tickets.
Offboarding: the half that must not depend on memory
Nobody files an offboarding ticket. The departing person has no incentive, the manager is busy, and IT often learns about a departure in the hallway. Meanwhile every day between departure and deprovisioning is a day a former employee’s credentials still work — which is not a productivity gap but an open door.
So offboarding cannot be request-driven; it must trigger from the HR event automatically. The checklist is the access matrix reversed, executed in security order: identity-provider account disabled first — which cascades through everything behind SSO — then the non-SSO stragglers (the tools someone signed up for with email and a credit card), shared-credential rotation where the person had them, device return and wipe, and finally the transfer items: file ownership, calendar handoffs, the on-call rotation slot.
The non-SSO stragglers are where offboarding actually fails, and the fix is upstream: every tool procurement goes through the matrix, or it does not officially exist. Shadow tools are unfindable at offboarding time by definition.
Put it on the queue, with an audit trail
Run both flows through the ticketing system rather than beside it — not for bureaucracy, but because access changes are precisely the events an auditor, a SOC 2 assessment, or an incident investigation will ask about. Who got access to what, when, granted by whom, revoked when: if the answer lives in a ticket timeline, the audit is a query; if it lives in Slack DMs, it is a reconstruction project.
This is also a natural fit for allow-listed automation. Standard grants from the matrix are exactly the reversible, well-trodden, verifiable actions that belong on an AI allow-list — FlowTux can run the routine provisioning steps automatically with every action logged on the ticket, while anything outside the matrix (an exception grant, an early access request, anything touching production) routes to a human with the context attached. The checklist runs itself; the judgment calls stay judged.