8 Steps to Build Multi-Step HR Onboarding Workflows in Make.com

Building a multi-step HR onboarding workflow in Make.com™ connects your ATS, HRIS, IT provisioning tools, and LMS inside one visual scenario. When a candidate accepts an offer, every downstream system fires automatically — accounts created, equipment ordered, training enrolled — with zero manual handoffs and a full audit trail across every step.

Parseur research puts the cost of manual HR data entry at $28,500 per employee per year when you factor in time, errors, and rework. New-hire onboarding is the densest concentration of that cost. The scenario structure below eliminates the manual handoffs and lets your team focus on the work that requires human judgment.

If you’re evaluating Make.com against other platforms first, read Make vs. Zapier: A Straight Pricing and Feature Breakdown for 2026 before continuing. This post assumes you’ve made the platform decision and are ready to build.

1. Map Every Manual Step Before Touching the Builder

You cannot automate a process you haven’t fully mapped. Walk each stakeholder — HR, IT, the hiring manager, payroll — through their specific tasks. Capture what triggers each step, what data it reads or creates, which system holds that data, and what the acceptable timeline is.

McKinsey Global Institute research finds that up to 56% of HR administrative tasks are automatable with existing technology — but only if you know which tasks exist first.

Output a single table: Step | Owner | Source System | Target System | Data Fields | Dependency. That table becomes your Make.com module list. Every row is a module. Every dependency is a sequencing decision — sequential where order matters, parallel where it doesn’t.

Flag any step where the rule is ambiguous or requires judgment. Those are future AI insertion points, not immediate automation targets. The OpsMap™ checklist gives you a structured framework for this discovery phase.

2. Build All Connections Before Placing Modules

Broken connections mid-build waste significant time. In Make.com, navigate to Connections and create a named connection for each system: your ATS, HRIS, IT ticketing tool, LMS, and Slack or email platform.

Use OAuth 2.0 where the app supports it. For systems without a native Make.com module, use an HTTP module with an API key. Name each connection with the system name and environment — for example, Greenhouse-Production or BambooHR-Sandbox. Swapping sandbox credentials for production credentials later is far cleaner with descriptive naming.

Confirm that your ATS sends webhook payloads on status change. Not every ATS tier includes outbound webhooks — verify before committing to a webhook trigger architecture.

3. Set the Trigger on ATS Offer Acceptance

The trigger is the event that fires the entire scenario. For HR onboarding, the correct trigger is ATS offer acceptance — the moment a candidate’s status moves to “Offer Accepted” or the equivalent in your system.

In Make.com, add a Webhooks > Custom Webhook module as your trigger if your ATS supports outbound webhooks. Configure your ATS to POST to that webhook URL on status change. Test the trigger by moving a test candidate to offer-accepted status and confirm Make.com receives the payload.

If your ATS doesn’t support outbound webhooks, use a scheduled polling trigger on a 15- or 30-minute interval. Polling introduces latency but works with any ATS that has a filterable API endpoint.

4. Create the HRIS Record as the First Action Module

The HRIS record is the dependency everything else waits on. Until the employee exists in your HRIS, there’s no employee ID to attach to IT tickets, benefit enrollments, or LMS accounts. Build HRIS record creation as the first action module after the trigger.

Map fields directly from the ATS webhook payload: first name, last name, start date, department, job title, manager. Add a Router module immediately after HRIS creation — this is where you branch into parallel tracks for IT provisioning, benefits, and LMS enrollment.

If your HRIS requires fields absent from the ATS payload, use a Get a Record module against your HRIS lookup table or a data store before the router. Resolve missing data upstream — not inside the router branches.

5. Branch Parallel Tracks for IT, Benefits, and Training

After HRIS record creation, every downstream action is independent. IT provisioning doesn’t wait on benefits. LMS enrollment doesn’t wait on IT. Use Make.com’s Router to run all three tracks in parallel — this compresses elapsed time from days to minutes.

• IT Track: Create a provisioning ticket in your IT system, trigger account creation in Google Workspace or Microsoft 365, and send the new hire their credentials via email.
• Benefits Track: Send the enrollment link with a deadline, log the enrollment event in your HRIS, and schedule a follow-up reminder for day 3 if enrollment isn’t confirmed.
• LMS Track: Create the learner profile, assign the role-specific onboarding curriculum, and notify the hiring manager that training is queued.

The scenario that compressed a 45-minute onboarding process to under 4 minutes used exactly this parallel-branch architecture — every minute of savings came from eliminating sequential hand-offs between systems.

6. Add an Error Handler to Every External Module

Every module that calls an external system — your ATS, HRIS, IT ticketing tool, LMS — needs an error handler. Without one, a single API timeout aborts the entire scenario and leaves a new hire with a half-created record across four systems.

In Make.com, right-click any module and select Add error handler. For most external modules, use a Break handler configured with 3 retry attempts and a 60-second interval. This handles transient API failures without human intervention. For failures that persist after retries, route the error to a Slack notification or email alert so your team knows exactly which module failed and why.

The full setup is covered in this routed error handling walkthrough for Make.com.

7. Test Against Sandbox Records Before Activating on Live Candidates

Activating on live candidates before testing produces real HRIS records with bad data. Create a test candidate record in your ATS sandbox — or use a clearly flagged test record in production — and walk the full scenario from trigger to completion.

Verify each output: the HRIS record fields match exactly, the IT ticket has the correct employee ID attached, the LMS enrollment is assigned to the right curriculum, and the hiring manager notification contains accurate data. Run the test three times with different role types if your scenario includes role branches.

Document every failure, fix it in the scenario, and retest. Schedule a stakeholder review before go-live — HR, IT, and at least one hiring manager sign off on a successful test run before the scenario activates on real candidates.

8. Document the Scenario Structure Before Handing Off

A Make.com scenario with no documentation is a liability. When the person who built it gets pulled into other work, the next person inherits a black box. Document before the handoff.

At minimum, cover: what triggers the scenario, what each router branch does, which external systems each module touches, what error handling is in place, and where to find the test record protocol. Add notes directly to modules inside Make.com — right-click any module and select Add a note.

Non-technical HR teams run these scenarios successfully when documentation is clear. The HR team automation case study shows what that looks like in practice.

Frequently Asked Questions

How many Make.com operations does a full onboarding workflow use?

A typical onboarding scenario with ATS trigger, HRIS creation, and three parallel branches (IT, benefits, LMS) runs 15–25 operations per new hire. At the Make.com Core plan rate, that is well within budget for teams hiring fewer than 100 people per month.

What if my ATS doesn’t have a native Make.com module?

Use Make.com’s HTTP module with your ATS API key. Most ATS platforms expose a REST API — feed the API documentation into Claude to generate the module configuration. The step-by-step guide for building HTTP modules from API docs covers this exactly.

How do role branches work for different job types?

Add a Router after your HRIS creation module. Each route uses a filter condition on the job title or department field from the webhook payload. Hourly roles, salaried roles, and contractor roles each follow their own branch with role-specific provisioning and training assignments.

What is the biggest mistake teams make when building these scenarios?

Skipping the process map. Teams open the Make.com builder before documenting every manual step, then discover mid-build that departments have different onboarding rules for the same role. The process map table eliminates that problem before the build starts.

Can this scenario handle rehires differently from new hires?

Yes. Add a lookup module after the trigger that checks whether an employee ID already exists in your HRIS. Route returning employees to a reactivation branch that skips HRIS record creation and goes directly to account reactivation and updated training assignment.