I recently started using automations and I really like them. Super user-friendly and powerful. Congrats!
However, the way Tulip currently detects potential loops in automations seems too simplistic to me. When using a loop, the warning about potential infinite loop appears in many cases, even when it is obvious that it is impossible. I think that in some cases, this can frustrate the user or make them worry needlessly.
I think it would be nice to take into account simple things that don’t look too expensive to execute. E.g.:
take into account the Create record if it doesn’t exist checkbox of create/update actions
take into account which table is selected
This would allow to avoid displaying a warning in cases that I think will probably often arise.
I’m gonna focus on tables here and consider that connectors, tables and machines don’t interact in a way that they influence each other. I think that’s perfectly reasonable to assume since it is impossible to detect 100% of looping cases anyway.
Detection algorithm conditions could look something like this (not that they are sufficient, not necessary and sufficient):
For on table record deleted kick-off event: risk of looping only if automation contains an action that deletes a record AND does it on the same table as the kick-off event.
For on table record added kick-off event: risk of looping only if automation contains a create/update record action that has the Create record if it doesn’t exist checkbox checked AND acts on the same table as the kick-off event.
For on table record updated kick-off event: risk of looping only if automation contains a create/update record action that acts on the same table as the kick-off event.
In terms of complexity, we’re probably on something like O( m * n ) with m = number of distinct tables used in the automation and n = number of table record actions used in the automation.
Thank you for reaching out with this detailed message and thinking through the options here!
Could I ask a bit more about your user experience and the friction you might be experiencing -
Is it that you’re seeing the warning frequently, and would just want to dismiss it since you’re familiar with the risk? Or would accurately detect infinite loops very valuable to your process?
We’re prioritizing some more foundational aspects of Automations in the next few months, such as listening to table column updates (instead of full row updates).
Hoping to understand whether a lighter lift improvement could be valuable in the short term.
I’d love to schedule a :20-30 minute listening session if that’s easier!
Yes, the warning is too frequent to me and being able to dismiss it persistently would be very welcome (EDIT: persistently until the automation changes! see below). I don’t remember the exact UX of automation (I haven’t used them lately) but the following would be simple to implement and improve UX:
(keep detection algorithm as-is).
Add a Dismiss button / link on the warning.
If the user clicked the Dismiss button, do not show the warning anymore as long as the automation was not modified at all.
If the automation is modified in any way, show the warning again.
In my humble opinion, accurately detecting infinite loops without having any “false positive” is almost impossible to do since there will probably always be a way to bypass detection rules. I think your current approach (with true and false positives) is good and reasonable. It’s just that there are too many false positive cases in my taste! And I think this makes the user think and worry needlessly.
Thanks - I’m adding it to our list of “quick wins” to triage.
We’ve been able to fit in a few quick wins recently for Triggers and Automations, including getting Trigger Descriptions in, and increasing the block count for Automations from 50 to 100.
For this one -
Would you mind sharing an example of an Automation where you run into this, either here or in a Direct Message to my inbox?
Could I ask the Community to vote on this thread, if it feels like this is something worth tackling in the near term? I’m trying to understand how frequently customers run into this issue - I’ve only heard about this once in the last 6 months.
I’ve added this to our list of quick wins, and we’ll follow up here when we’re able to get it prioritized. There are a few other items on the list we’d like to get to first across Automations and Triggers that have been requested by several teams like improving Automations Import/Export and productionalizing a new visual Debugger for Triggers.
Request to the Community to upvote this Product Suggestion (especially the dismissibility part) this if it’s a major pain point for other teams. We take votes into consideration when we sequence “quick wins”!