Make error handling for HR automation requires five configurations: a module failure audit, upstream input filters, explicit error directives — Break, Resume, or Rollback — retry logic for transient API failures, and a structured exception log. Without all five, a single API outage leaves your ATS, HRIS, or payroll systems in a partial-write state.

Clean data filtering and mapping prevents most HR automation failures. Error handling catches the ones that slip through. Together they form the two layers every production-grade HR scenario needs before it touches live candidate or employee data. If you want to see how these layers connect at the infrastructure level, six ways the Make MCP changes automation work for HR teams walks through the architecture.

Below are the five Make error handling configurations every HR scenario needs before it goes live.

1. Audit Every Module for Its Most Likely Failure Mode

Before adding a single error route, map what can break at each module. Open your scenario and work left to right. For each module, answer three questions:

1. What data does this module require? List every required field and its expected format — string, integer, ISO date, valid email address.
2. What external dependency does it call? External API calls to your ATS, HRIS, payroll provider, or email service fail for reasons outside your control: rate limits, maintenance windows, credential expiry.
3. What is the consequence if this module fails silently? A log-row append failing silently is annoying. A payroll write failing silently is a compliance event.

Document this as a table: module name, required inputs, external dependency (yes/no), consequence severity (low / medium / critical). That table drives every configuration decision that follows.

2. Add Input Validation Filters Upstream of Every Critical Module

Error handlers catch failures after they occur. Filters prevent failures from occurring. Both are required — but filters are cheaper and faster.

For every module flagged medium or critical in your audit, add a Make filter immediately upstream. Configure it to verify:

• Presence: Required fields — first name, last name, email, employee ID — are not empty.
• Format: Dates follow ISO 8601 (YYYY-MM-DD). Employee IDs match your expected pattern. Email addresses pass a basic regex check.
• Range: Numeric fields — salary, hours, headcount — fall within realistic bounds. A $0 salary writing to payroll is a data error, not a valid input the downstream system should receive.

When a filter blocks a record, route it to a dedicated notification module — Slack, email, or a log row — that captures what was blocked and why. That notification is your audit trail for the input that never reached the downstream system.

For scenarios where filter logic becomes complex, see how to set up routed error handling in Make with AI assistance — the same routing principles apply to filter fallback paths.

3. Assign an Explicit Error Directive to Every Module

Make’s default behavior on module failure is to mark the execution as an error and stop — no retry, no notification, no rollback. That silent failure is the fastest way to corrupt your ATS or HRIS with a partial write. Every module in a production HR scenario needs an assigned directive.

Break — stops the execution and marks it as an error. Use on non-critical modules where stopping is the correct response and a human can review the execution log. Break does not undo writes that already succeeded in the same bundle.

Resume — continues execution with a defined fallback value (empty string, null, default ID). Use only when the failure is recoverable and the downstream module accepts the fallback. Never use Resume to skip a write — use it only when a missing value is acceptable to the receiving system.

Rollback — signals Make to undo all writes in the current bundle for modules that support transactions. Use exclusively on critical modules — payroll writes, benefits enrollment, offer letter generation — where a partial write creates a compliance or legal risk. Not every Make module supports Rollback; verify in the module documentation before relying on it.

Ignore — continues without marking an error. Use only for genuinely optional modules — audit log appends, Slack notifications — where failure has zero downstream consequence. Ignore on a data-write module is almost always a configuration mistake.

4. Configure Retry Logic on Every External API Module

Transient failures — a 429 rate-limit response, a 503 maintenance window, a connection timeout — are not errors in your scenario logic. They are infrastructure events. Retry logic handles them without human intervention.

The 4Spot standard for HR scenarios: three retry attempts at 60-second intervals before escalating to Break. Apply this to every module with an external API dependency — your ATS connector, HRIS webhook, payroll endpoint, or email provider.

Configure retry at the error handler level, not the module level. Right-click the module, select Add error handler, choose Break as the directive, then enable the retry toggle: three attempts, 60 seconds. If all three attempts fail, Make logs the execution as an error and the Break directive fires — giving your team a clean, reviewable failure instead of a silent gap in your data.

For scenarios where self-diagnosing retry logic replaces manual investigation entirely, see how to build a self-diagnosing error handler in Make using an MCP server. A real-world result: an AI-built error handler cut technician research time from 20 minutes to a glance.

5. Build a Structured Exception Log for Every Error Route

Retry logic and error directives handle failures in real time. A structured exception log creates the audit record your HR and compliance teams need after the fact.

Add a dedicated log module at the end of every error route — not at the end of the happy path. Each log entry captures:

• Execution ID: The Make execution URL via {{var.scenario.executionUrl}} so any team member pulls the full run in one click.
• Timestamp: When the failure occurred — ISO 8601, UTC.
• Module name and position: Which module failed and where it sits in the scenario flow.
• Error code and message: The exact response from the external API — not a paraphrase.
• Input payload: The data that triggered the failure, redacted for PII where required by your data handling policy.
• Directive applied: Whether the scenario Broke, Resumed, Rolled Back, or Ignored — so the audit record is self-contained.

Route this log to a dedicated Airtable base or Google Sheet — separate from the data store your scenario writes production records to. Keeping the exception log isolated means a log write failure never corrupts production data, and it gives you a clean dataset for monthly error-rate reviews.

Frequently Asked Questions

What is the difference between Break, Resume, and Rollback in Make?

Break stops execution and marks it as an error. Resume continues with a defined fallback value. Rollback undoes all writes in the current bundle for modules that support transactional writes — use Rollback only on compliance-critical modules like payroll and benefits enrollment, and only after confirming the module supports it.

Do I need error handling if I already have input validation filters?

Yes. Filters prevent predictable data failures — missing fields, wrong formats, out-of-range values. Error handlers catch unpredictable infrastructure failures — API outages, rate limits, credential expiry. Filters alone leave your scenario exposed to API failures; error handlers alone let bad data through to systems that should reject it.

How many retry attempts should I configure for an HR API module?

Three attempts at 60-second intervals covers most transient API issues — rate limit resets, brief maintenance windows — without holding execution bundles open long enough to create backpressure on your scenario queue. If the third attempt fails, escalate to Break so the failure is visible in the execution log.

Can I use Rollback on any Make module?

No. Rollback works only on modules that support transactional writes. Most third-party API connectors in Make treat each write as final and do not support Rollback. Check the module documentation before configuring it, and test Rollback behavior in a sandbox scenario against non-production data before deploying to live HR systems.

Where should I route the exception log — Airtable or a Google Sheet?

Either works. The requirement is isolation — the exception log destination must be separate from the data store your scenario writes production records to. A log write failure cannot be allowed to corrupt production data, and the log dataset needs to stay clean for compliance review without mixing in operational records.