Scenario settings
You can access the settings panel by clicking the gear icon in the editor. Here you can set various advanced settings.
You can allow to store information about incomplete executions.
The sequential processing setting determines how processes recurring incomplete executions. The incomplete executions folder must contain data.
- If enabled, stops executing the until you resolve all incomplete executions. This option guarantees that will always solve incomplete executions in sequential order.
Sequential processing also applies to webhooks. By default, processes webhooks in parallel. When you enable sequential processing, waits until the previous execution is complete before starting the next one.
After a executes, you can display information about data processed by the modules. This happens by default.
If you do not want to store this information, enable this setting.
If enabled, there are very limited options to solve errors that occur in a execution.
This setting determines what happens if a run encounters an error. You can choose how will process the data.
- If enabled, the is paused and moved to the incomplete executions folder. This gives you the possibility to fix the issue and continue from where the stopped.
You can resolve each incomplete execution either manually or automatically.
The data in this folder counts towards the storage limits of your subscription plan.
may fail to save a data bundle to the queue of incomplete executions (e.g. due to a lack of free space). With this setting enabled, does not save the lost data. This is to prevent interruptions in the Make execution.
This option is well-suited for where continuous execution is the highest priority. The incoming data is less important.
Modules can encounter files larger than the maximum allowed size. In this case, proceeds according to the enable data loss setting and displays a warning message.
The maximum file size depends on your subscription plan.
This setting applies to transactions and defines the way to process a . This setting is enabled by default.
- If enabled, the commit phase on each module starts immediately after the operation phase. Data is committed right away and cannot be restored in the case of an error.
- If disabled, no commit occurs until operations are executed for all modules.
Not every module supports transactionality. Only modules marked with the tag 'ACID' support transactions.
This setting defines the module commit order after a successful operation phase. This setting is enabled by default.
- If enabled, the commit phase skips the trigger and processes that module last.
- If disabled, the commit phase occurs in the default order.
This setting defines the maximum number of cycles allowed during a execution.
Setting more cycles can be useful when you want to prevent connection interruption to third-party services. This can also ensure all records are processed within the run.
If you execute the manually by clicking the Run once button, the setting is ignored and only one cycle will be performed.
This setting defines the maximum number of consecutive execution attempts before the deactivates (though there are exceptions listed in the error handling overview.
If a starts with an instant trigger, the setting is ignored and the is deactivated immediately once the first error has occurred.