How to Use the Break Directive in Make.com

The Break directive in make.com gives you precise control over how your scenario continues or stops after errors are handled. By learning how to configure Break correctly, you can build more predictable, robust, and maintainable automations that behave exactly as you expect when something goes wrong.

What the Break Directive Does in Make.com

In make.com, the Break directive is an option inside an error handler that lets you decide what should happen to the current data bundle after the error handling flow has finished.

Instead of sending the bundle back into the main scenario flow, you can explicitly stop it. This helps you prevent invalid or partially processed data from moving forward in your automation.

The Break directive works at the level of:

• A single bundle caught by an error handler
• What happens immediately after that handler is done processing

Core Options of Break in Make.com Error Handlers

When you configure an error handler in make.com and select the Break directive, you will see three key options. Each one controls what happens at the end of the error handling branch.

Break Only

Break tells make.com to stop processing the current bundle entirely after the error handler finishes. The bundle will not return to the main route of the scenario.

Use this when:

• You know the bundle is invalid and should not continue.
• You have already logged or processed the error inside the handler.
• You want to prevent any additional modules from acting on faulty data.

Effectively, “Break” isolates the error and safely ends processing for that one bundle.

Break & Commit

Break & Commit is used when a transaction has been started in the scenario and you want to:

• Stop processing the current bundle, and
• Commit the work that has already been successfully done inside the transaction.

In make.com, this is particularly useful if your modules are grouped in a transaction that should keep valid changes even if a later module fails. With Break & Commit, you essentially say “end the bundle here, but keep everything that succeeded before the error.”

Choose this option when:

• Partial results are acceptable and should be saved.
• Rolling back all changes is not necessary or desired.
• You want to guarantee that successful operations are preserved even after an error.

Break & Rollback

Break & Rollback is the strict option. It:

• Stops the current bundle from continuing, and
• Rolls back the entire transaction so that no partial changes are left behind.

In make.com, this is essential when your process must be all-or-nothing. If any module in the transaction fails, everything done in that transaction is undone.

Use Break & Rollback when:

• Your data must stay fully consistent.
• Any partial update would cause incorrect or confusing records.
• You prefer to repeat the whole process later rather than save partial results.

When to Use Break in Make.com Scenarios

Deciding when to use Break depends on how your business logic treats failed bundles. In make.com, you typically use a Break directive in three categories of scenarios.

Stopping Invalid or Corrupted Data

Sometimes a bundle reaches your error handler because of bad input or a missing required field. After logging the issue or notifying a team member, the safest option is often to break and prevent that bundle from affecting downstream modules.

Typical use cases:

• Incoming webhook data fails validation.
• An API module returns a permanent client error (like a 4xx status).
• A transformation step reveals inconsistent or incomplete data.

Controlling Transactions in Make.com

With transactions, make.com can treat a set of operations as a single unit. If you are using transactions around database writes or critical API calls, choosing between Break & Commit and Break & Rollback becomes important.

Examples:

• Break & Commit when some database rows were created successfully and you want to keep them, even if a later, non-critical step fails.
• Break & Rollback when creating related records must always succeed together, such as an order plus its line items.

Keeping the Main Route Clean

Error handlers in make.com are separate branches that capture failures from specific modules. Using Break ensures that a bundle that already failed in one branch does not re-enter the main route and trigger additional logic unexpectedly.

This is especially helpful when:

• Your main route has side effects (emails, notifications, payments).
• Duplicate runs would cause confusion or extra costs.
• You want a clear separation between normal flow and error recovery flow.

Step-by-Step: Configure Break in a Make.com Error Handler

Follow these steps to set up a Break directive inside an error handler in make.com.

1. Open your scenario.
   Go to your dashboard and open the scenario that contains the module you want to protect with an error handler.
2. Add an error handler to a module.
   Click the wrench or error icon of the target module and choose the option to add an error handler. This creates a new route branching from that module.
3. Design the error handling flow.
   Inside the handler, add modules to log the error, send alerts, store details, or perform any cleanup you need.
4. Select the Break directive.
   In the error handler settings, find the directive options and choose one of the following:
   • Break – stop the bundle entirely.
   • Break & Commit – stop processing but commit the current transaction.
   • Break & Rollback – stop processing and roll back the transaction.
5. Save and run a test.
   Run the scenario with a test bundle that triggers the error. Confirm that after the handler finishes, the bundle behaves according to the Break option you selected.

Best Practices for Using Break in Make.com

To get the most from the Break directive in make.com, follow these recommendations.

• Always log errors before breaking. Use a data store, spreadsheet, or external logging service so you can review failures later.
• Send notifications only when necessary. Avoid spamming your team; group or rate-limit alerts when many bundles can fail in a short time.
• Document your intent. Add notes in your scenario explaining why a particular error handler uses Break, Break & Commit, or Break & Rollback.
• Test both success and failure paths. Make sure that:
  • Successful bundles follow the main route as expected.
  • Failed bundles are fully contained inside error handlers and never reach modules that should only see valid data.

Learn More About Break in Make.com

For the full technical reference on the Break directive and error handlers in make.com, see the official documentation on the source page: Break directive in error handlers.

If you need help designing complex automations, scenario architecture, or advanced error handling patterns, you can also consult automation specialists at Consultevo for strategy and implementation support.

By understanding and correctly configuring the Break directive in make.com, you gain full control over how your automations react to failures, ensuring cleaner data, fewer surprises, and more reliable workflows.

Need Help With Make.com?

If you want expert help building, automating, or scaling your Make scenarios, work with ConsultEvo — certified workflow and automation specialists.

Get Help