Our verdict: default to Retry for anything you cannot lose
For a reminder or invoice workflow, losing a record silently is usually worse than a delay. We would add Retry to modules that call outside services and turn on incomplete executions, so a failed bundle is stored instead of dropped. [1] [4] We would reserve Skip for data problems that are genuinely occasional and harmless, which is also how Make's overview frames it. [1]
Who this fits: anyone running a Make scenario that writes to another app. Who can skip it: a one-off manual scenario where you watch every run.
What each handler does
Make renamed two handlers: Ignore is now Skip, and Break is now Retry. [2] The table summarizes Make's overview page. [1]
| Handler | What happens to the failed bundle | Scenario stops? | Run status |
|---|---|---|---|
| Skip (formerly Ignore) | Dropped; the next bundle continues [1] [2] | No [1] | Success [1] |
| Retry (formerly Break) | Stored with the remaining steps as an incomplete execution [1] [4] | No [1] | Warning [1] |
| Resume | Replaced with a substitute output you define [1] [5] | No [1] | Success [1] |
| Commit | Run stops; changes so far are committed in database apps [1] | Yes [1] | Warning [1] |
| Rollback (default) | Run stops; changes in transaction-supporting modules are reverted [1] | Yes [1] | Error [1] |
Incomplete executions in plain terms
Make describes incomplete executions as a safety feature that keeps scenarios from stopping on errors and helps prevent data loss: the unfinished run is saved in the Incomplete executions tab. [3] You enable it under Scenario settings with Store incomplete executions, which is off by default. [3] Retry requires it. [4] There is an organization-wide maximum tied to your usage allowance, and exceeding it produces an error message. [3]
With Retry, you can set Automatically complete execution so Make retries based on a number of attempts and an interval, or leave stored runs for manual resolution. [4]
Worked example: a reminder scenario
Hypothetical example: a scenario reads tomorrow's appointments from a sheet, looks up each client in a CRM, and sends a reminder email. On one run, the CRM lookup fails for one client because of a temporary outage, and another client has no email address.
With no handler, Rollback applies: the run stops with an error and later clients are not processed. [1] With Retry on the CRM module and Store incomplete executions enabled, the failed client is stored and the other clients continue, and the run ends with a warning you can see. [1] [3] [4] For the missing address, Resume with a placeholder review address keeps the run going while routing that reminder to someone who can fix the record. [5] Skip would also keep the run going, but the client would simply not get a reminder and the run would still show success. [1]
In this hypothetical, Retry and Resume together protect every client; Skip alone would hide two problems.
Procedure: choose a handler per module
- List each module that talks to an outside app.
- Ask: if this fails, can the record be dropped? If yes and failures are rare, Skip. [1]
- Is there a safe placeholder value, such as a review address for a missing email? If yes, Resume. Make's own example substitutes a placeholder address so the record can be reviewed. [5]
- Must the record be processed eventually? Turn on Store incomplete executions and use Retry. [3] [4]
- Must partial database writes be kept or reverted? Choose Commit or Rollback. [1]
- Hypothetical check: send one test bundle with a deliberately missing field and confirm where it ends up.
Pitfalls
- Skip records the run as a success, so dropped bundles do not stand out in the history. [1]
- Resume also ends in success; a placeholder value can flow into later steps, such as an email to a review address. [1] [5]
- Without any handler, Rollback applies and repeated errors can deactivate the scenario. [1]
- Retrying a step that already sent an email can send it twice. Pair Retry with a duplicate check, as described in the webhook duplicates guide.
Our decision rule
Turn on incomplete executions for every production scenario, put Retry on outside calls, and use Skip or Resume only where a dropped or substituted record is acceptable and visible to someone. Leave Rollback as the default only for scenarios where stopping is the safe outcome.
Watch demos / Official walkthroughs
See how the tools work.
Videos load from YouTube only when you press play. These are provider videos, not our own product tests.
Make / Official video
Make—Building Your First Automated Workflow from Scratch
What to look for: Follow how modules connect and how data moves through the first workflow.
Watch on YouTubeQuestions before you decide
What happened to Make's Ignore and Break handlers?
The Make Help Center says the Ignore error handler has been renamed to Skip and the Break error handler has been renamed to Retry. Older tutorials may still use the old names.
What does Make do if I add no error handler?
Make's error handling overview says Rollback is the default when you set no error handling. The run stops with an error status, and the scenario is deactivated after repeated runs with errors.
Are incomplete executions on by default?
No. The Help Center says the Store incomplete executions setting in scenario settings is disabled by default.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Make Help Center: Overview of error handling Accessed 13 Oct 2026
- Make Help Center: Fix missing data errors Accessed 13 Oct 2026
- Make Help Center: Incomplete executions Accessed 13 Oct 2026
- Make Help Center: Retry error handler Accessed 13 Oct 2026
- Make Help Center: Resume error handler Accessed 13 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.