How Make.com Scenario Execution Cycles Work

The difference between an execution, a cycle and a bundle

These three terms describe different levels of the same runtime process:

• Execution: the complete attempt to run a scenario, from start to finish.
• Cycle: one pass in which the trigger retrieves or receives data and the scenario processes that data through its configured route.
• Bundle: a unit of data emitted by a module and passed to the next applicable module.

A single execution may contain one cycle or several. A cycle may contain one bundle or many. Each bundle can then produce work in downstream modules, through filters, routers, searches, creates, updates or other operations.

This distinction is more useful than treating a scenario run as one indivisible event. For example, a scheduled scenario might start once, retrieve a limited set of records in its first cycle, and continue with another cycle if more eligible records remain. The execution is still one overall run, even though the trigger has performed multiple passes.

What happens during a Make.com scenario execution

Although scenarios can contain different modules and routes, most executions can be understood as a sequence of operational decisions.

1. Start and initialize: the scenario starts from a schedule, webhook, event, manual run or another configured trigger. Make.com loads the scenario and its connections.
2. Retrieve or receive input: the trigger looks for eligible data or accepts an incoming request. This is where source-side filters, date windows and retrieval limits begin to shape the workload.
3. Emit bundles: the trigger passes one or more bundles into the scenario. A bundle may represent a record, event, line item, webhook payload or another data structure.
4. Process each route: downstream modules act on the bundle. Filters decide whether it continues, while routers can send it down different branches.
5. Record outcomes: the execution history shows which modules ran, what data they received and where errors or interruptions occurred.
6. Determine whether more input is available: depending on the trigger and scenario configuration, Make.com may continue with another cycle or finish the execution.

This is not the same as a database transaction. A scenario can successfully write to one system and then fail before writing to another. If the workflow has several side effects, its design needs a clear response to partial completion, such as retry handling, status tracking or an exception route.

How cycles affect workload and operation counts

Cycles are important because they control how a trigger works through available input. A trigger may return a limited number of bundles at a time, or a scenario may use a setting that limits how much data is processed in one pass. When qualifying data remains, another cycle may be needed.

The number of cycles is only one part of capacity planning. Suppose a cycle receives 20 bundles. If every bundle passes through five downstream modules, the scenario may perform substantially more module operations than the bundle count suggests. A router can increase the work for some bundles, while a filter can reduce it. A search module may also generate additional bundles that continue through later steps.

Use this simple sequence when estimating a scenario:

The right batch size is therefore an operating decision, not simply a performance setting. Smaller batches can reduce the size of a failed retry and make execution history easier to inspect. Larger batches may be efficient when the source and destination systems can handle them reliably.

How to read cycles in execution history

When diagnosing a scenario, start with the execution history rather than changing modules immediately. Select a run that represents the problem and inspect it in this order:

1. Confirm how the scenario started

Check whether the run came from a schedule, webhook, manual test or another event. A manual run may not reproduce the same input conditions as a production trigger. A webhook may also contain one payload while a polling trigger may retrieve multiple records.

2. Check the trigger output

Look at how many bundles the trigger emitted and what their identifiers or timestamps are. If no bundles were produced, downstream modules did not have an opportunity to run. The issue may be the source query, date window, polling state or trigger filter rather than a later module.

3. Follow the bundle paths

Inspect filters and routers to see where bundles stopped or branched. A filter that appears logically correct can still exclude data because of an empty value, a different data type or an unexpected status. Follow representative bundles instead of assuming every bundle took the same route.

4. Separate errors from expected exclusions

A filtered bundle is not necessarily a failed bundle. Document the difference between an item intentionally excluded by business logic, an item that needs review and an item that failed because a system returned an error.

5. Compare the observed run with the intended business state

Ask whether the scenario merely performed operations or moved the record to the correct state. For example, sending a notification may be an activity, while updating the record to “customer notified” may be the state needed for reporting and follow-up ownership.

Design rules for more predictable scenario cycles

Make the trigger’s input boundary explicit

Define the field, event or timestamp that makes an item eligible. Avoid relying on an informal assumption such as “new records” when the source system can change records after creation. A clear input boundary reduces duplicates and makes reprocessing safer.

Filter before expensive work

Apply conditions as close to the source as practical. Early filtering reduces unnecessary searches, updates and notifications. It also makes the execution easier to reason about because fewer bundles reach complex branches.

Use idempotent actions where possible

An idempotent action can be repeated without creating an unintended duplicate result. For example, updating a known record by a stable identifier is generally easier to retry safely than blindly creating a new record. Where an action cannot be repeated safely, store a processing marker or define an exception path.

Keep ownership visible

Every failure that can interrupt a business process should have an owner and a next action. Technical error handling is not enough if nobody knows whether to correct the source record, rerun the scenario or contact the customer.

Design reporting around decisions

Track measures that lead to action, such as items waiting for review, failed writes, records processed more than once or cycles that regularly reach a configured limit. A dashboard that only shows total executions may hide the operational problem.

A practical example of cycle behavior

Consider a hypothetical operations team with a scheduled scenario that looks for orders requiring fulfillment review. The trigger retrieves eligible orders in manageable groups. Each bundle is checked for required address data, then routed either to a fulfillment queue or to an exception list.

If 40 orders are eligible and the trigger processes 10 at a time, the execution may require several cycles. Some orders may take the normal route, while others stop at the validation filter. The team should not define success as “the scenario ran four times.” A better definition is that every eligible order ended in a known state: queued, excluded with a reason or assigned for correction.

If the scenario fails after some orders have been queued, the next design question is whether a retry would duplicate those orders. A stable order identifier, a recorded processing status and a safe update rule can make recovery controlled instead of manual guesswork.

When to redesign a scenario

Repeated cycle problems often indicate a process or data design issue rather than a need for more modules. Investigate when:

• the same records appear in multiple executions without a clear reprocessing rule;
• cycles regularly approach execution, time or API limits;
• filters are difficult to explain to the people who own the process;
• errors are visible in logs but not assigned to an operational owner;
• reports show activity but cannot answer what work is complete;
• one scenario contains several unrelated responsibilities and recovery is difficult.

At that point, document the business states first. Then decide whether the scenario should be split, whether the source data needs a clearer status field, or whether a separate exception workflow is required. More automation is not automatically better if it obscures ownership and makes partial completion harder to recover.

For broader workflow architecture, automation design and connected business systems, see ConsultEvo’s systems and automation services. You can also review examples of connected operational systems in the ConsultEvo client work portfolio.