Guide
With automations, it can sometimes be difficult to know why something happened (or didn't happen) and looking at the activity log of a single automation may not provide enough information to figure everything out.
Also, as the number of automations in a workspace grows, it becomes more likely that automations start triggering each other, and/or at the same time as each other.
The behaviour of automation rules can get quite complicated, but the underlying logic for how they work is relatively simple.
Basic logic rules for automations
A workspace has a single 'automation engine' which is responsible for handling all automation activity.
This means that only one automation can be executing at any one time.
An automation's actions occur in sequence, and all actions in one automation will be completed before any other automation rule execution is started.
Formulas used in automation actions are evaluated at the time the automation action executes.
When an automation triggering event occurs, an 'event notification' is sent to the automation engine, letting it know that the automation needs to happen.
If an automation has a trigger filter set, when the automation engine receives the notification, it will evaluate the filter criteria to determine whether or not the automation actions should be executed.
The filter evaluation is done based on the entity field values at the time when the event notification is received by the automation engine, which will be slightly delayed from when the triggering event actually occurred.
If the filter criteria are met, the actions for the automation rule will be queued up, to be executed when the automation engine becomes available.
If more than one automation has the same trigger, the order in which they are evaluated/execute will be the order of the rules on the automation editor page.
Automation activity is asynchronous to other activity in the workspace.
What does this mean in practice?
The above rules can result in the following behaviour:
The values of an entity's fields may get changed between the time of the triggering event and the time the automation engine evaluates/executes the automation.
Example #1
An automation is configured to trigger when an entity checkbox field is updated. The automation includes a filter to only execute actions if the checkbox is true.
A user rapidly clicks the checkbox field from false to true and back again, several times.
Each change of the checkbox field results in an 'event notification' being sent to the automation engine. The automation engine examines the state of the checkbox field for each event notification that is received, in order to determine whether to execute the actions.
There is no guarantee what the state of the checkbox might be for each of the event notifications received, so there is no way to determine how many times the automation will execute.
Example #2
An automation is configured to trigger when a project's due date field is updated. The project has a formula field to determine if the due date is today, and the automation rule includes a filter to only execute actions if the formula field is true.
Any change of the due date field results in an 'event notification' being sent to the automation engine. The automation engine examines the state of the formula field each time an event notification is received, in order to determine whether to execute.
There is no guarantee that the formula calculation will have updated to the correct value by the time the automation engine checks it.
🧠In this case, it might be better to change the automation to trigger on an update to the formula field instead of the date field.
Example #3
An automation rule is configured to run when a task's state is updated, from In Progress to Done, and it has two actions: 1) create a linked report entity, and 2) remove all assignees.
Another automation rule is configured to run any time a report entity is created, and has a single action: to overwrite the report's summary rich text field with information from the linked task, making use of Markdown Templates. The markdown template includes the name of the linked task and its assignees.
Although a report entity will be created before assignees are removed from the task, the report summary will show no assignees, since the second rule will not execute until the first has fully completed (by which time, the assignees will have been removed).
🧠In this example, it might be better to only have the 'create report' action in the first automation, and then clear the task assignees as a second action in the report automation. Remember: actions can be used to update the fields of the entity that triggered the automation, but can also be used update the values of fields in related entities.
Rich text as a trigger
It is possible to define automations that trigger on changes to a rich text field. However, it's worth bearing in mind that an event notification will not be generated for every character being added/deleted (otherwise the automation engine would quickly get overloaded).
Instead, rich text changes are considered to have occurred in batches, corresponding to version updates (see Text history).
This means that there will be latency before an automation gets triggered following rich text changes.
Loop prevention
Loops in automations/formulas can cause problems, and when they are detected, the automation/formula will be disabled. See Loop Prevention in Fibery.
Generally, an automation that directly (or indirectly via a formula field) causes itself to be retriggered, will be detected as a loop, and stopped/disabled.
However, if an automation is re-triggered but its actions are not executed (because filter criteria are not met) it will not be considered that a loop has occurred.
Example
An automation is configured to trigger on a checkbox field change, with a filter to only execute if the checkbox is true.
The automation includes an action is to clear the checkbox.
This action will re-trigger the automation, but because the automation filter means that no actions are executed when re-triggering occurs, no loop is detected.
An alternative (visual) explanation
If you find the above rather wordy, perhaps a more visual explanation might help:
Imagine a database with a number of fields, and two automations: rule A and rule B.
In the visualisations below, the fields are shown as colours.
Automation rule A
Trigger | 🔴 |
Filter | 🔷 |
Action 1 | 🟪 |
Action 2 | 🟨 |
Action 3 | 🟩 |
Action 4 | 🟧 |
Rule A triggers on an update of the 'red' field, checks the state of the 'blue' field, and then updates the 'purple', 'yellow', 'green' and 'orange' fields
Automation rule B
Trigger | 🟢 |
Filter | 🔶 |
Action 1 | ⬛ |
Rule B triggers on an update of the 'green' field, checks the state of the 'orange' field and then updates the 'black' field.
Now, the user makes some updates to the various fields, while the automation rules are enabled.
The visualisation below shows the interplay between the user's activity and the automation engine:
Workspace events | | Automation engine |
Rule A | Rule B |
1 | User updates field | 🟦 | | | |
2 | User updates field | 🟥 |
3 | User updates field | 🟦 | Event #2 received 🔴 |
4 | User updates field | 🟩 | Check filter 🔷 |
5 | User updates field | ⬛ | start execution … | Event #4 received 🟢 |
6 | Rule A updates field | 🟪 | Action 1 🟪 | Check filter 🔶 |
7 | Rule A updates field | 🟨 | Action 2 🟨 | wait … |
8 | Rule A updates field | 🟩 | Action 3 🟩 |
9 | Rule A updates field | 🟧 | Action 4 🟧 | Event #8 received 🟢 |
10 | User updates field | 🟦 | | start execution … | Check filter 🔶 |
11 | Rule B updates field | ⬛ | Action 1 ⬛ | wait … |
12 | User updates field | 🟨 | | start execution … |
13 | Rule B updates field | ⬛ | Action 1 ⬛ |
Things to note:
The user updates the blue field (#1) and then triggers Rule A by updating the red field (#2).
The user updates the green field (#4) and this gets received by the automation engine, but the engine is busy executing Rule A.
Rule A actions include an update to the green field (#8) and so Rule B is triggered a second time (but still needs to wait its turn).
After Rule A has executed all actions (#6 - #9) the automation engine starts executing the action of Rule B for the first time (#11) and when this is done, it executes the action again (#13) for the second triggering of Rule B.
It's easy to see why a user might be confused by some of the behaviours of the workspace:
Rule A was executed when it was expected that the filter setting would prevent this
the user only set the green field once, but Rule B got executed twice
Rule B automation actions happened much later than the triggering event(s)