Effect settings

This page contains information about effect settings, which can be accessed through the individual effect pages when configuring an automation.

Concurrency

Automations run independently, and if multiple automations trigger at the same time, they will execute in parallel in a nondeterministic ordering. However, effects for a given automation can be configured to execute in parallel or sequentially.

In the example above, since the effects are set to execute sequentially, Action 1 will be executed before Action 2. This statement holds regardless of what partitioning settings are configured. For example, if the partition size is 20, and 40 objects trigger the automation, the automation would execute as follows:

• The first set of 20 objects will trigger Action 1, then...
• The second set of 20 objects will trigger Action 1, then...
• The first set of 20 objects will trigger Action 2, then...
• The second set of 20 objects will trigger Action 2.

The example above will result in 4 total sequential executions.

However, if parallel execution was configured, the automation would execute as follows:

• The first set of 20 objects will trigger Action 1 + Action 2 in parallel, then...
• The second set of 20 objects will trigger Action 1 + Action 2 in parallel.

This example results in 4 executions, with 2 sets of 2 in parallel.

Object edits

When an automation is triggered by object edits, rather than datasource updates, you can configure how the automation handles multiple edits to the same object within a short time period.

If multiple edits are made to an object in quick succession, each edit will either trigger the automation independently, or all at once, depending on the evaluation latency.

For example, if a user makes several quick edits to a document object:

• With live monitoring enabled: Each batch of concurrent edits triggers the automation separately. The automation's concurrency settings are respected within each batch.
• With scheduled monitoring enabled: All edits since the last time the automation evaluated are combined into a single trigger.

Execution guarantees

Effects follow at-least-once execution semantics rather than exactly-once guarantees. This means that in rare cases, the same effect may be executed multiple times for the same trigger event. When designing Actions and functions that will be used with Automate, ensure that your Actions and functions can handle potential reruns gracefully.

To account for possible duplicate executions:

• Implement idempotent operations, meaning operations that produce the same result regardless of how many times they execute. For example, creating a resource with a consistent ID will only create the resource once, even if the creation code runs multiple times.
• Use conditional checks to verify if an operation has already been performed before proceeding.
• Design your data models to handle duplicate submissions appropriately.

While Automate attempts to minimize duplicate executions, they cannot be completely eliminated due to the distributed nature of the system and retry mechanisms for handling transient failures. It is important to consider this execution behavior when designing automation workflows, particularly for critical operations.