Directives for error handling
The Directives are explained in detail below:
Rollback |  | Scenario execution is stopped immediately and a rollback phase is started on all the modules in an attempt to revert them all to their initial state. The subsequent modules are not processed. Barring a few error types, the scenario is deactivated after the "number of consecutive errors" specified under Scenario settings. The scenario execution status is marked as "error". Note: This is the default behavior if no error handler route is attached to the module and the "Allow Storing Incomplete Executions" setting under Scenario settings is not checked. |
| Commit |  | Scenario execution is stopped immediately and a commit phase is started on all modules. The subsequent modules are not processed. All unprocessed bundles are ignored. The scenario execution status is marked as "success". |
| Resume |  | A substitute output is specified and supplied to the module that encounters an error. The subsequent modules are processed. The scenario execution status is marked as "success". |
| Ignore |  | The error is ignored and the subsequent modules are not processed. If there are unprocessed bundles, the scenario execution continues normally. The scenario execution status is marked as "success". |
| Break |  | The state of the scenario execution is stored in the queue of incomplete executions where the error can be resolved manually. There are, however, some exceptions that are mentioned here. The subsequent modules are not processed. If there are unprocessed bundles, the scenario execution continues normally. The scenario execution status is marked as "warning" when the Automatically complete execution option is disabled. See the Break section below for further information. |
| Retry |  | In some cases, it could be useful to re-execute a failing module for a couple of times when there is a chance that the reason for the failure might pass over time. Integromat currently does not offer the Retry directive, though several workarounds can be employed to mimic its functionality. |
Break
When an error is handled by the Break directive, a record is created in the Incomplete Executions folder which stores the state of the scenario execution along with data from the prior modules. For each bundle of data that causes the error, a separate record is created.
The record references the module where the error originated and contains information regarding what data was received by the module as input. Read on about Incomplete Executions here.
Here, you may resolve the error manually by updating the scenario (if needed) and running it once.
On the other hand, by enabling the Automatically complete execution option under the Break directive settings, it can be configured to automatically process an incomplete execution by re-executing the scenario after the specified number of minutes.
With this option enabled, when an error takes place, the incomplete execution is retrieved (after the time specified in the Interval between attempts field) and executed with the original input data. This will repeat until the execution of the module completes without an error or until the Number of attempts specified is reached.
However, there are some exceptions to executions being stored under Incomplete Executions and with some error types, the auto-retry of a scenario execution is not possible. They are mentioned here, under Allow Storing Incomplete Executions.
Additional Resources
- Watch this 4-part video course to learn all about error handling in less than 22 minutes
- Check out this article to learn about advanced error handling.
