When I started, onboarding was fully manual, and I was the person doing it by hand. Create the account, pick the groups, assign the apps, order the laptop, update the ticket. Ten to fifteen minutes per person if nothing went sideways.
Ten to fifteen minutes doesn’t sound like much. Then the company went from around 200 people to around 650, and it stopped being a task and started being a job. Automating it wasn’t a nice-to-have anymore.
Today an onboarding is one click. Someone reviews a message in chat, hits approve, and Okta Workflows does the rest.
The ticket is the trigger
Everything starts with a Jira Service Management ticket. When an onboarding request is created, Jira fires a webhook at Okta Workflows and the sequence begins.
The ticket carries everything the flow needs: first and last name, manager, title, department and team, and a shipping address. The address matters more than you’d think. The workforce is fully remote, so every new hire means a box of equipment going to someone’s house.
Because the ticket is the single source for the request, the flow never has to ask anyone for more information. If it’s in the ticket, the automation can act on it. If it isn’t, the request form is what needs fixing, not the flow.
What onboarding does
The first thing the flow does is work out the username and email address for the new hire and check whether it conflicts with one that already exists. Better to find that out before anything has been created.
Then it stops and asks a person. It posts the details to our messaging platform, where someone on the team reviews them and approves or denies. That’s the one click. It’s deliberate: the automation does the work, but a human still looks at what’s about to happen before it happens.
Once it’s approved, the flow:
- Creates the user in Okta
- Adds them to groups automatically based on department and team
- Lets Okta provision their applications from those group assignments
- Opens a ticket with our hardware vendor to get equipment shipped
The whole time, it’s writing comments back to the Jira ticket: what it did, and the details anyone following along would need. Nobody has to wonder whether the automation ran or where it got to. The ticket tells you.
What offboarding does
Offboarding is essentially the same flow in reverse, with a few steps that only make sense on the way out.
The big one is sessions. Disabling an account doesn’t help much if the person is still signed in somewhere, so the flow revokes active sessions directly in Okta, Google Workspace, and Microsoft Entra. It also sends wipe commands to the user’s devices automatically.
Every offboarding gets written to an Okta table for tracking. A daily report is generated from that and sent to key management, so there’s a regular check that offboardings are happening when they should and finishing completely. An offboarding that quietly half-finishes is the kind of thing you only find out about months later, and by then it’s a problem.
What about movers?
There’s no mover flow, and that’s on purpose. Once someone has officially started, their profile information comes from the HRIS. Name changes, title changes, team changes: HR makes them in the system they already own and they flow through from there. IT isn’t in the middle of it.
The hard parts
Okta Workflows has native connectors for a lot of applications. It doesn’t have them for everything, and several of the ones we needed weren’t covered. For those I wrote custom API requests to fill the gaps. That ended up being a real share of the work: reading each vendor’s API documentation, working out authentication, and getting the calls to behave inside a flow.
The other problem was timing. Some applications are slow to catch up after a change. The flow would create or update something, immediately make the next call, and the application on the other end wouldn’t know about the first change yet. The fix isn’t elegant. There are pauses of a few seconds between certain API calls. It works, and I’d rather have a flow that waits than one that fails at random.
Testing and guardrails
Before any of this went live, I created a set of test accounts and ran them through the flows repeatedly until I trusted what they did.
The guardrails are mostly the tickets themselves. The automation only acts on a ticket, and only HR can submit an offboarding ticket. Nobody else can trigger one. Combined with the approval step on the onboarding side, that means every run starts with a person who’s supposed to be making that decision.
What it bought us
For the past three months we’ve been onboarding around 20 people a week. At ten to fifteen minutes each, that’s three to five hours of service desk time every week spent on account creation alone. Now it’s minutes.
The point isn’t the hours themselves, it’s what they get spent on instead. The service desk exists to get people unstuck. Every hour that used to go to typing a new hire’s details into a form now goes to someone who can’t work until their problem is fixed.
What I’d do differently
This was my first time building anything in Okta Workflows. I understand how it works a lot better now than I did when I started, and it shows in the flows.
If I rebuilt them, I’d lean much harder on helper flows. The main flows do too much inline, which makes them long and harder to read than they need to be. Breaking the repeated pieces out into small helper flows that the main flow calls would make the whole thing easier to follow, and easier for someone else to pick up.
It works, and it’s been working every week. But the next version would be a lot more readable.