Who this is for
An operations or marketing manager whose Make scenario halts, or is switched off, when one record in a batch contains something unexpected.
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.
What is 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
You receive
- 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
What is 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
What we need from you first
- 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
Never send passwords, keys, customer records or confidential code in the first enquiry. Secure handover is agreed after scoping.
How we check it is done
- 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.
- 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.
- The agreed recipient receives one alert naming the scenario and the failing module for that record.
- 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.
- After the bad record is corrected and resolved once, it is written once and does not duplicate an already processed record.
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.
When we would stop or decline
- 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
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.
Price and terms
£175 · untested offer price. £175 after the agreed checks pass and you sign off. No payment before sign-off.
This is a new service with no published client results. The price is a starting point we have not yet tested with buyers. Nothing is ordered or charged by the enquiry. The full specification is on the Synthetic Industry catalogue.