I almost wanted to applaud when it worked once today. But the next time it missed the calculation field change again and didn’t trigger the automation.
We already started looking into this and will keep you updated as soon as we have a first insight, or even better, a fix. Since the issue seems to happen only occasionally, we’ll first set up a test scenario to reproduce it reliably.
Once we can reproduce it, we’ll make sure to close the gap so that automations always trigger correctly when calculation fields change!
Thanks again for pointing this out, and have a great weekend!
We checked on our end via a reproduction scenario, and indeed found a timing bug that could lead to calculation field updates not triggering workflows in some cases. That fix was deployed over the weekend and is now live.
An additional important note: In order for this to work, the origin update (that triggers the calculation update) needs to have the “Trigger automations” switcher on, which propagates transitively through an update → caluclation cascade.
In your case, is the origin update performed manually, via the API or also via automations?
Looking forward to your feedback so we can resolve this together.
an automation starts a regular poll of a number of issues,
in order not to work with delays, the calculation field compares the expected number of issues with the number of linked records - I will make sure, that the automation that links the record will have the control switched on for triggering automations
once the number of linked records matches the number of expected issues, the calculation field switches to done and should trigger the next automation