How to automate employee onboarding and offboarding IT workflows

To automate onboarding across Okta, Google Workspace, and Slack, treat your HRIS as the source of truth, keep Okta as the identity layer, and run one workflow that creates accounts, assigns groups by department and role, invites the hire to Slack, and logs every step. Serval runs that workflow for each new hire, adds approval gates for sensitive access, and tracks the human steps in one journey. Serval automates all employee onboarding at Perplexity.

What does manual onboarding and offboarding actually cost IT?

Most IT teams undercount this. They see each onboarding as a handful of tasks rather than a workflow that runs identically for every hire.

Creating an Okta user takes a few minutes. Adding them to the right Google groups takes a few more. Then GitHub access, a Zoom license, a Slack workspace invite, device enrollment. Each step touches a different system. None of those systems talk to each other. And none of it starts until someone in IT notices the hire exists.

When the process works, new hires wait a day or two for full access. When it breaks: a step gets skipped because the person who usually handles provisioning was out. The new hire spends their first two days pinging IT for tools they were supposed to have on arrival. The ticket sits in the queue as a follow-up.

Offboarding carries a different cost structure. It's not a productivity problem: it's a security problem. When an employee leaves, every active credential is a risk. An access revocation that gets delayed a week isn't an inconvenience. It's an audit finding. Security teams typically discover missed offboarding steps during reviews, not from IT proactively flagging them.

The total cost is IT capacity: time spent on work that follows an identical path every time, that could execute automatically, but doesn't because nothing is wired to trigger it.

What is the difference between a checklist and a workflow?

A checklist describes what needs to happen. A workflow executes it.

The practical difference: a checklist requires someone to notice the hire, open the provisioning doc, work through each step manually, and verify completion. A workflow fires when a condition is met, executes each step in order, enforces dependencies between steps, requires approvals where configured, and logs a completion record.

Checklist-based onboarding works at low headcount because one or two people can hold the process in their head. It breaks when:

• The person who knows the steps is unavailable
• The hire record exists in the HRIS but no one has created a ticket yet
• A downstream step fails silently because an upstream step was skipped
• Compliance asks which systems a departed employee had access to and when each was revoked

None of these failures require a large team or bad process. They require a checklist to be run by a human. Replace the checklist with a workflow and those failure modes disappear because the system executes the steps, not the person.

How do you start onboarding automatically when a new hire is added to Workday, BambooHR, or Rippling?

This is the starting point for removing human-triggered delay from onboarding. The trigger for the onboarding workflow should be a new employee record in the HRIS, not a ticket someone opens after noticing the hire.

Webhook-triggered workflows in Serval receive an HTTP POST from an external system and execute immediately. For HRIS-connected onboarding, the setup looks like this:

1. 1.Connect Workday, BambooHR, Rippling, HiBob, ADP, or another HRIS to Serval
2. 2.Describe the onboarding workflow to Catalyst, Serval’s automation agent, which writes it as TypeScript: "When triggered, create an Okta user with the employee's name and email from the payload, add them to the standard groups for their department, provision a GitHub team membership, and send them a welcome DM in Slack with login instructions."
3. 3.Copy the workflow’s webhook URL and have the HRIS, or an integration tool, POST each new hire record to it, or schedule the workflow to check the HRIS for new hires

When the trigger fires, the workflow runs exactly as written. Catalyst wrote the code at build time. At runtime, nothing is generated or improvised on the fly. Employee 1 and employee 10,000 go through the same sequence.

The same pattern covers the full joiner, mover, leaver cycle. A termination starts the offboarding workflow. A department or manager change starts a workflow that removes the old Okta or Entra ID groups, adds the new ones, and routes any elevated access to an approver.

How do you provision accounts across Okta, Google Workspace, and Slack in one workflow?

Most organizations don't provision access through one system. Identity lives in Okta or Entra. Email and calendar live in Google Workspace. Code access lives in GitHub. Communication lives in Slack. Some access depends on IdP group membership. Some has to be provisioned directly.

A complete onboarding workflow handles all of this in one pass, in the right order.

Step 1: Create the Okta user. The workflow calls `Create Okta User` with the employee's name, email, and role. This establishes the identity that downstream provisioning will reference.

Step 2: Assign Okta groups. Based on the hire’s department, location, role, and employment type from the HRIS payload, the workflow calls Add User to Okta Group (or Add User to Azure Active Directory (Microsoft Entra ID) Group) for each relevant group, so contractors and full-time employees get different access. Applications provisioned through Okta group membership get access automatically at this step.

Step 3: Provision Google Workspace. The workflow calls `Create Google Workspace User` and `Add User to Google Group` for each relevant distribution list. Google groups may include internal mailing lists or calendar resources that don't map directly to Okta groups, so this step runs explicitly.

Step 4: Provision GitHub access. The workflow calls `Add GitHub User to Team` for the relevant repository teams. GitHub team assignments often can't be fully derived from IdP group membership: individual team assignments and organization roles are managed separately. The same goes for any app without SCIM. Serval runs a custom provisioning workflow through the app’s API, so those grants and revocations don’t fall back to a manual checklist.

Step 5: Provision Slack. The workflow calls Invite Slack User and Add User to Slack Channel for the hire’s team channels, then DMs them login instructions and posts a summary to the IT ops channel.

The order enforces the dependencies. If GitHub team membership depends on the Okta user existing, the workflow creates the Okta user first. If it fails at any step, the run log records where it stopped and why.

Serval ships installable workflows for Okta, Microsoft Entra ID, Google Workspace, Slack, and GitHub. The Create Okta User, Add User to Okta Group, Create Google Workspace User, Add User to Google Group, Invite Slack User, and Add GitHub User to Team workflows are available off the shelf.

How do approval gates work for sensitive provisioning steps?

Not every provisioning step should execute automatically. Elevated access, admin roles, and access to sensitive data systems should require human sign-off before the workflow continues.

Serval's approval model supports several configurations:

• Individual approvers: Route to a specific person who must approve before the step runs
• Group-based approvals: Route to a group, such as the IT Security team; any member can approve
• Manager routing: Automatically resolves to the requester’s manager, using manager data synced from your identity provider
• Multi-step sequential chains: Manager approves first, then the IT security team provides final sign-off
• Custom approval workflows: Auto-approve standard requests that meet predefined conditions; escalate exceptions to a human

These approvals are part of the workflow definition. They're not optional at runtime. An IT admin can't trigger the workflow and skip the approval step. The approval must occur before the provisioning step executes.

For a standard hire into a standard role, a single manager approval before elevated access is provisioned is usually sufficient. For a hire who needs production infrastructure access or admin permissions, a sequential chain works: manager approves the standard access package, then IT security approves the elevated grants separately.

Do you need Serval if you already use Okta Workflows?

Keep Okta as the identity layer. Okta Lifecycle Management and Okta Workflows handle identity events well: creating users from an HR source and pushing accounts to SCIM-connected apps. Onboarding also includes work outside identity: the manager’s access request, the approval chain for admin rights, apps without SCIM, the laptop, and the HR and manager tasks. Serval runs those in one place, calls Okta’s own actions where Okta is the right system, and logs the whole run.
For how Serval compares with Okta, Rippling, Workday, and other tools, see our guide to the best employee onboarding software for IT and HR teams.

How do you automate offboarding across every app when an employee leaves?

Onboarding delay costs a new hire productivity. Offboarding delay creates active security risk.

Every system an employee had access to is a system that still has their credentials active until the offboarding workflow runs. Former employees with active credentials are a common audit finding. The workflow should run as close to the termination event as possible. The trigger should be the HRIS status change, not a ticket someone opens after HR has already processed the departure.

A complete offboarding workflow in Serval:

1. 1.Deactivates the Okta account with Deactivate Okta User, or the Microsoft Entra ID account with Disable Office 365 User Account. This suspends the user's session, revokes SSO, and cascades deprovisioning to SCIM-connected applications.
2. 2.Removes all Okta group memberships using `Remove User from Okta Group`. This revokes any remaining role-based access.
3. 3.Removes the user from Google groups with Remove User from Google Group, hands off their files with Transfer Google Drive Ownership, deactivates Slack with Deactivate Slack User, and locks the laptop with Send Computer MDM Command in Jamf.
4. 4.Revokes GitHub access. For users with individual repository permissions not managed through IdP groups, this requires explicit revocation steps using the GitHub integration.
5. 5.Posts a completion summary to the security channel with the list of systems deprovisioned and the timestamp of each action.

At Cribl, offboarding in Serval is enforced consistently, with no missed steps.

The offboarding workflow is scoped to team members only. It never surfaces to the Help Desk Agent and can't be triggered by anyone outside the IT team. The actions it takes are irreversible: deactivating the wrong account deactivates a user and revokes all their access. Execution scope enforces that boundary at the configuration level, not as a UI suggestion.

Serval's API scope ceiling matters here as well. When you connect an integration, you define the maximum scope of what the workflow layer can ever access. The offboarding workflow can't exceed that ceiling. If Okta is connected with user management and group management scopes, those are the limits. No workflow can take actions beyond what was explicitly configured at setup.

What does the audit trail look like, and how does it serve compliance?

Every workflow run in Serval logs the steps executed, the user who triggered the run, the approvers who signed off, and the timestamp of each action. That log is the audit trail.

For onboarding, the log answers: which systems was this employee provisioned into, who approved the elevated access grants, and when did each step complete.

For offboarding, it answers the question auditors actually ask: which systems did this employee have access to, when was each revoked, and who authorized the offboarding run. That's a SOC 2 evidence artifact, not a reconstruction from Slack messages.

Scheduled audit workflows extend this further. An access change audit workflow runs every Friday, pulls all provisioning and deprovisioning activity from the past seven days, and exports a CSV with user email, application, action, approver, and timestamp to the security channel. That information sits in a channel your security team already monitors, formatted for review, without anyone generating it manually.

The audit trail for offboarding has a specific compliance use case. When a security auditor asks who had access to production infrastructure last quarter and when that access was revoked, the answer comes from the workflow run logs directly.

What should IT automate first?

The onboarding and offboarding steps worth automating first are the ones that follow an identical path every time and carry the highest cost when skipped.

Offboarding access revocation earns automation immediately. The workflow path is the same for every termination. The security case is clear regardless of company size. The audit trail is a compliance requirement. This is the highest-value starting point.

Standard role provisioning is the onboarding equivalent. Every engineer goes to the same Okta groups. Every sales hire goes to the same Google groups. These automations eliminate the most common provisioning mistakes and free up IT for exceptions rather than repetition. Mercor runs contractor onboarding this way: more than 4,000 contractors onboarded, with expert managers triggering onboarding themselves.

HRIS-triggered workflow initiation comes after those are working. Once the provisioning sequence is reliable, connecting it to the HRIS trigger removes the last human-dependent step: someone has to notice the hire and kick off the process.

Then put the steps people still own into a journey. A Serval journey gives each new hire one tracked record. HR, the hiring manager, and IT each get their tasks, tasks unlock based on the start date, and the journey list flags incomplete and failed steps, so nobody has to chase where a setup is stuck.

After those are running, the Catalyst agent analyzes remaining ticket volume and surfaces which provisioning requests still generate manual IT work. That becomes the roadmap for what to automate next. Serval measures full automation rate: requests completed without anyone in IT touching the ticket.