Make.com Filtering and Mapping: The HR Data Pipeline That Stopped a $27K Payroll Error

Make.com filtering and mapping modules catch HR data errors before they propagate between systems. When David’s team manually transferred a $103K accepted offer to their HRIS, a keystroke produced $130K — and $27K in overpayments before discovery. A five-module Make.com pipeline eliminates that failure point entirely.

Case Snapshot: David’s HR Data Unification Problem

Why Manual Field Transfer Between ATS and HRIS Fails

Before automation, David’s team managed three systems with no native integration. Every accepted offer triggered a manual sequence: export the ATS record, open the HRIS, locate the new employee stub, and re-key approximately 40 fields — compensation, start date, job title, department, employment type, manager ID, cost center, and more. A second manual step then transferred HRIS compensation data into the payroll provider’s import template.

Two invisible failure points sat in that chain. The ATS stored compensation as a plain text string — “103000” — with no currency format and no validation. The HRIS required a numeric field with decimal precision. David’s team typed “130000” instead of “103000.” The HRIS accepted it without complaint. Payroll ran it for months. The $27K overpayment surfaced in a routine audit — after the employee had already resigned when the salary correction arrived.

The full case breakdown lives in The $27K Overpayment: How One HRIS Data Entry Mistake Cost a Manufacturer a Year of Salary. What follows is the Make.com pipeline architecture that eliminates this category of error.

Configuration 1: String-to-Numeric Type Enforcement at the ATS Output

The source of David’s error was a data type mismatch. The ATS exported compensation as a raw text string. The HRIS required a numeric value. Without a type enforcement step between them, every transfer was a manual conversion — and every manual conversion was a risk.

In Make.com, the fix is a dedicated mapping step immediately after the ATS trigger module. The parseNumber() function strips non-numeric characters, enforces decimal precision, and passes a validated numeric value downstream. If the parse fails — because the ATS record is blank, malformed, or contains a currency symbol the function doesn’t expect — a filter module routes the record to an error branch before it reaches the HRIS write module.

This single configuration catches the $103K → $130K transposition before the HRIS accepts it.

Configuration 2: Salary Range Filter Before the HRIS Write

Type enforcement catches format errors. Range validation catches magnitude errors — the transpositions, extra zeros, and copy-paste mistakes that produce a syntactically valid number that is factually wrong.

Make.com’s filter module sits between the mapping step and the HRIS write module. The filter checks: does this compensation value fall within the valid range for this job grade and employment type? If yes, the record passes. If no, the scenario routes to a Slack or email alert that sends the flagged record to a human reviewer before any HRIS write occurs.

For David’s team, this meant setting salary bands by department — ranges derived from existing HRIS records. A $130K value for a position with a $90K–$115K band triggers the alert. Nothing writes until a human confirms or corrects the value.

Configuration 3: Cross-System Field Mapping From ATS Labels to HRIS IDs

Every ATS and HRIS uses different field naming conventions. The ATS calls a field “Department” while the HRIS expects “cost_center_id” with a numeric lookup value. “Employment Type” in the ATS becomes “worker_classification_code” in the HRIS. Without an explicit mapping layer, every field transfer requires manual interpretation — and every interpretation is a point of variance.

Make.com’s mapping module creates a persistent translation table between the two systems. Each ATS field name maps to the corresponding HRIS field ID, including the value transformations required: text labels to numeric codes, date formats from MM/DD/YYYY to ISO 8601, department names to cost center IDs.

This mapping lives in the scenario — not in a spreadsheet, not in someone’s head. When the HRIS updates a field ID or the ATS changes a label, the fix is a single mapping update in Make.com, not a retraining session for the HR team. For the structural question of which validation controls belong in the system versus in the automation layer, HRIS Required Fields vs Manual Data Validation covers that decision directly.

Configuration 4: Employment Type Router for Classification-Specific Record Paths

Full-time employees, part-time employees, and contractors don’t follow the same onboarding path in the HRIS or payroll. A full-time hire triggers benefits enrollment eligibility, PTO accrual configuration, and a specific payroll tax withholding setup. A contractor triggers none of those. Running both through the same unrouted pipeline produces HRIS records with incorrect defaults — or benefits enrollment for ineligible workers.

Make.com’s router module branches the pipeline at the employment type field. Each branch carries only the modules relevant to that classification. The full-time branch writes the benefits eligibility flag, the PTO accrual rule, and the tax setup. The contractor branch skips all three and writes only the engagement-specific fields. No defaults fire for the wrong classification.

For HR teams managing a mix of worker types — a configuration common in manufacturing — this router is the difference between a clean HRIS and one that requires quarterly audits to find misconfigured records.

Configuration 5: Payroll Export Format Gate Before the Final Write

The final handoff — HRIS to payroll — carries its own format requirements. Payroll providers import compensation data in specific formats: decimal precision to two places, no currency symbols, specific date formats for pay period start and end, employee IDs in the exact format the payroll system expects. Manual exports from the HRIS rarely match those requirements, which forces manual reformatting before every payroll run.

Make.com’s format gate handles this as a dedicated transform step before the payroll write module. The step applies formatNumber(value; 2) for compensation fields, formatDate(date; "YYYY-MM-DD") for date fields, and a string replace for any characters the payroll system rejects. The output is a validated record that matches the payroll provider’s import spec exactly — no manual reformatting, no last-minute corrections before payroll closes.

What the Five-Configuration Pipeline Replaced

After David’s team implemented the Make.com filtering and mapping pipeline, the results were measurable within the first payroll cycle:

• Zero manual re-entry between ATS, HRIS, and payroll
• 15+ hours per week reclaimed from data entry and format correction
• Zero payroll discrepancies in all periods following implementation
• Full audit trail — every record transformation logged in Make.com’s execution history
• Error alerts fire before bad data reaches any system, not after a costly discovery

The pipeline runs on Make.com’s event-driven trigger — firing on every accepted-offer status change in the ATS, not on a batch schedule. New hires are in the HRIS within minutes of offer acceptance, not at the end of the week when someone gets to the export queue.

For HR teams without a dedicated IT resource, How a Non-Technical HR Team Started Building Their Own Automations With Make + AI covers the build path that doesn’t require a developer. For teams evaluating the broader operational impact of HR process standardization, the TalentEdge $312K HR process standardization case study shows what happens when filtering and mapping architecture scales across a full HR function.

Frequently Asked Questions

Does Make.com require API access to both the ATS and HRIS?

Make.com connects to most modern ATS and HRIS platforms via native modules or webhook triggers. For legacy systems without a native connector, Make.com’s HTTP module handles REST API calls directly. David’s team used a native ATS module combined with an HTTP module for their legacy HRIS — no additional middleware required.

What happens when a record fails the salary range filter?

The scenario routes the failed record to an error branch — a Slack message or email alert with the flagged record attached. The HRIS write does not execute until a human reviewer confirms or corrects the value and re-triggers the scenario. Nothing writes automatically when a validation fails.

How long does a Make.com HR data pipeline take to build?

A five-configuration pipeline connecting ATS, HRIS, and payroll runs 20–40 hours for initial build and testing, depending on legacy system complexity and whether API documentation exists. David’s team had theirs running within four weeks, including the mapping table build for the legacy HRIS fields.

Is this the same pipeline architecture TalentEdge used?

The architecture shares the same filtering and mapping principles, but the scope differs. TalentEdge’s engagement involved workflow redesign across multiple HR functions. David’s pipeline focuses specifically on the ATS-to-HRIS-to-payroll data transfer — a narrower scope with a faster build cycle and a direct line to the payroll error problem.