The trigger is always executed regardless of the trigger filter. In this example I wanted the trigger to execute only when the entity field ‘LockStatus’ is ‘Locked’. But that has no effect.
What I understood from the Description field trigger is that it could trigger after a few seconds or even longer, when Fibery considers the field to be edited.
Maybe it generates a list of events that indicates editing only after x seconds, and then performs the filter check. But such behavior does not take into account the trigger filter. I’m just guessing here.
I tested the following way:
I wanted to mimick the ‘locking’ of a Description field to automatically revert it to a a value that is stored elsewhere when the field is locked:
When:
page updated Description,
– Where: LockStatus is Locked
Then:
change LockStatus to ‘Reverting’
Revert the Description text.
change Lockstatus to ‘Locked’.
This should result in only one time reversion of the Description field. However, it results in a continuous cycle of reverting. I tried it by using two separate automations, with the same result.
As a general rule, it is not a good idea to have an action in an automation rule that can be the cause of the rule being triggered.
In your case
will naturally lead to
And so based on the summary you gave, then yes, automation repeating is likely to occur.
On first execution, the reverting of the text action will take place, causing the automation to be retriggered, but this second run will not begin executing until the first run has completed, by which time, the lock status has been set to ‘Locked’.
When the 2nd run starts executing, the filter gets checked and is found to be true, so the automation actions will take place again.
Regardless of the workflow of this example, the bug here is the misleading presence of the When condition. If a Description trigger When condition is set, the Action should not happen at all. Or the feature needs to be updated to only execute on historic edit events when the correponding historic condition status is met.
The trigger and the filter are two separate things. For technical reasons, it is not possible to evaluate the filter at exactly the same time as the trigger event occurs.
Perhaps the UI could be improved so that it was clear that these two things are not simultaneous, e.g.
