Job make-scenario-stops-on-one-bad-record · revised 11 October 2026
Set one bad record aside in a Make scenario and tell a named person
On a copy fed by a disposable source, one bad record in a synthetic batch is held or skipped as you agree and a named person is alerted. The good records are processed once and the next run is tested.
You might be seeing
- The scenario history shows an error at one module, and later records in the same batch were not handled
- The scenario was deactivated after repeated failed runs
- Nobody was told, and the gap was found by a customer or a missing report
No passwords, keys, card details or admin invites needed to start.
What usually happened
A Make scenario with no error route follows its default behaviour. With stored incomplete executions switched off, the default is to roll back and stop, and the scenario is deactivated after repeated failing runs (three in a row unless the setting was changed). One malformed record therefore blocks every record behind it. An error route can set the bad record aside with its reason and tell a named person. What happens to later runs then depends on the directive: Skip drops the record and carries on, while holding it with Retry and a stored incomplete execution keeps it safe but, as Make documents, postpones the next scenario run until the stored record is resolved. The job adds the route with the directive you choose and tests both the batch and the next run.
Who it’s for: An operations or marketing manager whose Make scenario halts, or is switched off, when one record in a batch contains something unexpected.
Usually starts when: The scenario worked for weeks, then stopped at one record, and the records behind it were not processed until someone noticed.
The result: On a copy of the scenario reading a disposable source, a synthetic batch containing one deliberately bad record has every good record processed once. The bad record is held, or skipped if you agree in writing, with its reason visible, and a named person receives one alert. A second run with new synthetic records is then tested and its result recorded: with a held record, Make documents that the next run waits until the record is resolved, and the handover says whether that happened.
Check whether this job fits
Answer these from your scenario history without sharing logins or customer data. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
Read the failing module
Open the scenario history, select the failed execution and open the module that shows the error. Do not run the scenario again just to look.
Look for: The error text, whether it names one record's value, and whether later records in the batch appear in the history.
What you get
- A short note naming the module, the error text and why that record failed
- The corrected copy of the scenario with the error route, its directive and the alert
- Execution history for both synthetic batches and for resolving the held record
- A one-page explanation of which error types this route does and does not catch, and what the directive does to later runs
Included
- One scenario with one failing module that errors because of a data problem in a single record
- Add an error route to that module using the directive you agree after we explain the choices (retry with stored incomplete executions, skip, resume with a substitute, commit or rollback)
- Add one alert on the error route to a named mailbox or channel. The route always ends in the agreed directive, because Make documents that it skips the error when the route holds no error handler, so a route that only sends a message would silently drop the record
- Point the copy at a disposable source and a disposable destination, run a synthetic batch of five to ten records with one bad record, run a second batch of new synthetic records, and resolve the held record once to show the route works
Not included
- Repairing connection or authorisation errors, or buying more operations or storage on your plan
- Rebuilding the scenario or changing more than the one module's error route
- Clearing a backlog of old stored executions beyond the single one used in the test
- Scenarios set to keep data confidential, where Make stores no payload and the record cannot be inspected or resumed
- Real customer records or any message sent to a real contact during testing
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A synthetic batch of five to ten records containing exactly one bad record finishes on the copy with every good record written once to the disposable destination.
Evidence: Execution identifier, the batch contents and the destination record count.
The bad record is held as an incomplete execution, or skipped if so agreed, with its error visible, and the scenario remains active and scheduled afterwards.
Evidence: Scenario history showing the held or skipped record and the scenario's active status.
The agreed recipient receives one alert naming the scenario and the failing module for that record.
Evidence: The received alert, redacted.
A second run with new synthetic records after the bad record was held or skipped behaves as the handover note states: with a skip, the new records are processed; with a held record, the history shows whether the run is processed or postponed until the held record is resolved.
Evidence: The second run in the scenario history, the destination count for the new records, and the sentence in the note that matches it.
After the bad record is corrected and resolved once, it is written once and does not duplicate an already processed record.
Evidence: Resolution history and destination record count.
Sign-off. You inspect the history, the alert and the destination counts on the copy, then sign off before payment. You switch the corrected scenario on yourself and check a live run.
If it fails. If the agreed tests do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- You are an owner or admin of the Make organisation and can copy the scenario
- The failure comes from the content of one record, not from a lost connection or an exhausted plan
- The copy's trigger or source can be pointed at a disposable source (a test sheet, list, form or webhook sender). Pausing the original scenario is not an alternative, because a copy that reads your live source would still process real records
- A disposable destination or clearly marked test records exist for the modules that write data
We stop and tell you if
- The errors are authorisation, connection or plan-limit errors that only the account holder can resolve
- Modules write to apps with no transaction support, and a partial write cannot be reversed or tolerated, until you choose a different directive
- The copy can only read the live source, because no disposable source can be set up
- The scenario can only be tested with live customer data
What could go wrong
The original scenario is untouched, because all changes are made on a copy. If the copy misbehaves, switch the original back on and the copy off. Removing the error route returns the module to Make's default behaviour.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Skipping a record loses data nobody notices. Make marks a skipped run as successful, so the run history alone does not show it. | Prefer holding the record with an alert. A skip is chosen only if you agree in writing that the record may be dropped, and the alert still reports every skipped record. |
| A directive leaves a partial write in an app that cannot roll back. | Explain per module whether transactions are supported, and choose the directive with that in view. Test on a disposable destination. |
| A held record postpones later scheduled runs until someone resolves it, so new records wait behind it. | Make documents that creating an incomplete execution postpones the next scenario run until it is resolved or the Retry handler resolves it. We state this plainly in the note, test a second run, and set the alert so a held record is seen and has an owner. |
| The copy reads your live source and processes real records. | The copy is built against a disposable source and never reads the live one; the original is left running and is not paused for the test. Nothing is switched on against the live source until you do it. |
An independent reviewer checks the redacted before and after evidence, that every test used synthetic data, that nothing outside the agreed scope changed, and whether your authorised owner can safely reverse the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the scenario, the failing module, the directive to use and the alert recipient in writing
- Read the redacted execution history and reproduce the failure on a scenario copy pointed at a disposable source, with a synthetic batch that includes one bad record
- Add the error route to the failing module, with the alert and the agreed directive, and turn on stored incomplete executions if the directive needs them
- Run the batch: confirm good records are processed once, the bad record is held or skipped as agreed, and the alert is received
- Run a second batch of new synthetic records and record whether it is processed or postponed behind a held record
- Resolve the held record once, to show that a person can repair and resume it
- Independent review of what the directive does to partly written data and to later runs, then hand over the copy and notes; you switch it on
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform, hosting and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If this scenario matters daily, discuss ongoing monitoring of the named scenarios as a separate recurring service.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Read Make's overview of error handling. It explains the default rollback behaviour, incomplete executions and the consecutive-errors setting, and you may be able to apply it yourself. help.make.com
- Make's incomplete executions page explains how stored runs are inspected, fixed or deleted. help.make.com
Questions
Which error directive will you choose?
We explain the options and what each does to partly written data and to later runs, then you choose. Holding the record with an alert is the default we recommend; skipping needs your written agreement.
Will the scenario keep running after a bad record?
It depends on the directive. With skip, the record is dropped and later records are processed. With a held record, Make documents that the next scenario run waits until the held record is resolved, or until the Retry handler resolves it. We test a second run and tell you which happened.
Will this stop every kind of failure?
No. An error route handles data problems in a record. Lost connections, expired authorisation and plan limits need the account holder, and Make deactivates some kinds of scenario immediately.
Do you need my Make login?
Not for the first enquiry. After agreement we work on a copy, through a handoff agreed in advance, and you switch the result on.
Send an enquiry
Send us
- The scenario name, the module that fails and its redacted error text
- Whether the scenario is scheduled or webhook-triggered, and how often it runs
- Whether Store incomplete executions and the consecutive-errors setting were ever changed
- Do not send passwords, API keys, customer lists or an account invitation in the first enquiry
Later, once you agree
- A scenario copy, or a team-member invitation with the least access Make offers, which you create and can revoke
- A disposable source and destination and a synthetic batch, including the bad record you want handled
- A named recipient for the alert and a company-controlled secure handoff agreed before any access
You keep the live accounts, production keys and customer records. We work only on a copy or a test route with synthetic data, through a company-controlled handoff agreed before any access; a person owns Synthetic Industry and remains accountable. Your authorised account holder approves and carries out the live change.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “make-scenario-stops-on-one-bad-record” as the subject.