Make automation: scenarios, webhooks and recovery

Make suits flows with more shape than a straight line:

• Data arrives as lists that need splitting and regrouping. An iterator turns an array into bundles, and an aggregator merges bundles back into one.
• One input goes different ways. A router splits a scenario into routes with filters, and a fallback route takes what matches none.
• You need to keep data between runs. Data stores hold data across scenarios and scenario runs.
• Failed runs should be kept and retried, not lost. Incomplete executions store them for automatic or manual resolution.

Plan around these before you commit:

• Your volume grows with every record. Each bundle a module processes is an operation, so a loop over many items uses many operations. Plan what happens when credits run out: on one of our projects, bookings were missed when a webhook did not fire.
• You assume every failure is kept. Incomplete executions are off by default, and some errors never create one, such as an error on the first module or a run longer than the duration limit.
• You expect a scenario to keep running after an error. Scenarios with an instant trigger are deactivated after the first error, whatever the error setting says.
• The logic needs automated tests and code review. Then the core belongs in your own code, with Make kept for the app connections.

A scenario starts with a trigger. Polling triggers, usually named "Watch", check a service on the scenario's schedule. Instant triggers receive data by webhook and start the scenario at once. Search modules fetch records, action modules get, create, update or delete them, and universal modules make a custom API call when no ready-made module exists. Data moves as bundles, and each module processes each bundle separately. An iterator turns an array into bundles, an array aggregator merges bundles into one, and a router sends bundles down routes that run one after another, with a fallback route last. Data stores keep data between scenarios and runs, shaped by a data structure. A scenario can run at intervals, daily, weekly, monthly, on specified dates or on demand. Each bundle a module processes is one operation, while a trigger counts once per run however many bundles it returns. For modules without AI, one operation uses one credit.

Not sure which tool fits? See how we choose between Zapier, Make, n8n and custom code.

• Webhooks: instant webhook runs happen in parallel unless "Process data in order" is on. Scheduled webhooks queue requests until the next run. When the queue is full, Make rejects the extra data, and a webhook not connected to any scenario for more than five days is deactivated.
• Error handlers: Skip moves on, Retry stores the run for another attempt, Resume supplies a substitute value, Commit stops but keeps what was done, and Rollback stops and undoes it. We choose one per module by what a failure there means.
• Incomplete executions: with the setting on, a failed run is kept. Rate limit, connection and module timeout errors are retried automatically with growing gaps. For other errors you fix the module and run it again from the failing step with its original input. Deleting one is permanent.
• Storage and gaps: incomplete executions share a storage limit, and if the folder is full Make can discard the failed data. Errors on the first module, runs over the duration limit and errors in rollback leave nothing to recover.
• Success that is not: a run can finish without errors and still miss its output, such as a report with no attachment. We check outputs, not just run status.
• A safety net for webhooks: a scheduled scenario that compares the source with the database catches what a missed webhook left behind.

1. Count the operations first: bundles per run times the modules they pass through, so the design fits the credits
2. Choose instant or scheduled per flow: webhooks for speed, schedules for batches and for recovery
3. Turn on recovery before go-live: incomplete executions, error handlers on modules that call other systems, and an alert for runs that succeed without their output
4. Hand over properly: each scenario named and documented, with notes on reading the history and resolving an incomplete execution