Resume data arrives in PDFs, raw text, and parsed JSON — none of it aligned to your ATS custom fields. Map it with Make.com instead of transcribing by hand. This post walks through trigger setup, parsing logic, type conversion, field validation, and write verification for a complete, error-resistant hiring data flow.

This guide is one focused piece of a larger system. The parent resource — Master Data Filtering and Mapping in Make for HR Automation — covers the full data integrity framework. Here, the focus is narrower: the specific mechanics of mapping parsed resume data to ATS custom fields. Trigger setup, parsing logic, type conversion, filtering, writing, and verification.

Manual transcription is where hiring data breaks. Wrong data types, truncated values, blank required fields, and copy-paste errors that turn a $103,000 offer into a $130,000 payroll entry. Automating this flow with Make.com eliminates that failure mode entirely. If your team is still fighting inherited process problems upstream of this, this breakdown of fixing broken hiring processes is worth reading first.

Before You Start

Skipping prerequisites is the fastest way to build a scenario that looks functional but silently corrupts candidate records. Confirm all of the following before opening Make.com.

• ATS API access: Confirm your ATS exposes a REST API or has a native Make.com connector. Identify whether you are writing to a sandbox or production environment. Build and test in sandbox.
• Custom field schema documentation: Pull the exact API field names, data types (string, integer, boolean, date, enum), required/optional status, and — for dropdowns — the accepted option values or IDs. This is the most time-consuming prerequisite and the most important one.
• Resume source access: Know where resumes enter your pipeline — email inbox, ATS upload portal, career site webhook, or job board feed — and confirm you can trigger an automated flow from that source.
• Make.com account with sufficient operations: Complex parsing scenarios consume more operations than simple data transfers. Estimate module count before committing to a plan tier.
• Error logging destination: Set up a Google Sheet, Airtable base, or Make data store before building the scenario. You need somewhere to route failed records from day one.
• Time estimate: Four to eight hours for a single resume source with five to eight custom fields. Add time for AI parsing integration and multi-source routing.

The question of whether your HRIS required fields or manual validation is safer has a direct answer for ATS custom fields too — read the comparison here before deciding how strict to make your validation logic.

Step 1 — Audit and Document Your ATS Custom Fields

Start with your ATS, not with Make.com. Every mapping error traces back to assumptions about field names and data types that turned out wrong.

Open your ATS admin panel or API documentation and create a mapping table with four columns: Human Label (what recruiters see), API Field Name (exact string used in API calls), Data Type, and Accepted Values. Work through every custom field you intend to populate.

Common custom fields in recruiting ATS builds include:

• Years of total experience (integer)
• Highest education level (enum/dropdown)
• Primary technical skill (string or multi-select)
• Visa sponsorship required (boolean)
• Target salary range (integer or string)
• Source channel (enum — values vary by ATS)
• Certifications held (multi-select or text array)

For enum and multi-select fields, pull the exact accepted values from your ATS API. If your ATS expects bachelor_degree but your parsing returns Bachelor's, the write fails silently. Document the exact strings now.

Export this table. You will reference it in every subsequent step.

Step 2 — Configure Your Trigger Module

The trigger determines when Make.com fires the scenario. The right choice depends on where resumes enter your pipeline.

Email inbox trigger: Use the Gmail or Microsoft 365 Watch Emails module. Filter by label, sender domain, or subject line to isolate application emails. Set the trigger to watch for attachments if resumes arrive as PDFs.

Webhook trigger: Use Make.com’s Custom Webhook module when your career site or ATS posts data on submission. Copy the webhook URL into your source system and verify the payload structure before building downstream modules.

Cloud storage trigger: Use Google Drive or Dropbox Watch Files when resumes land in a designated folder. Filter by file type to avoid processing non-resume uploads.

ATS native trigger: Some ATS platforms post a webhook on new application. Use the Custom Webhook module or the ATS native connector’s trigger module if one exists. This is the cleanest option when available — the ATS hands you structured data instead of raw document content.

Name your trigger module what it actually does. “Watch Gmail — Applications Inbox” beats “Gmail” every time you open the scenario two months from now.

Step 3 — Parse the Resume Data

Parsing is the most variable step. Resume data enters in three formats: raw text extracted from PDF, structured JSON from an ATS or job board, or HTML from web form submissions. Each requires a different approach.

PDF Resume Parsing

Make.com does not parse PDFs natively. You need one of three approaches:

• Third-party parser API: Connect to a resume parsing service via an HTTP module. Pass the PDF file content as a base64-encoded string or a direct file URL. The API returns structured JSON. Common fields returned: name, email, phone, work history array, education array, skills array.
• AI extraction: Send the extracted text to an AI module (OpenAI, Claude via API, or a Make.com AI module). Prompt the model to return a JSON object with exactly the fields your ATS needs. Constrain the output format — unconstrained AI output requires its own parsing layer.
• Document parser app: Services like Eden AI or Affinda have Make.com connectors that return structured candidate data directly. Check field coverage against your ATS custom field list before committing to a parser.

Structured JSON Input

When your trigger delivers structured JSON — from an ATS webhook or job board API — parsing is a mapping problem, not an extraction problem. Use Make.com’s built-in variables to reference each field directly. The work is in step four: converting types and normalizing values.

HTML Form Submissions

Gravity Forms and similar tools post form field values as key-value pairs. Map each form field name to the corresponding ATS API field name. Watch for multi-select fields — some tools post them as comma-separated strings, others as arrays. Confirm the format before writing the mapping logic.

Step 4 — Convert Data Types and Normalize Values

This step is where most scenarios fail in production. Resume data is messy. Your ATS is not forgiving about types.

Integer Conversion

Years of experience arrives as strings like “8 years”, “8+”, or “eight.” Your ATS wants an integer. Use Make.com’s parseNumber() function to extract the numeric value. Build a fallback — if parseNumber() returns null, route the record to your error log instead of writing a blank value.

Boolean Conversion

Visa sponsorship fields return “Yes”, “No”, “yes”, “TRUE”, or nothing. Map each variant explicitly. A filter module with four branches is cleaner than a nested if() chain that becomes unreadable in three months.

Enum Normalization

Education level is the most common enum problem. Build a lookup table: your parsed values on the left, your ATS accepted values on the right. A Make.com data store works. A hardcoded if() chain also works for fields with fewer than six options. For anything larger, use the data store — it is editable without opening the scenario.

Example normalization table for an education field:

Date Formatting

Start dates and graduation years arrive in every format imaginable. Make.com’s formatDate() function handles the conversion. Your ATS API documentation specifies the required date format — ISO 8601 is common, but confirm before assuming.

Multi-Select and Array Fields

Skills and certifications land as comma-separated strings from most parsers. If your ATS API expects an array, use Make.com’s split() function to convert. If your ATS expects individual POST calls per value, add an iterator module after conversion.

Step 5 — Filter Records Before Writing

Not every parsed record should reach your ATS. Write filters that prevent incomplete or invalid records from creating bad data downstream.

Required field check: Add a filter after your parsing and conversion modules. Verify that every required ATS field carries a non-null, non-empty value. Route records that fail to your error log with a label identifying which field is missing.

Duplicate detection: Search your ATS for the candidate’s email address before writing. If a match exists, route to a separate branch — update the existing record or log for manual review, depending on your process.

Source channel validation: If your ATS enum for source channel only accepts specific values, filter out any record where your normalized value did not match a known option. A write with an invalid enum value fails at the ATS level and generates a silent error if you are not watching execution logs.

Run an OpsMap™ audit if you are uncertain about which records should actually reach your ATS and which should go to a review queue. Automating a process without mapping it first produces a faster version of the same broken workflow.

Step 6 — Write to ATS Custom Fields

With parsed, converted, filtered data ready, the write step is straightforward — if your field schema documentation is accurate.

If your ATS has a native Make.com connector: Use the Create Applicant or Update Applicant action. Map each variable from your parsing and conversion modules to the corresponding custom field. The connector handles authentication and endpoint routing.

If you are using the HTTP module: Build your POST body as a JSON object. Every custom field becomes a key-value pair. Confirm your authentication method — API key in header, OAuth bearer token, or basic auth — and configure the HTTP module accordingly. Set your sent_from and sent_to values in the request body for traceability.

Error handler on every write module: Add an onerror route set to Break with three retry attempts at 60-second intervals. On final failure, route the full data bundle to your error log with a timestamp and the ATS error response. A write module with no error handler is a silent data leak.

Name the write module specifically: “Create ATS Applicant — Custom Fields” or “Update ATS Record — Skills + Education.” Not “HTTP” or “Module 8.”

Step 7 — Verify the Write

Verification is not optional. A confirmed execution in Make.com does not mean the ATS accepted the data as expected.

Read-back verification: After your write module, add a GET request to retrieve the record you just wrote. Compare the returned field values to the values you sent. If they do not match, route to your error log and flag for manual review.

Spot-check protocol: For the first five to ten candidates processed by a new scenario, open the ATS record manually and verify every custom field. Make.com execution logs show successful module runs — they do not show whether the data looks correct inside the ATS.

Monitor execution history: In Make.com, open the scenario execution history and check for any modules that completed with warnings or partial data. A module that runs without error but returns an empty field is a parsing failure, not a write failure.

Step 8 — Build Your Error Log

Every failed or suspicious record needs a destination. Your error log is that destination.

A Google Sheet works for most teams. Columns to include:

• Timestamp of the failed execution
• Candidate email (or identifier from the trigger data)
• Which module failed
• The error message returned
• The raw data bundle at the point of failure
• Resolution status (open, reviewed, corrected)

Route every filter rejection and write failure to this sheet. Review it weekly at minimum during the first month. Patterns in the error log tell you which parsing assumptions were wrong and which field normalizations are incomplete.

If your team is running lean and error triage is already competing with everything else on the plate, this overview of fixing broken HR operations covers how to build sustainable review processes without adding headcount.

Common Failure Patterns and Fixes

Silent write failures: The module runs green but the ATS field is blank. Cause: the ATS accepted the request but ignored the field because the value did not match its validation rules. Fix: pull the exact accepted values from the ATS API and update your normalization table.

Enum mismatch on education or source: ATS returns a 400 error on write. Cause: your normalized value is close but not exact. Fix: log the raw ATS error response. It usually returns the accepted values in the error body.

Integer field receiving null: Years of experience writes as blank. Cause: parseNumber() returned null on a value like “N/A” or “—”. Fix: add a fallback value (0 or a sentinel like -1) and flag the record for manual review instead of writing null.

Duplicate records created: Every resume creates a new ATS record even for returning candidates. Cause: duplicate detection step missing or email field blank on some records. Fix: add duplicate detection before the write module and add a separate filter to catch records with no email address.

Date field rejected: ATS returns a format error on graduation year. Cause: your parser returns “2019” as a year string but the ATS expects a full ISO date. Fix: append a default month and day — “2019-05-01” satisfies most ISO date validators when only the year is known.

Scaling the Scenario

A single-source scenario for one ATS is a proof of concept. Production recruiting operations pull from multiple sources: job boards, LinkedIn, direct site applications, referrals, and agency submissions. Each source has its own data format and its own parsing logic.

Build source routing into the scenario from the start. A Router module after your trigger lets you direct each source to its own parsing branch before merging back into a shared conversion and write flow. This is cleaner than duplicating the entire scenario per source and easier to maintain when your ATS custom fields change.

When the scenario reaches eight to twelve modules per source branch, document it. Make.com scenario documentation does not write itself, and the recruiter who inherits this workflow six months from now will not know why the education normalization table has fourteen rows. The OpsMesh™ framework treats documentation as part of the build, not an afterthought.

For teams thinking about the wider question of whether to build automation in-house or bring in a partner for this work, this comparison of DIY automation vs. hiring a Make partner walks through the decision criteria without the sales pitch.

What a Production-Ready Version of This Scenario Looks Like

A scenario that maps resume data to ATS custom fields in production has these characteristics:

• Every module is named for what it does, not what it is
• Every external API call has an error handler with retry logic
• Every required field has a null check before the write module
• Enum and boolean values run through a normalization table, not hardcoded strings
• Duplicate detection runs before every create operation
• Failed records route to a named error log with full context
• A read-back verification step confirms field values in the ATS after each write
• Notes explain any non-obvious logic to the next person who opens the scenario

If a scenario you inherited or built does not hit all of these, it is not broken yet. It will be. The fixes are not complex — they are just skipped when speed matters more than correctness. Building them in from the start costs an hour. Fixing a candidate database with corrupted custom field data costs weeks.