When a new employee starts at a growing company, something predictable happens: at least four different people find out their process was more manual than they thought. The HR person realizes they never sent the system access request. IT realizes they weren't told the start date. The manager realizes nobody created the onboarding doc. The new employee realizes, at 9:03 AM on their first day, that they can't log into anything.
Onboarding is often described as a culture and communication problem. In our experience, it's actually a workflow coordination problem that surfaces as a culture problem when it breaks. The underlying issue isn't that people don't care — it's that the process has too many handoffs, no single owner, and no system that can track whether each step actually completed.
The Real Step Count
Map out a full employee onboarding sequence and you typically land somewhere between 18 and 28 discrete steps, depending on the role and company. Here's a realistic list for a non-executive hire at a 50–150 person SaaS company:
Offer signed → HRIS record created → payroll enrolled → background check initiated → background check cleared → laptop ordered → laptop configured → SSO provisioned → role-specific software licenses assigned → Slack workspace invited to correct channels → Google Workspace account created → email signature template sent → org chart updated → BambooHR (or equivalent) manager assignment confirmed → manager notified with start date → 30-60-90 day template shared with manager → onboarding buddy assigned → first-week calendar blocked → company handbook acknowledged → compliance training assigned → compliance training completed → IT equipment delivery confirmed → parking/badge/facilities access (if in-office) → initial 1:1 with manager scheduled.
That's 24 steps. They span IT, HR, Payroll, the hiring manager, and potentially Facilities. Some are triggered by others. Some can run in parallel. Several have dependencies where step N can't start until step N-1 produces a specific output (you can't provision SSO until the Google Workspace account exists; you can't assign licenses until SSO is provisioned).
No single person at most companies owns all 24. Which means in practice, several of them fall through the cracks on every hire.
Why Current Automation Approaches Fall Short
Most HR platforms have some onboarding workflow functionality. BambooHR has onboarding checklists. Workday has task assignments. These tools are useful for tracking whether steps are complete, but they're mostly notification engines: they send an email to IT saying "please provision this person's laptop" and then wait for someone to check a box.
The actual work — opening a Jira ticket with the right configuration template, creating the Google Workspace account with the right OU assignment, adding the person to the right Slack channels based on their department — still requires a human to log into each system and do it.
Zapier-style automation can help with individual handoffs. You can write a Zap that, when a new record is created in your HRIS, creates a Jira ticket with a template. But this falls apart quickly: what if the HRIS record is created before background check clearance? What if the laptop configuration varies by role? What if a contractor hire follows a different access policy than a full-time employee? Each variation requires its own rule, and the rules multiply until the automation is too fragile to maintain.
We're not saying HRIS workflow tools don't add value — they do, especially for checklist visibility. The gap is in execution: the tools track what should happen but don't close the loop on making it happen reliably across systems.
The Cross-System Execution Problem
What makes onboarding hard to automate with standard tools is that it's not one workflow — it's five parallel workflows that need to coordinate. Each system (HRIS, IT ticketing, identity provider, Slack, your ATS) has its own API, its own data model, and its own completion state. A step being "done" in BambooHR doesn't mean the corresponding action actually executed in Okta.
This is where the gap between "workflow tracker" and "workflow executor" becomes consequential. A tracker tells you the status of each step. An executor actually performs the work and verifies the result.
Consider what it takes to provision software licenses correctly for a new product manager. That person needs Jira, Confluence, Figma, Mixpanel, and Looker — but Looker access requires a specific user group assignment that maps to their team, not just their job title. If your onboarding automation just runs "add user to Looker," they get viewer-only access instead of edit access, and nobody notices until they try to create their first dashboard on day three.
An agent-based approach to this step reads the new hire's role, department, and team from the HRIS record, checks the access policy for that team against a maintained policy document, then provisions each tool with the correct role and permission set. It also logs the action taken with a before/after state, so if there's a question about access levels later, there's a clear record of what was provisioned, when, and why.
The Day-One SLA Problem
Here's a number worth tracking: what percentage of employees at your company can access all the systems they need on day one, by the time they start work? For most early-stage to mid-size companies, that number is well below 100%. When we've asked ops teams to estimate it, the honest answers range from 60% to 85%.
The cost of a broken onboarding isn't just the new employee's frustration. It's the manager's time resolving access issues, the IT team's reactive ticket load on day-one hires, and the signal it sends to the new employee about how the company operates. First impressions formed in week one are remarkably durable.
Improving that day-one SLA to 95%+ requires treating onboarding as an execution-critical process — not just a checklist. That means: every step has a clear trigger and a clear completion state, dependencies are enforced (you cannot send a welcome message until access is confirmed), and any step that hasn't completed by a defined deadline generates an escalation, not a silent miss.
What an Automated Onboarding Flow Actually Looks Like
In a well-designed automated onboarding sequence, the trigger is offer signature in your ATS. That fires a process that runs sequentially and in parallel depending on dependencies.
Immediately: HRIS record created, manager notified with onboarding doc template, compliance training scheduled for start date, background check initiated.
Upon background check clearance (dependency gate): IT laptop order placed with configuration template based on role, SSO account creation initiated.
Upon SSO creation (dependency gate): Role-based application access provisioned, Slack channels assigned based on department, Google Calendar permissions set.
Two business days before start date: Manager receives a structured briefing — confirmed access list, first-week calendar, buddy assignment, and any unresolved items flagged for manual attention.
Day one, 8:00 AM: New employee receives a structured welcome message with login instructions for their confirmed active accounts — not a generic "check these things" list, but a confirmation of what's actually provisioned and ready.
Each step logs its execution state. Any step that fails (API error, timeout, missing data) immediately escalates to the responsible owner with context — what step failed, what the input was, and what the error returned. The escalation is not "something went wrong." It's "the Looker provisioning step failed because the team identifier 'product-growth' did not match any group in the Looker directory — expected one of: product-analytics, growth-team, product-core. Please confirm the correct group and we'll retry."
The Offboarding Mirror
The same logic applies to offboarding, which is often worse. When someone leaves, access revocation needs to happen quickly and completely. Missing a step — leaving an active account in a SaaS tool after someone's last day — is not just an operational loose end; it's a security exposure.
Offboarding workflows have the same multi-system execution problem with higher stakes: you need to confirm that access was revoked in every system, not just that someone sent the deprovisioning request. The completion state needs to be verified, not assumed.
The discipline of treating onboarding as a precisely sequenced, multi-system execution problem — rather than a checklist — transfers directly to offboarding. Once you have the execution infrastructure and audit logging for one, the other is the same pattern inverted.