HR automation breaks at the data layer. Nested arrays in webhook payloads — skills lists, education history, work experience — get silently dropped by auto-mapping. The workflow runs green, the records are incomplete, and nobody knows until the damage is done. This is what fixing it looks like inside Make.

When the Automation Runs Green and the Data Is Still Wrong

Nick’s team was not starting from zero. They had already connected their application intake form to their ATS via webhook. The Make scenario ran on every submission. The execution log showed green checkmarks on every run. What they did not know: every candidate record in the ATS was incomplete.

The application form collected contact details, a skills list, education history, and work experience. The ATS received contact details. Skills, education, and work history were missing from every record. No error fired. No alert triggered. The data was gone — silently, on every run, for three weeks.

This is the canonical nested-array failure pattern. The webhook payload arrived as a JSON object with top-level scalar keys for name, email, and phone. Nested inside were arrays: a skills array holding multiple strings, an education array holding objects for degree, institution, and graduation year, and an experience array holding objects for employer, title, and dates. Make’s auto-mapping scanned the top-level keys and mapped them. It did not descend into the arrays. They were ignored.

By the time Nick identified the problem, three weeks of records contained only contact information. Reconstructing the missing data meant going back to original application emails and re-entering skills and history by hand — the exact work the automation was supposed to eliminate.

According to Parseur’s Manual Data Entry Report, manual data entry costs organizations an average of $28,500 per employee per year in processing time and error correction. For a 3-person team each spending 15 hours a week on file processing, that number was not a benchmark — it was the operating reality they were trying to escape.

Why Auto-Mapping Fails on Nested JSON

Auto-mapping in Make works on scalar values — strings, numbers, booleans. A field that holds "John Smith" maps cleanly. A field that holds ["Python", "SQL", "Tableau"] does not, because the value is an array, not a string. Auto-mapping has nowhere to put it.

The same problem applies to arrays of objects. Work history is not a string. It is a collection of structured records, each with its own keys. Auto-mapping sees the container, finds no scalar to extract, and skips it.

This behavior is not a bug. It is the expected result of applying a tool designed for flat data to structured data. The mistake is expecting the tool to handle something outside its scope without any configuration that tells it how.

There are three nested-array patterns that cause the most damage in HR workflows:

• Arrays of primitives — a skills list, a list of certifications, a list of preferred locations. Each item is a plain string or number.
• Arrays of objects — education history, work history, references. Each item is a structured record with multiple fields.
• Mixed nesting — a top-level object that contains both scalar keys and nested arrays at the same level. Auto-mapping grabs the scalars and drops the arrays entirely.

All three require explicit handling. The path to that handling runs through two Make modules: JSON Parse and Iterator.

OpsMap™ Before Any Module Gets Built

The rebuild started with an OpsMap™ session — a structured discovery pass that maps data sources, payload shapes, destination field requirements, and failure modes before any scenario work begins. The goal is not to find the fastest path to a working scenario. The goal is to understand the data well enough that the scenario does not silently fail.

For Nick’s intake workflow, OpsMap™ surfaced three things that the original build had skipped:

1. The actual webhook payload shape. Nobody had looked at a raw payload before building the first scenario. The nested arrays were not discovered until the data loss was already in production.
2. The ATS field structure. The destination ATS stored skills as a pipe-delimited string, not an array. Education and experience were stored in separate related records, not as fields on the candidate object. The scenario needed to write to three separate endpoints, not one.
3. Array size variance. Candidate resumes ranged from 2 skills to 40. Education records ranged from 1 to 4. Work history ranged from 1 to 12 positions. Any solution had to handle the full range without hardcoded positions.

Without those three inputs, the rebuilt scenario would have repeated the same class of error in a different form. The OpsMap™ pass is what made the rebuild fixable rather than just different.

For a full walkthrough of what this discovery step looks like, see What Is OpsMap? The Discovery Step That Prevents Automation Mistakes.

The Fix: JSON Parse, Iterator, and Explicit Field Mapping

The rebuilt scenario replaced a single HTTP module with a structured five-module sequence for handling the nested payload. Here is how each piece works.

Step 1: Webhook Receives the Raw Payload

The webhook module receives the full JSON body from the application form. Nothing changes here. The payload shape is the same. What changes is what happens next.

Step 2: JSON Parse Unpacks the Structure

Make’s JSON Parse module takes the raw payload body and unpacks it into a structured bundle that subsequent modules can reference by key. Without this step, the payload body is treated as a string — nested arrays and all — and downstream modules cannot address individual fields inside it.

The JSON Parse module requires a data structure definition. That definition tells Make what keys to expect and what type each value is — string, number, array, or array of collections. Defining the arrays explicitly is what unlocks them for downstream processing. Without the structure definition, Make does not know the arrays exist as addressable objects.

Step 3: Aggregate the Skills Array Into a String

The skills array — an array of plain strings — needed to land in the ATS as a single pipe-delimited field. Make’s Array Aggregator module handles this. It iterates over the array and joins each item with a separator character. The output is a single string ready to write to the ATS skills field.

This is the right tool for arrays of primitives. The Iterator is for arrays of objects, where each item requires individual field-level processing.

Step 4: Iterator Processes Each Education and Experience Record

Education history and work experience are arrays of objects. Each education record holds degree, institution, graduation year, and field of study. Each experience record holds employer name, job title, start date, end date, and a description field.

Make’s Iterator module takes an array and outputs each item as its own bundle — one at a time, in sequence. The module that follows the Iterator runs once per item. Field references inside that module use the item’s keys directly: degree, institution, employer, title.

For Nick’s scenario, the Iterator fed into an HTTP module that wrote each education record to the ATS education endpoint and each experience record to the ATS experience endpoint. Both endpoints expected individual records, not arrays. The Iterator produced exactly that.

Step 5: Field-Level Validation Before the ATS Write

The final addition was a validation filter between the Iterator output and the ATS write module. The filter checked for two conditions: the required fields were present and non-empty, and the data types matched what the ATS endpoint expected. Records that failed validation routed to a separate error path and wrote a row to a Google Sheet flagged for manual review.

This is the structural difference between a scenario that silently drops data and one that surfaces the problem. The original scenario had no validation layer. Every record wrote — with or without complete data. The rebuilt scenario only writes records that pass the field-level checks.

What the Rebuilt Scenario Handles

After the rebuild, Nick’s scenario processed the same 30–50 weekly resume payloads with a materially different result:

• Skills arrays of any length aggregated correctly into the ATS pipe-delimited field
• Education records — one or four — each wrote to the correct ATS endpoint with all fields populated
• Experience records — one or twelve — each wrote individually, preserving employer, title, and date data
• Incomplete or malformed records flagged to the review sheet instead of writing partial data silently
• The scenario ran without modification across the full range of candidate complexity

The 150+ hours per month the team spent on manual file processing dropped to near zero. The ATS records were complete. The review sheet flagged roughly 3–4 records per week with data quality issues from the source form — issues that existed before Make was in the picture and would have been invisible without the validation layer.

The Three Rules That Prevent Nested-Array Failures

Nick’s scenario is a specific case. The underlying rules apply to every HR automation that touches structured JSON.

Rule 1: Inspect the raw payload before building anything. Pull a real webhook delivery. Open it. Find every array key. Note whether each array holds primitives or objects. That inspection takes ten minutes and prevents three weeks of silent data loss.

Rule 2: Define the data structure in JSON Parse explicitly. Auto-mapping works on scalars. Arrays require a structure definition that names them and types them. Define every array in the structure before referencing it downstream.

Rule 3: Match the processing tool to the array type. Arrays of primitives go to Array Aggregator. Arrays of objects go to Iterator. Using the wrong tool produces either an error or a silent failure — and silent failure is worse.

These rules apply regardless of the payload source — ATS webhooks, HRIS exports, applicant tracking forms, payroll API responses. Any time the source is JSON and the shape includes nested arrays, the same three rules govern the build.

Where This Fits in the Broader HR Automation Stack

Fixing the JSON layer is one piece of a complete HR automation build. The intake scenario handles candidate data. Connected workflows handle offer generation, onboarding task creation, benefits enrollment triggers, and offboarding sequences. Each of those workflows has its own data layer — its own payload shapes, its own nested structures, its own failure modes.

The same OpsMap™ approach that surfaced Nick’s nested-array problem applies to every workflow in the stack. Map the data first. Define the structure explicitly. Validate before writing. Build in that order and the execution logs mean something.

For teams running multiple HR workflows through Make, the compound effect of clean data handling is significant. A single scenario with validated writes is one clean record. A stack of ten validated scenarios is an ATS, an HRIS, and a payroll system that all reflect the same ground truth — automatically, without a team of three spending 150 hours a month keeping them in sync by hand.

If you are building HR automation and hitting silent data loss, data type mismatches, or incomplete records in downstream systems, the root cause is almost always in the JSON layer. The fix is not a different tool or a more complex scenario. The fix is the JSON Parse module, an Iterator, and a validation filter — configured explicitly against the actual payload shape your source system sends.

For more on how this fits into a complete HR automation stack, see data filtering and mapping in Make for HR automation and 6 Ways the Make MCP Changes Automation Work for HR Teams.

If you want the OpsMap™ discovery process applied to your current HR workflows before the next build, that is where every 4Spot engagement starts — see what OpsMap™ covers.