Automating employee onboarding and offboarding means building a system that triggers from your HRIS, executes every provisioning step in a defined sequence, enforces approval gates before sensitive actions run, and logs a complete audit trail. The difference between that and a checklist is not speed. It's whether the automation layer actually executes the work, or whether a person still has to run the process.

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 does a webhook-triggered workflow connect to an HRIS to fire automatically?

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. Connect Workday, Rippling, or another HRIS to Serval

2. Build the onboarding workflow in the Workflow Builder. The Automation Agent writes it as TypeScript based on a plain-English description: "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. Copy the workflow's unique webhook URL and configure the HRIS to POST the new employee record to that URL when a hire is created

When the trigger fires, the workflow runs exactly as written. The Automation Agent 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.

For offboarding, the same pattern applies. A termination event in Workday or Rippling fires the webhook. The offboarding workflow runs.

What does multi-system provisioning look like inside a single onboarding 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 employee's department and role from the HRIS payload, the workflow calls `Add User to Okta Group` for each relevant group. 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.

Step 5: Post confirmation. The workflow sends a Slack DM to the new hire with their 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, Google Workspace, and GitHub. The `Create Okta User`, `Add User to Okta Group`, `Create Google Workspace User`, `Add User to Google Group`, and `Add GitHub User to Team` workflows are available off the shelf. Install them, configure inputs and approvals, and wire them into the onboarding sequence. Common onboarding steps can be live the same day.

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 org structure from the connected HRIS

• 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 configured in the Workflow Builder as 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.

Custom approval workflows reduce the manual review queue for routine access. If the request matches a standard access policy and the requester hasn't been denied the same access in the past 24 hours, auto-approve. Otherwise, route to the resource owner. This eliminates review overhead for routine requests while preserving oversight for anything outside the norm.

Why is offboarding a security workflow, not a productivity workflow?

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. Deactivates the Okta account using `Deactivate Okta User`. This suspends the user's session, revokes SSO, and cascades deprovisioning to SCIM-connected applications.

2. Removes all Okta group memberships using `Remove User from Okta Group`. This revokes any remaining role-based access.

3. Removes the user from all Google groups using `Remove User from Google Group`.

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. Posts a completion summary to the security channel with the list of systems deprovisioned and the timestamp of each action.

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.

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.

After those three are running, the Insights Agent analyzes remaining ticket volume and surfaces which provisioning requests still generate manual IT work. That becomes the roadmap for what to automate next.

What is the practical difference between automation and deflection for onboarding?

Deflection means a user's request was redirected: to a knowledge base article, a self-service portal, or another queue. The request didn't complete. Someone still has to act on it.

Automation means the request completed without IT touching it. The access was provisioned. The account was created. The workflow ran to completion.

A chatbot that helps a new hire find the provisioning portal is deflection. A workflow that creates their Okta account, assigns their groups, provisions their tools, and sends them login instructions before they arrive is automation.

For onboarding and offboarding, the distinction matters more than it does for general support tickets. Deflection doesn't solve the provisioning problem. A new hire directed to a portal still needs someone on IT to process the request. An offboarding request routed to a queue still needs someone to run the revocation steps.

Serval measures full automation rate: requests completed without an IT or service desk member ever touching the ticket. Approval steps may involve humans, but that's a deliberate security control built into the workflow definition. The execution still runs without manual intervention. The goal isn't fewer tickets. It's IT never having to manually run the provisioning sequence again.