How to Automate HR Onboarding: Build Multi-Step Workflows in Make.com™

Manual onboarding coordination is an operations tax. Parseur research puts the cost of manual data entry at $28,500 per employee per year when you account for time, errors, and rework — and new-hire onboarding is one of the densest concentrations of manual data entry in any HR team’s calendar. The answer is a multi-step automation scenario that connects your ATS, HRIS, IT provisioning tools, and LMS inside a single visual workflow. This guide shows you exactly how to build that scenario in Make.com™.

If you’re still deciding whether Make.com™ is the right platform for your HR stack, start with the Make vs. Zapier for HR automation deep comparison before continuing here. This guide assumes you’ve made the platform decision and are ready to build.

Before You Start

Skipping prerequisites is the fastest way to build a scenario you’ll have to rebuild. Confirm each item before opening Make.com™.

• Tools required: Make.com™ account (Core plan or higher for multi-step scenarios), access credentials for your ATS, HRIS, IT ticketing system, and LMS, plus admin rights to create webhook endpoints in your ATS.
• Time estimate: 4–8 hours for a single-track scenario. Add 2–4 hours per additional role branch. Reserve a full week before go-live for testing and stakeholder sign-off.
• Data map required: Know which ATS field maps to which HRIS field before you open the builder. Mismatched field types (text vs. date, for example) are the leading cause of module failures.
• Permissions: Confirm that your ATS can send webhook payloads on status change. Not every ATS tier includes outbound webhooks — verify before committing to this trigger architecture.
• Risk: Activating on live candidates before testing produces real HRIS records with bad data. Always use a sandbox or test-record protocol first.

Step 1 — Audit and Map Your Current Onboarding Process

You cannot automate a process you haven’t fully mapped. Before touching the Make.com™ builder, document every manual step that occurs between offer acceptance and an employee’s first day.

Walk each stakeholder — HR, IT, the hiring manager, payroll — through their specific tasks. Capture: what triggers each task, what data each task 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 in the first place.

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

Action: Complete the process map table before proceeding. Flag any step where the rule is ambiguous or requires judgment — those are your future AI insertion points, not your immediate automation targets.

Step 2 — Connect Your Data Sources in Make.com™

Connections authenticate Make.com™ to each external system. Build them all before you start 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, 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 connections descriptively — “ATS-Production” rather than “Connection 1” — so that when you’re auditing a scenario six months later, every connection’s purpose is self-evident.

Action: Authenticate and test every connection. Send a test API call from the Make.com™ connection screen and confirm a successful response before advancing.

Step 3 — Configure the ATS Trigger

The trigger is the entry point for the entire scenario. Get it wrong and every downstream module fires on bad data — or doesn’t fire at all.

The two viable trigger architectures are:

• Webhook (preferred): Your ATS sends a POST request to a Make.com™ custom webhook URL the moment a candidate status changes to “Offer Accepted.” Near-real-time, low operation cost, no polling lag.
• Scheduled Watch Records: Make.com™ polls your ATS every 15 minutes (or on your defined interval) for new records matching a filter condition. Higher operation cost, introduces lag, but works for ATS platforms that don’t support outbound webhooks.

To configure a webhook trigger: in Make.com™, add a Webhooks > Custom Webhook module as the first module in your scenario. Copy the generated URL. In your ATS automation or integration settings, paste that URL as the destination for the “Offer Accepted” status change event. Send a test event from your ATS and confirm the payload appears in Make.com™’s webhook inspector.

Action: Configure your trigger, send a test payload, and confirm the data structure in Make.com™’s bundle inspector. Note the exact field names — you’ll map these in Step 4.

Step 4 — Retrieve and Validate New-Hire Data

The webhook payload from your ATS typically contains a candidate ID and status — not the full candidate record. Add an ATS “Get a Candidate” or “Get a Record” module immediately after the trigger to pull the complete data set.

Map the candidate ID from the webhook payload to the lookup field in the Get module. After the module runs, inspect the output bundle and confirm that every field your downstream modules need is present and correctly typed: first name, last name, personal email, job title, department, start date, hiring manager email, and employment type (full-time, part-time, contractor).

Add a Filter after the Get module to halt the scenario if any required field is empty. A filter set to “Start Date exists AND Job Title exists” prevents the scenario from creating partial HRIS records for incomplete candidate profiles.

Action: Run the scenario with a test candidate ID. Open the Get module’s output bundle and verify that all required fields are populated and correctly typed before proceeding.

Step 5 — Build the HRIS Record Creation Module

This is the highest-stakes module in the scenario. An HRIS record with incorrect data — wrong start date, wrong job title, wrong pay type — creates downstream compliance and payroll problems. David, an HR manager at a mid-market manufacturing company, learned this the hard way: an ATS-to-HRIS transcription error turned a $103K offer into a $130K payroll entry, a $27K mistake that ended with the employee quitting.

Add your HRIS’s “Create Employee” or “Create Record” module. Map each field explicitly from the Step 4 output bundle — do not use free-text defaults. Pay particular attention to:

• Date fields: Match the format your HRIS expects (ISO 8601, MM/DD/YYYY, etc.). Make.com™’s formatDate() function handles conversion.
• Employment type: Map to your HRIS’s exact enum values, not the ATS’s label — they are often different strings.
• Manager field: Most HRIS platforms expect a manager Employee ID, not a name or email. You may need an intermediate lookup module to convert the hiring manager email to their HRIS ID.

Attach an error handler to this module immediately (covered in Step 9). A failed HRIS creation should never be silent.

Action: Map every required HRIS field. Run a test and open the HRIS to confirm the record was created with correct values before proceeding.

Step 6 — Add a Router for Role-Based Branching

A single onboarding track doesn’t exist in real organizations. Managers get different training modules. Engineers get different software licenses. Contractors get different access permissions. The Router module handles this without duplicating scenarios.

Add a Router module after the HRIS creation step. Create one path per role category you need to support. On each path, add a Filter that evaluates the Job Title or Department field from your data bundle:

• Path A filter: Job Title contains "Manager" → manager onboarding branch
• Path B filter: Department = "Engineering" → engineering onboarding branch
• Path C filter: Employment Type = "Contractor" → contractor onboarding branch
• Path D (fallback): no filter → default onboarding branch for all others

Each path then carries the modules specific to that role: the correct LMS enrollment, the correct IT access tier, the correct equipment request form. For a deeper treatment of filter logic and branching patterns, see the guide on advanced conditional logic and filters in Make.com™.

Action: Build your Router with at least two paths plus a fallback. Test each path with a candidate record that matches that filter condition.

Step 7 — Fire Parallel Task Sequences (IT Provisioning + Manager Notification)

Sequential task chains are where manual onboarding loses days. IT waits for HR. The manager waits for IT. Equipment ordering waits for manager sign-off. In Make.com™, a Router with non-exclusive paths fires all parallel tasks from the same data bundle simultaneously.

Within each role branch from Step 6, add a second Router (or use parallel paths off the same Router if your tool allows it) to fire simultaneously:

• IT provisioning path: Create a ticket in your IT system with the new hire’s name, role, start date, required software list, and access tier. Map these fields from the HRIS output bundle, not the original ATS payload — the HRIS record is now the system of record.
• Manager notification path: Send an email or Slack message to the hiring manager’s email address with the new hire’s details, start date, and a checklist of manager-side onboarding tasks. Use Make.com™’s text formatting to make this message scannable.

For guidance on connecting your ATS to real-time team notifications, the same webhook and notification patterns apply regardless of which direction the data flows.

Action: Confirm both paths fire in the same execution. Check the IT system for the created ticket and confirm the manager received the notification with correct data.

Step 8 — Enroll in LMS and Send the New-Hire Welcome Message

LMS enrollment and the new-hire welcome message are the final functional steps before error handling. Both fire after IT provisioning and manager notification are confirmed — or in parallel with them if your scenario architecture allows.

Add your LMS “Enroll User” module. Map the new hire’s email, the course or learning path ID appropriate to their role (set per Router branch in Step 6), and the enrollment start date. Asana’s Anatomy of Work research finds that workers spend a significant portion of their day on work coordination rather than skilled work — a pre-populated LMS enrollment eliminates one more coordination task from the HR team’s plate.

Follow the LMS enrollment with an email module that sends the new hire a personalized welcome message. Include:

• Their name, role, and start date (mapped from the data bundle)
• Their manager’s name and contact information
• A link to their LMS enrollment
• First-day logistics (location, time, what to bring)

Use Make.com™’s text/HTML formatting options to build a clean, professional template. Store the template in a Make.com™ Text Aggregator or reference a Google Doc via module — do not hardcode it in the module itself, or every update requires a scenario edit.

Action: Trigger a test run, log in to the LMS as the test user, and confirm enrollment is present. Confirm the welcome email arrived in the test inbox with correct personalized fields.

Step 9 — Add Error Handlers to Every Critical Module

Error handling is not optional. Gartner research consistently identifies data quality and integration reliability as top barriers to HR technology ROI — and silent automation failures are a primary driver of both problems.

In Make.com™, right-click any module and select Add error handler. The two most useful handler types for onboarding scenarios are:

• Ignore: Logs the error and continues the scenario. Use only for non-critical notifications (e.g., a secondary Slack ping failing should not halt onboarding).
• Break: Halts processing and marks the bundle as failed for manual retry. Use for critical modules — HRIS record creation, IT provisioning, LMS enrollment.

Wire every Break handler to a Slack or email notification module that sends the error message, the candidate’s name, and the module that failed to the HR operations inbox. This turns a hidden failure into an immediate, actionable alert.

For security considerations around how error data is handled and what to log, the guide on securing HR automation workflows covers data minimization practices for error payloads.

Action: Add error handlers to: the HRIS Create module, the IT provisioning module, the LMS enrollment module, and the welcome email module. Test each handler by temporarily breaking the connection and confirming the alert fires.

Step 10 — Test, Verify, and Activate

A scenario that passes visual inspection is not a scenario that’s ready for production. Run a structured verification protocol before activating on live candidates.

1. Single-path test: Use a test candidate record that matches your default onboarding path (Path D from Step 6). Run the full scenario. Open the Execution Log and inspect every module’s input and output bundle. Confirm field values are correct end-to-end.
2. Role-branch test: Repeat with a test record for each role branch. Confirm the Router routes correctly and that each branch triggers the right LMS course and IT access tier.
3. Error-handler test: Temporarily invalidate one critical module’s connection. Run the scenario. Confirm the error handler fires and the alert arrives in the HR inbox. Restore the connection.
4. Stakeholder review: Walk IT, payroll, and the hiring manager through a test run output. Confirm that the records and notifications they receive match their expectations.
5. Activate: Turn the scenario on. Monitor the first three live executions in real time via the Execution Log before stepping away.

How to Know It Worked

A successful multi-step onboarding scenario produces all of the following within minutes of offer acceptance:

• A complete, accurate HRIS employee record with correct start date, job title, and manager assignment
• An IT provisioning ticket with the correct software and access tier for the role
• A manager notification with new-hire details and a first-day checklist
• An LMS enrollment in the correct learning track for the role
• A personalized welcome email in the new hire’s inbox
• Zero error-handler alerts in the HR inbox

The operational benchmark to target: time from offer acceptance to all downstream systems updated drops from 1–3 business days (manual) to under 15 minutes (automated). SHRM data on new-hire retention consistently links faster, more complete onboarding to higher 90-day retention rates — the automation ROI extends beyond time savings.

Common Mistakes and How to Fix Them

Mistake 1 — Mapping Fields From the Wrong Bundle

Using the raw ATS webhook payload fields in downstream modules instead of the enriched Get-Record output. Fix: always map from the most recent, complete data source — the HRIS record after Step 5, not the webhook from Step 3.

Mistake 2 — Building Sequentially When Parallel Is Possible

Chaining IT provisioning after HRIS creation after manager notification in series adds unnecessary latency. Fix: use a Router with parallel paths for steps that have no data dependency on each other.

Mistake 3 — Skipping the Fallback Router Path

A Router with no fallback path drops any record that doesn’t match a specific filter — silently. Fix: always add a final Router path with no filter as the catch-all default track.

Mistake 4 — Hardcoding Values in Module Fields

Typing a specific manager’s email or a specific LMS course ID directly into a module field means every organizational change requires a scenario edit. Fix: map dynamic fields from your data bundle or reference a lookup table.

Mistake 5 — Activating Without Error Handlers

The scenario runs, a module fails, and no one knows for three days. Fix: complete Step 9 before activation — no exceptions.

What Comes Next

A working onboarding scenario is the first component of a broader HR automation spine. The same architecture — trigger, data retrieval, Router, parallel task sequences, error handling — applies to offer letter generation, background check coordination, equipment return on offboarding, and performance review scheduling.

For a side-by-side look at how this Make.com™ architecture compares to simpler linear approaches for onboarding specifically, see the HR onboarding automation platform comparison. For the broader strategic question of where automation ends and AI begins in your HR stack, the employee onboarding automation platform guide covers the decision framework in full.

The principle that applies across all of it is the same one that applies here: build the automation spine before layering in AI. The scenario you built in this guide is that spine. Everything else builds on top of it.