Master Make Mapping Functions for HR Data Transformation

Make.com mapping functions are the translation layer between what your HR source systems send and what your destination systems accept. Configure them correctly and your ATS-to-HRIS pipeline runs without manual correction. Skip them and every field mismatch becomes a data integrity problem that reaches payroll or compliance records.

Raw HR data breaks automation. Not because your scenario logic is wrong — because an ATS sends a single “Full Name” string when your HRIS expects two separate fields, or a job board delivers skills as a comma-separated blob when your talent platform wants individual tags. These mismatches are not edge cases. They are the default state of every HR tech stack that has not been explicitly mapped.

Make.com mapping functions are the deterministic translation layer that resolves those mismatches before they corrupt a record. This guide walks through every step of configuring them correctly — from prerequisites through verification — so your HR scenarios run on real candidate data without manual intervention. For the strategic context of where mapping fits in a complete data pipeline, start with the parent pillar: Master Data Filtering and Mapping in Make.com for HR Automation.

Before You Start

Complete these prerequisites before touching a single mapping panel. Skipping them is the primary reason mapping configurations fail in production.

• Export real data from every source system. Download at least 20 actual records from your ATS, job board, or HRIS — not demo data. Real exports surface inconsistent capitalization, missing fields, and non-standard phone formats that clean sample data hides.
• Document field requirements for every destination system. Identify exact field names, accepted data types (string, integer, boolean, array), and enumerated option values. The ATS “Employment Type” field expects “Full-time” not “Full Time” — that space matters.
• Map the gap list on paper first. Before opening Make.com, write down every source field and its destination field. Flag mismatches in type, format, or structure. These flags become your mapping function checklist.
• Work in a test environment. Never develop mapping logic against a live scenario. Clone the scenario and connect it to sandbox credentials.
• Time required: 2–4 hours for a typical ATS-to-HRIS integration with 15–25 mapped fields. Complex aggregations add another 1–2 hours.
• Risk level: Incorrectly mapped fields that reach payroll or compliance records are expensive to remediate. Bad data fed into downstream systems compounds errors faster than manual processes correct them.

Step 1 — Open the Mapping Panel and Inspect Raw Field Output

Before writing a single function, confirm exactly what your source module is actually sending. Make.com shows the raw bundle output from every module run — use it.

Run your scenario once with a real record. Click the output bubble on your source module (the small circle that appears after a run). You will see the full data bundle: every field name, its value, and its data type. This is your ground truth. Compare it against the destination field requirements you documented in prerequisites.

Common discoveries at this step:

• The “Full Name” field contains “SMITH, John” in last-first format — not “John Smith” — so a simple split() without additional transformation produces incorrect first/last output.
• A date field arrives as a Unix timestamp (1711497600) rather than a human-readable string.
• A boolean “Active” field arrives as the string “true” rather than a true boolean, which fails a destination field expecting the boolean type.
• An array field arrives flattened as a single comma-separated string.

Document every discrepancy. Each one requires a specific function. Do not proceed to Step 2 until every source-to-destination gap is named.

Step 2 — Apply String Functions for Name and Text Fields

Name fields are the most common transformation problem in HR automation. ATSs frequently store full names in a single field. HRISs almost universally want separate first and last name fields.

For a “First Last” format source field, use {{split(1.fullName; " ")[]; 1}} to extract the first name and {{split(1.fullName; " ")[]; 2}} to extract the last name. For “Last, First” format, reverse the split and strip the comma: {{trim(split(1.fullName; ",")[]; 2)}} for first name and {{trim(split(1.fullName; ",")[]; 1)}} for last name.

Additional string transformations that appear frequently in HR data:

• Capitalization normalization: {{capitalize(lower(1.department))}} converts “HUMAN RESOURCES” or “human resources” to “Human Resources.”
• Whitespace stripping: {{trim(1.jobTitle)}} removes leading and trailing spaces that cause lookup failures in destination systems.
• Email normalization: {{lower(1.email)}} forces all email addresses to lowercase before they hit your HRIS, preventing duplicate records from case differences.
• Phone formatting: {{replace(replace(replace(1.phone; "-"; ""); "("; ""); ")"; "")}} strips all formatting characters and leaves a raw digit string you can reformat to your destination’s required pattern.

Step 3 — Apply Date and Time Functions

Date fields break HR integrations at a high rate because every system has a preferred format and most systems do not reject invalid formats — they store them silently and produce errors downstream when a report or calculation references the field.

Make.com’s formatDate() function converts any date value to any output format. The syntax is {{formatDate(1.startDate; "YYYY-MM-DD")}} where the second argument is the target format string.

Common HR date scenarios:

• Unix timestamp to ISO date: {{formatDate(1.createdAt; "YYYY-MM-DD")}} converts a timestamp like 1711497600 to “2024-03-27.”
• ISO date to US format: {{formatDate(1.hireDate; "MM/DD/YYYY")}} converts “2024-03-27” to “03/27/2024” for systems expecting US date format.
• Adding timezone context: {{formatDate(1.interviewTime; "YYYY-MM-DD HH:mm:ss"; "America/Chicago")}} converts UTC timestamps to a specific timezone before storing them in a calendar system.
• Calculating days elapsed: {{dateDifference(now; 1.applicationDate; "days")}} produces the number of days since an application was submitted, useful for SLA tracking in ATS workflows.

Always verify the output format against the destination system’s field validation rules before running a full batch. A single malformed date in a required field stops the entire record.

Step 4 — Handle Boolean and Enumerated Value Conversion

HR systems enforce strict enumerated values on fields like employment type, status, and department. A value of “Full Time” fails when the destination expects “Full-time.” A string “true” fails when the destination expects a boolean true. These are not bugs in your scenario logic — they are data contract violations that require explicit mapping.

For boolean conversions from string to boolean:

• {{if(1.active = "true"; true; false)}} converts the string “true” to a boolean true and any other value to boolean false.
• {{if(1.status = "Active"; true; false)}} converts a status string to a boolean for destination systems that store active state as a boolean flag.

For enumerated value normalization, use a switch() function to translate every possible source value to its required destination value:

{{switch(1.employmentType; "Full Time"; "Full-time"; "Part Time"; "Part-time"; "Contract"; "Contractor"; "Unknown")}}

The final argument (“Unknown” in the example above) is the fallback value for source values not covered by the mapping. Set it to a value that triggers a downstream error handler rather than silently inserting bad data.

Step 5 — Transform Array and Multi-Value Fields

Skills, certifications, and competency fields regularly arrive as comma-separated strings from job boards and ATSs. Talent platforms and HRISs frequently want those values as individual array items, separate records, or checkbox fields.

To split a comma-separated string into an array:

{{split(1.skills; ",")}}

This produces an array that downstream modules can iterate over. If you need to pass individual items to a module that expects one value at a time, connect the split() output to an iterator module. Each array item becomes a separate bundle processed by subsequent modules in the scenario.

To join an array back into a string when the destination expects a delimited format:

{{join(1.tags; "; ")}}

This produces a semicolon-delimited string from an array input. Use the specific delimiter your destination system expects — not all systems use commas, and some require no spaces after the delimiter.

For deduplication before processing, combine split() with the array functions available in Make.com’s built-in tools. A skills field that arrives as “Excel, Excel, PowerPoint” produces a redundant record if not deduplicated before writing to a talent profile.

Step 6 — Apply Conditional Logic for Missing or Null Fields

Source systems send incomplete records. An application with no phone number still needs to reach your HRIS without breaking the scenario. Conditional mapping prevents null field errors from stopping your automation.

The ifempty() function handles missing fields cleanly:

{{ifempty(1.phone; "Not Provided")}}

This passes the phone value when present and substitutes “Not Provided” when the field is null or empty. Substitute the fallback value with whatever your destination system accepts for optional fields.

For more complex conditional logic where the action depends on multiple conditions:

{{if(and(1.startDate; 1.department); formatDate(1.startDate; "YYYY-MM-DD"); "")}}

This formats the start date only when both the start date and department fields are present. When either is missing, it passes an empty string instead of failing. Complex conditional chains belong in a Code module (JavaScript) when the if() nesting becomes difficult to read — Make.com’s Code module accepts the full data bundle as input and returns transformed values to the downstream mapping panel.

Step 7 — Test Against Real Records Before Production

Mapping functions that look correct in the panel fail on records that deviate from the pattern you built against. Testing against a single record is not enough.

Run your scenario against a batch of at least 20 real records from your source system before activating it. Review the output bundles for:

• Null outputs where values were expected. A function that produces an empty string instead of a transformed value means your source field name is wrong, the record format differs from your test case, or the function logic has a gap.
• Destination system rejection errors. Check the execution log for 400 or 422 errors from your destination API. These carry field-level detail about which value failed validation.
• Unexpected fallback values. If your switch() function’s fallback value appears frequently, the source system is sending values your mapping doesn’t cover. Add those values before production.
• Format drift across record types. A job board that sends dates as “March 27, 2024” for some records and “2024-03-27” for others requires a conditional date parser, not a single formatDate() call.

If you are running large batches for the first time, use Make.com’s execution history to review individual bundle outputs. Filter by error status to isolate failures without scrolling through successful records.

Where Mapping Fits in the Larger HR Automation Stack

Data mapping is not a one-time configuration task. Every time a source system updates its API, adds a field, or changes an enumerated value list, your mapping layer needs a corresponding update. Build a documentation habit alongside your mapping work — record every function, its source field, its destination field, and the logic applied. That documentation is the difference between a 20-minute update and a four-hour debugging session when a vendor changes their schema.

For HR teams building automation without dedicated technical staff, the combination of Make.com and AI-assisted build tooling has compressed what used to be developer work into operator-level tasks. The non-technical HR automation case study covers how teams with no coding background are handling exactly these mapping challenges using Make.com’s visual interface alongside AI assistance for function syntax.

The mapping layer described in this guide is one component of a structured automation engagement. An OpsMap™ discovery process identifies which HR workflows are ready to automate and which data contracts need cleanup before automation works reliably. Skipping that step and building mapping functions on top of inconsistent source data produces automations that work in testing and fail in production — because real records are messier than the ones you built against.

The Make.com MCP and HR automation guide covers how the MCP server layer changes the build process for these integrations, including how to generate mapping configurations from API documentation without writing every function by hand. If you are managing a stack of existing Make.com scenarios and need to audit what mapping logic is already in place, the OpsMap discovery process provides the framework for doing that systematically before building new integrations on top of what you already have.