Every module in a Make scenario can have an error handler directive attached to it, and the five options — Ignore, Resume, Break, Commit, Rollback — look like a settings dropdown but actually encode very different decisions about what happens to the data a scenario has already touched when something fails partway through. Picking one without understanding the difference is how you end up with half-written records that nobody notices until reconciliation.
Ignore is almost never what you want
Ignore swallows the error and continues the scenario as if the module succeeded, using whatever output the module produced (often empty). It exists for genuinely optional side effects — logging to a metrics endpoint that's allowed to fail without affecting the main flow. Attached to anything that writes business data, Ignore means a failed write is treated as a successful one downstream, which is the exact failure mode of "three line items imported and the fourth silently didn't" that shows up as a customer complaint two weeks later instead of an alert the same day.
Resume substitutes a fallback value
Resume lets you supply a fallback output for the failed module and continue, which is appropriate when there's a genuine sane default — a currency conversion API that's down can fall back to the last known rate, logged as such. It's the right tool exactly when you can say out loud what the fallback value should be and why it's safe; if you can't answer that, Resume is Ignore wearing a nicer name.
{
"module": "http:ActionSendData",
"name": "Create Invoice",
"onerror": [
{"directive": "Break", "parameters": {"delay": 300, "attempts": 3}},
{"module": "slack:CreateMessage", "name": "Alert on final failure"}
]
}Break is the retry primitive
Break stops the current execution, stores its state, and lets Make automatically retry the run later (with a configurable delay and attempt count) or lets you manually resume it from the point of failure. This is the correct default for transient failures — a downstream API returning a 503, a rate limit, a timeout — because it preserves the exact data the scenario was working with rather than discarding it or substituting something else.
If every retry attempt is exhausted, the execution sits in an incomplete state indefinitely unless something notifies you. Chain a notification module after the Break directive's retry attempts are exhausted — Make's own interface won't page anyone for you.
Commit and Rollback matter specifically for database-backed modules
Commit and Rollback apply to modules that participate in Make's transaction handling (mainly database modules). Rollback undoes changes made earlier in the same execution when a later module fails, which is the closest thing Make has to an actual transaction boundary — useful when a scenario writes to more than one table and a failure partway through would otherwise leave them inconsistent. Outside of true transactional modules, there's nothing to roll back, so this pair is a narrower tool than the other three.
Design the route around the failure mode, not the module
The question to ask per module isn't "what error handler should this have" in the abstract, it's "if this specific call fails, what state does the world end up in, and is that acceptable." A read-only lookup failing is low-stakes and can often use Resume with a safe default. A write that creates a financial record should almost always Break-and-retry with an eventual alert, never Ignore.
Force a module to fail deliberately (a bad URL, a token you know is expired) and confirm the error route does what you designed it to do. Scenarios are rarely tested this way, which is why error handler misconfiguration is one of the most common causes of silent data loss in Make.
Wrapping up
Ignore, Resume, Break, Commit, and Rollback aren't interchangeable severity levels — they're different answers to "what happens to the data." Default to Break-with-retry-and-alert for anything that writes business data, reserve Resume for cases where you can name the fallback out loud, and treat Ignore as a last resort for genuinely optional side effects. The dropdown is small; the consequences of picking wrong aren't.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.