What is a Make.com router and how does it work in HR automation?

A Make.com Router module accepts one incoming data bundle and splits it into multiple parallel execution paths. In HR contexts, this means a single trigger — such as a new hire record appearing in your ATS — can simultaneously send data to your HRIS, payroll platform, IT provisioning system, and benefits administrator, each receiving only the fields relevant to that system.

How is a router different from a filter in Make.com?

A filter stops or passes a single execution path based on a condition. A router creates multiple distinct paths from one bundle, each of which can then carry its own filter. Filters are binary (pass/stop); routers are multiplicative (one bundle becomes N branches). You almost always use both together — the router creates the branches, and filters on each branch enforce the conditions.

What happens if one router branch fails?

By default, a failure in one branch does not halt other branches — but it also does not surface automatically unless you configure error-handling routes on each branch individually. For HR data (which often touches payroll or compliance systems), add a dedicated error route to every branch that sends an alert or logs the failure so nothing drops silently.

Do I need to clean and validate HR data before it hits the router?

Yes — routers orchestrate; they do not cleanse. If a phone number field arrives in inconsistent formats, every branch that uses that field inherits the inconsistency. Use RegEx formatters, text parsers, and deduplication filters upstream of the router.

Can I use routers for offboarding and termination workflows, not just onboarding?

Routers are especially valuable for termination flows because the required actions differ sharply by employee type, seniority, and location. A router with branches gated on employment-type and manager-flag fields can simultaneously trigger access revocation, direct-report reassignment, payroll final-pay calculation, and GDPR-compliant data retention scheduling — all from one status-change trigger.

How to Automate Complex HR Data Flows with Make.com™ Routers: A Step-by-Step Guide

Most HR automation breaks not at the trigger or the destination — it breaks at the routing layer. A new-hire record fires, and instead of reaching four systems simultaneously, it reaches one, or it reaches all four but with wrong fields, or it reaches none because a missing filter condition killed the branch silently. This guide shows you exactly how to build a Make.com™ Router scaffold that gets HR data to the right system, with the right fields, every time.

This is a focused drill-down into routing logic. For the full upstream context — deduplication, field mapping, and data quality enforcement — start with the parent guide on Make.com™ data filtering and mapping for HR automation. That upstream work is a prerequisite for everything below.

Before You Start

Get these four things in place before building a single router branch. Skipping any of them turns your router into a liability.

A clean upstream data source. Routers orchestrate; they do not cleanse. Every field that hits the Router module must already be validated and normalized. If department names are inconsistent (“Sales” vs. “sales” vs. “SALES”), every branch that filters on department inherits the inconsistency. Complete the upstream normalization work described in the guide to eliminating manual HR data entry with automation before touching the router.
A documented field map. Know exactly which fields each destination system requires before you build the branches. HRIS needs first name, last name, SSN, start date, and department. Payroll needs employee ID, salary, pay frequency, and bank routing data. IT provisioning needs first name, last name, manager email, and department. Map these on paper first.
API credentials for each destination system. Each router branch fires an API call to a different platform. Confirm you have working credentials, correct base URLs, and the right authentication method (OAuth 2.0, API key, or Basic Auth) for every destination before starting.
A test environment or sandbox. You will make mistakes on the first build. Run every test against sandbox instances of your HRIS and ATS, not production data. Make.com™ lets you pin a specific bundle for testing — use it.
Estimated build time: 3–6 hours for a 4-branch new-hire onboarding router with error handling. Add 1–2 hours per additional branch.

Step 1 — Define Your Routing Conditions Before Opening Make.com™

Router branches without documented conditions become spaghetti within two weeks. Define every branch condition in plain language first.

Open a spreadsheet and create one row per routing branch. For each branch, document:

Trigger condition: What field value or combination of values sends a bundle down this branch? (Example: “Employment Type = Full-Time AND Department = Engineering”)
Destination system: Which platform does this branch write to?
Fields transmitted: List every field this branch sends. Only send what the destination system requires — over-sending PII to systems that don’t need it is a compliance risk.
Error behavior: What happens if this branch fails? Who gets notified?

A common HR router for new-hire onboarding has four to six branches: HRIS enrollment, payroll setup, IT account provisioning, benefits eligibility trigger, manager notification, and optionally a compliance/audit logging branch. Define all of them before touching Make.com™.

Gartner research consistently identifies undefined data governance rules as the leading cause of HR tech implementation failure — branch-level condition documentation is the minimum viable governance layer for any routing scenario.

Step 2 — Build the Trigger and Upstream Normalization Block

The Router module is never the first module in your scenario. Build the trigger and normalization block first.

Set your trigger. This is typically a webhook (your ATS fires a POST request when a candidate is marked “Hired”), a scheduled data pull from your ATS via its API, or a watch trigger on a Google Sheet that your recruiting team updates manually. Choose the trigger type that matches your ATS’s integration capabilities.
Add a data normalization chain before the router. Use Make.com™’s built-in text functions to standardize every field the router branches will filter on. Department names go through a toLowerCase() function. Phone numbers go through a RegEx formatter. Employment type values get mapped to a canonical set (“FT”, “PT”, “Contractor”) using a Text/Map function. The guide to essential Make.com™ filters for recruitment data covers the specific filter patterns for the most common HR field inconsistencies.
Add a deduplication check. Before the router, query your HRIS or a Make.com™ Data Store to confirm this employee ID does not already exist. If it does, route the bundle to an exception handler immediately — do not let a duplicate record fan out across four systems simultaneously.

Only after this normalization block is confirmed working should you add the Router module.

Step 3 — Add the Router Module and Create Your Branches

With your upstream normalization block confirmed, add the Router module directly after the last normalization step.

Click the + button after your last normalization module and search for Router in the module library. The Router module does not connect to any external service — it is a native Make.com™ flow-control module.
Once the Router is on the canvas, you will see a single empty branch output. Click the + on that branch output to add your first downstream module (for example: an HTTP module making a POST request to your HRIS API).
To add additional branches, hover over the Router module itself and click Add route. Repeat for each destination system. Each branch is an independent execution path — modules on Branch 2 have no visibility into what Branch 1 is doing.
Label each branch immediately using Make.com™’s branch naming feature. Labels like “HRIS Enrollment,” “Payroll Setup,” and “IT Provisioning” save significant debugging time when a scenario has six or more branches.

Build all branches to the point where each has at least one downstream module before moving to filter configuration. An empty branch with no modules will cause Make.com™ to throw a validation error.

Step 4 — Configure Filter Conditions on Every Branch

This is the most consequential step. Filterless branches pass every bundle — including bundles that should not touch that system.

To add a filter to a branch, click the filter icon (the funnel symbol) on the line connecting the Router module to the first module of each branch. Every branch must have a filter, even if that branch is the intended “catch-all” fallback — the fallback branch should have a filter that explicitly passes anything that did not match prior branches.

For a standard new-hire onboarding router, set branch filters like this:

HRIS Enrollment branch: Filter: employment_type exists AND employee_id is not empty. This branch runs for every new hire regardless of type — it is the universal enrollment path.
Payroll Setup branch: Filter: employment_type = “FT” OR employment_type = “PT”. Contractors typically do not go into payroll — add employment_type ≠ “Contractor” as an AND condition if your system requires it.
IT Provisioning branch: Filter: start_date is within 14 days of today AND requires_system_access = true. This prevents provisioning requests from firing too far in advance.
Compliance Logging branch: No filter (or a filter that always evaluates to true). This branch catches every bundle and writes a timestamped audit record to a Google Sheet or database. It must always fire.

Asana’s Anatomy of Work Index reports that workers lose significant time to unclear process handoffs — conditional routing filters are the mechanism that makes handoff logic explicit and machine-enforced rather than implicit and human-dependent.

Step 5 — Add Error Handling to Each Branch Individually

Router branches fail independently. A 500 error from your payroll API does not halt the HRIS branch — and it does not notify you unless you build the notification. This is where most HR automation scenarios have a critical gap.

For each branch, add an error handler by right-clicking the first module in the branch and selecting Add error handler. Make.com™ offers three error handler types:

Resume: The scenario continues from the next module after the error. Use this only when the failed operation is non-critical (e.g., a welcome email failure should not block payroll setup).
Rollback: All operations in this branch since the last committed transaction are reversed. Use this for payroll and HRIS writes where a partial write is worse than no write.
Ignore: The error is swallowed and execution continues. Never use this on HR data branches — silent failures in payroll or compliance logging are a compliance and legal risk.

On every branch, add a notification module inside the error handler that sends a Slack message or email to the HR operations owner with: the branch name, the employee ID that failed, the error code, and a timestamp. Supplement this with a logging module that writes the same data to a persistent audit sheet.

The full error handling configuration options are covered in the dedicated guide to error handling in Make.com™ for resilient HR workflows.

Step 6 — Handle High-Volume Scenarios with Iterators and Aggregators

Single-record routing is straightforward. High-volume HR scenarios — bulk onboarding of a 30-person cohort, mass status updates at fiscal year-end — require an additional layer before the router.

When your trigger delivers an array of records (e.g., a JSON array of 30 new-hire objects from an ATS batch export), add a Make.com™ Iterator module between the trigger and the normalization block. The Iterator unpacks the array into individual bundles, each of which flows through normalization and then into the router independently. This means your 4-branch router processes 30 employees as 30 sequential single-record executions rather than trying to push an array through branch filters that expect scalar values.

After all branches have completed for all records, add an Array Aggregator downstream (outside the router) to collect per-branch results into a summary report. This summary can feed a Google Sheet dashboard that shows HR operations how many records were successfully routed to each system in the batch run.

Be aware that high-volume scenarios can hit API rate limits on destination systems. Stagger branch execution with Make.com™’s sleep function (inserting a 1–2 second delay between API calls) for systems that enforce strict rate limits. The full Iterator and Aggregator configuration is documented in the guide to Make.com™ Iterator and Aggregator for complex HR data.

Step 7 — Build a GDPR and Compliance Routing Layer

For HR teams operating under GDPR, CCPA, or SOC 2 requirements, add a compliance branch that enforces data residency and retention rules at the routing layer.

The compliance branch filters on fields like employee_country or data_residency_flag and routes EU employee records exclusively to EU-hosted system endpoints, blocking those records from reaching US-only systems. This is not an optional enhancement — data residency violations under GDPR carry fines of up to 4% of global annual turnover.

The compliance branch also writes a record to your audit log every time a bundle is intentionally blocked from a system due to a residency rule. This creates a documented audit trail demonstrating that your automation enforces data governance rules consistently without human intervention. The full GDPR configuration approach is covered in the guide to GDPR-compliant data filtering with Make.com™.

How to Know It Worked

Do not declare the router scenario production-ready until all of the following are confirmed:

Branch isolation test: Use Make.com™’s bundle pinning to force-execute each branch individually with a test bundle. Confirm that the correct fields reach the correct destination system. Confirm that fields excluded from a branch’s field map do not appear in the API payload sent to that system.
Filter boundary test: Run a bundle that should NOT qualify for a branch through the scenario. Confirm the filter blocks it. Run a bundle that should qualify. Confirm the filter passes it. Do this for every branch.
Error handler test: Deliberately break a branch by entering an invalid API endpoint. Confirm that the error handler fires, the notification reaches the HR operations owner, and the failure is logged to the audit sheet. Confirm other branches are not affected.
End-to-end live test with sandbox data: Run a complete live test using a fake employee record against sandbox instances of all destination systems. Confirm records appear correctly in each system with all required fields populated and no extraneous PII fields present.
Audit log verification: Check the audit log Google Sheet after the live test. Confirm every branch produced a timestamped log entry with the correct employee ID, branch name, system name, and outcome status.

Parseur’s Manual Data Entry Report estimates manual data entry costs organizations approximately $28,500 per employee per year. A fully validated router scenario that eliminates multi-system re-keying for even 10 employees represents a measurable cost reduction from day one of operation.

Common Mistakes and How to Fix Them

Mistake 1: Leaving a Branch Without a Filter

A filterless branch passes every bundle. If your HRIS enrollment branch has no filter, contractor records that should not enter the HRIS will be enrolled. Fix: add an explicit filter to every branch, including the catch-all. The catch-all’s filter should be the logical inverse of all other branch conditions.

Mistake 2: Putting Data Cleaning Logic Inside the Router

Some builders add text formatters and mapping functions inside individual router branches, creating inconsistent logic across branches. If the department normalization logic lives in Branch 1 but not Branch 3, Branch 3 will fail on records with non-canonical department names. Fix: all data cleaning goes in the upstream normalization block before the Router module. Branches receive only clean, validated data.

Mistake 3: Skipping Error Handlers on “Less Important” Branches

There is no such thing as a non-critical HR data branch. A failed welcome email is low stakes. A failed compliance audit log is a legal exposure. Fix: every branch gets an error handler, regardless of perceived importance.

Mistake 4: Testing Only the Happy Path

Most scenarios are tested with clean, complete records. Production HR data contains blank fields, unexpected special characters, and edge-case values. Fix: build a library of test bundles that includes records with missing required fields, non-ASCII characters in name fields, and employment types not in your canonical list. Run all of them before go-live.

Mistake 5: Ignoring API Rate Limits on Destination Systems

A bulk onboarding scenario that routes 50 records in rapid succession will hit the rate limit of whichever destination system has the tightest throttle. Fix: add Make.com™’s sleep function between iterations, and check each destination system’s API documentation for rate limit specifications before building the batch routing logic.

Next Steps: Connect Your Router to the Full HR Tech Stack

A router scenario that handles new-hire onboarding is one node in a larger HR automation architecture. The same routing logic applies to promotion workflows, termination flows, leave-of-absence triggers, and annual compensation review cycles — each event type has its own branching conditions and destination system requirements.

For connecting the router outputs to your full stack — ATS, HRIS, payroll, and benefits platforms — see the guide to connecting ATS, HRIS, and payroll with Make.com™. For the upstream data transformation work that makes router filters reliable, the guide to RegEx-powered HR data cleaning in Make.com™ covers the specific patterns for the field types most common in HR data payloads.

Build the router right once, and every HR workflow that touches multiple systems becomes a single-trigger operation. That is not a workflow improvement — it is a structural change in how your HR operations team spends its time.