How to Automate HR Onboarding and Offboarding Without Tickets

Your HRIS knows a new hire's start date weeks ahead. Too often, IT finds out on the first morning, when the new hire messages the help desk from a phone because the laptop won't sign in. Email and chat come through by lunch, and the rest of the team's apps trickle in over the next few days.

To automate HR onboarding and offboarding, connect your HRIS to the platform that governs access, so hire, change, and termination records grant, adjust, and revoke access on their own. The HRIS keeps automating the forms, payroll, and equipment work it already handles well.

Those lost days happen because nothing connects HR's record to access. Connect the two, and the record's loose ends become the risk, like a start date that moves, a transfer nobody re-scopes, or a termination entered late. Fixing both starts with a contract between HR and IT that covers which HR fields can change access, when each change fires, and what happens when the record is wrong. In this article, you will learn which HR fields should change access, when access should start, shift, and end, how to reach apps outside single sign-on, and what evidence satisfies an audit sample.

Make the HR record the trigger for every access change

Start each access change from an event in your HRIS, and keep every decision about what that event means in the platform that governs access. That split keeps access logic out of a tool built to track people and pay them.

Access is where HR templates fall short. When an HR platform's onboarding template includes a step to set up Salesforce, it creates a task for IT, which is a ticket with better formatting. You can't automate onboarding and offboarding while a person still reads one tool and types into another.

HR-driven provisioning closes that gap. The HR record decides who exists, what they do, and when they start and leave, and access follows each change to it without a request in between. In practice, it's user provisioning and deprovisioning with the HR record as the requester and your HRIS integration as the messenger.

Your identity provider may offer HR-driven provisioning of its own, and it covers the apps it federates. Its rules usually map HR attributes to groups, so a move adds the new team's groups while roles granted inside each app stay put. Apps outside single sign-on never hear about the change at all. In a workforce identity and access management program, the identity provider signs people in, and identity governance software decides what they should hold.

The first visible change is that nobody files a ticket for a new hire. Lumos Lifecycle Management picks up the hire the moment a start date lands in the HRIS and builds the identity provider account, email, and role-based birthright access before the first sign-in. Albus, our identity AI agent, watches role, department, manager, and status changes and applies the policy you've set when one changes. Tekion, with more than 3,000 employees worldwide, automated its global onboarding across more than 200 apps on Lumos.

All of this depends on how fast HR's events reach the access platform. Check how often your HR data syncs, and if it runs nightly, ask for an immediate trigger for terminations at the very least.

Decide which HR fields are allowed to change access

The contract's first part is a short list of HR fields allowed to change access, each with an owner in HR, because your automation will act on every mistake in them. Once the record is the trigger, a data entry choice becomes an access decision, often made by someone who doesn't know it is one.

HR operations and IT write the list together, naming which fields drive access and what each value means. Job title shouldn't be on it. Titles are free text, so "Sr. Engineer," "Senior Engineer," and "Senior Software Engineer" become three roles, and a rule keyed to title breaks every time someone fixes a typo. Use the job code or job family instead.

‍

HR operations signs the table. A change to any value list, like a new worker type or a renamed status, goes through IT before it ships, the same way a schema change would.

Bring this table to your HRIS lead this week and replace each typical owner with a person's name. Any field nobody will sign for stays out of the automation until someone does.

Give new hires policy-based access before their first sign-in

Build a new hire's access from policy days before the first morning, keyed to their department, job code, and worker type. The common shortcut, setting someone up like a current teammate, copies that teammate's years of accumulated access, including a project she finished long ago and the admin role she picked up during an outage.

Birthright should be the small set everyone in a department and job code needs, with everything else requested and approved. To find it, pull the access of the last five people hired into the same department and job code. Whatever most of them hold is a birthright candidate, and the rest becomes a request. Employee onboarding automation that clones a teammate automates privilege creep along with the setup.

Turning on birthright doesn't shrink what current employees already hold, so run one catch-up review when the new sets go live. Lumos user access review software can auto-approve access that matches birthright, leaving managers to weigh only the extras people picked up over the years. Albus suggests each role's baseline from what most of its peers use, and delta reviews then surface only what's new since the last cycle.

Then tie the policy to the start date. Create the identity when the hire event lands, often two to three weeks out, and build accounts that can receive mail and invitations while sign-in stays off. Turn sign-in on at the local start time, and cancel everything cleanly when HR moves the start date or rescinds the offer. Interns get an end date when their accounts are created.

On the first morning, the setup is already finished. Lumos lifecycle triggers can be keyed to the start date, with accounts and licenses landing on a schedule you set days before day one. For interns and temporary workers, JML workflow orchestration grants time-bound access for a fixed period, starting ahead of the start date if needed.

Roku keyed its birthright rules to department using Workday data, so a new salesperson gets Salesforce automatically, and anything outside birthright goes to the manager and then the app owner. In the first weeks after Roku deployed Lumos, the average time it took employees to get app access fell from 79 hours to 45 minutes.

Birthright sets drift like everything else. Review each one when a department reorganizes or adopts a new standard app, and drop any grant most of the group has stopped using.

Treat every role change as a recertification

When someone changes roles, grant the new access right away and put the old access on a short clock. Transfers go wrong because the new team asks for access loudly and the old team never asks for anything back, so a move only ever adds.

In a joiner mover leaver (JML) process, that one-way pull makes the mover the hardest part of JML, and a team that handles movers by ticket inherits it. NIST already treats a transfer as a review. Control PS-5 in NIST SP 800-53 Rev. 5 asks you to review and confirm the ongoing operational need for someone's current access when they're reassigned or transferred, modify it to match, and start the transfer actions within a period you define.

Automation is how that review happens on every move. A department or job code change recomputes birthright, and a manager change re-routes approvals and reviews. Access outside the new birthright set gets a handover window (14 days is a reasonable start) and then ends unless the new manager re-approves it item by item. Moves HR never records, like an acting role or a six-week project, get time-bound grants with an end date.

Our own IT team used to run movers through Jira tickets, contacting app owners one by one. Now that we've put Lumos to work on our own lifecycle, a department change in the HRIS produces the list of access to remove or reassign. That list goes straight to each app owner, with no ticket filed.

The number to watch for movers is the share of moves that removed nothing, because that's privilege creep as it happens. A falling share means old access is ending on schedule.

Time each offboarding to how the person is leaving

The contract's second part decides when access ends, and that depends on how the person is leaving. For most departures, it's a scheduled time on the last day. A high-risk involuntary termination needs two steps, a confidential heads-up from HR to security so someone can review the person's recent work, then a disable timed to the start of the conversation. A 2025 federal sentencing shows why the review comes first.

According to the Justice Department, a software developer at an Ohio-based company had planted code by August 2019 that included a kill switch. The code, named IsDLEnabledinAD, checked whether his own Active Directory account was still enabled and would lock out every user once it wasn't. It fired on September 9, 2019, when he was placed on leave and asked to hand in his laptop, and hit thousands of users worldwide. He was sentenced in August 2025 to four years in prison.

Code like that watches for the disable, so it runs the moment the account goes dark. The useful window was before the disable, when a review could still find what he'd built. For a high-risk departure, look at scheduled jobs, scripts, and code that reference the person's own account ahead of the meeting, then disable. That review changes with the job, because how to offboard an employee depends on what their role let them build, from an engineer's scripts to a finance lead's payment approvals.

Offboarding automation should carry a written timing rule for each way people leave. Here's a starting set to adapt with HR and legal.

‍

Your own automation can tip someone off, too, if a lifecycle change emails them before the meeting. Check what each app sends when an account is suspended or disabled, and turn off notices to the affected employee for lifecycle-driven changes.

Remove the access your identity provider never granted

Disabling someone in your identity provider ends single sign-on, and every local account, unfederated app, and token already issued keeps working until you remove it. Add cloud consoles with their own users, break-glass accounts, and sessions already open, and the list outgrows any employee offboarding checklist that isn't built from the person's live access.

To automate offboarding all the way, the leaver event has to reach each of these. Cut privileged access and open sessions first, then shared credentials, then everything else, so the riskiest access ends soonest.

What the person owned is a separate job. Their mailbox and files need a new owner, and so do the service accounts and OAuth grants they set up, while personal access tokens need their work moved to a service credential before revocation. An automated non-human identity lifecycle handles that machine-side hand-off from the same leaver event. AI agents need the closest look, because they keep running on keys and tokens the person created in other apps until AI agent offboarding moves each one to a successor on new credentials.

One leaver event should reach every app the person could sign in to. The Lumos leaver workflow revokes access at once in the apps your identity provider never touched, including local accounts and on-premises apps, which it reaches through direct API or browser agents. Any removal that fails becomes an error task with retries and a workflow record for someone to close.

Compare last week's HR terminations against each app's active account list, starting with the apps outside SSO. Every name on both lists is a gap your IT offboarding process hasn't closed.

Stop bad HR data from becoming an access event

The contract's last part covers what happens when the record is wrong. A bad HR export looks exactly like a good one to the sync that reads it, so HR-driven automation needs brakes before it runs unattended. Five errors deserve a rule before go-live.

1. A mass change. An integration update or a bad import marks a large share of the workforce terminated, and the automation offboards them before anyone reads the alert.
2. A conversion. A contractor becomes an employee, HR records a termination and a new hire, and the person loses everything for a day. Match people on a persistent identifier and treat a conversion as a role change.
3. A rehire. A returning employee gets a new worker ID, or old accounts reactivate with stale access. Start every rehire from today's birthright policy and never restore old access wholesale.
4. A late or backdated termination. The termination date has already passed when the record lands, so removal fires at once. Flag the gap and review the person's activity between the date and the entry.
5. A leave keyed as a termination. Suspend first and delete after a quiet period, so a keying error stays reversible.

Lumos Sync Circuit Breakers, on by default, stop the first error before a sync writes anything. They trip when 50% of an app's active accounts would deactivate or go missing, or when a source returns zero accounts. On apps matched to your identities, a third breaker trips when 50% of active identities would move to a terminated status, and every threshold change requires a reason and lands in the Activity Log. We'd rather a person look at any sync that wants to terminate half the company.

Set your own cap from normal volume, whatever tool you use. A bad import that marks 30% of staff terminated would slip under a 50% threshold, so hold any run that would terminate more than a few times your usual daily count.

In a staging tenant, feed the automation an HR export with most of the workforce terminated, and confirm nothing gets removed. Then run a conversion, a rehire, and a backdated termination through it, since no mass-change brake will catch those.

Prove every hire, move, and departure finished

Each hire, move, and departure needs a timestamped record an auditor can match against the HR entry that started it. SOX IT general controls and SOC 2 testing commonly sample terminations and compare each removal timestamp with the HR termination date, so your evidence has to show both.

Four numbers tell you whether the automation works. Track how many birthright apps were ready at each new hire's start time, and the share of moves that removed nothing. Then track time from termination to the last account removed, and the count of active accounts with no matching active HR record. Trace each of those accounts to the cause that let it survive, a habit that belongs at the top of your employee offboarding best practices.

Access reviews face the same test, and Sun Country Airlines knows the manual version. After the airline went public in 2022 and SOX became a requirement, its reviews ran on screenshots, Excel, and email, and every removal needed a ticket plus a second screenshot to prove it happened. With Lumos, rejected access can be revoked automatically, or the evidence of its removal attached to the review.

Onboarding and offboarding automation that can't put the HR timestamp and the removal timestamp side by side hasn't retired the screenshots, only moved them. The worst gap between the two deserves the most attention, because it's the one an auditor finds first.

Run access from the HR record and keep people on the exceptions

Your HR record already knows who's joining, who's moving, and who's leaving. Once that record is trustworthy and all three parts of the contract are signed, the rest of how to automate onboarding and offboarding is writing rules that let it act.

Start with one department, and run the automation in report-only mode for a cycle so you can see every change it would make before it makes one. After that, people stay on the judgment calls, from high-risk terminations to anything a circuit breaker halts.

This month, list every place access is granted from an HR email or a ticket, sign the field table and the departure table with HR and legal, and derive birthright sets from recent hires. This quarter, turn on start-date provisioning, the mover clock, and the brakes, then measure every event against its HR timestamp. IT should hear about a new hire from the HR record, not from the new hire.

Somewhere in your HRIS, a termination is already scheduled. If access still waits on a ticket, that person keeps signing in after their last day, and the new hire starting that week waits for apps. Your auditor will sample one of them, and so will anyone hunting for an account nobody closed. Book a demo to see Lumos JML workflow orchestration close both from the HR record, in every app your identity provider never touched, on native connectors that go live in weeks.

‍

‍