Great to see this could be implemented so quickly!
I finally got a chance to try it today, but unfortunately it seems like the current implementation suffers from similar usability and fragility concerns as the “New Row” trigger.
-
As @S_M said, we need the ability to limit the trigger to a subset of columns. Changing a “Notes” column after “Approved” has already been checked will re-fire the flow.
-
Sometimes I get spreadsheets with multiple tables/lists on a single sheet, so I’d love to be able to scope the trigger to a (named) range instead of a whole sheet. This applies to the “New Row” trigger and some of the actions too.
-
There’s no way to get the “old value” of a row, so it’s not clear what has actually changed. This is probably a little tricky to implement, but it’s essential for a lot of workflows.
For example, one of my sheets has multiple checkbox columns. The actions to run depend on which one was (newly) ticked. In particular, if the flow is triggered by an update to column D, I need to know if checkbox B was already ticked before, to avoid re-running actions. -
I’ve noticed some flakiness around duplicate rows, but I can’t seem to reproduce it reliably… Usually the flow runs for every new/updated row, but sometimes it seems to miss a couple.
-
Reordering rows re-triggers the flow for those rows. From a programmer’s perspective I understand that swapping two rows means both of them were updated, but for a (non-technical) user this is fragile.
-
In line with #5, inserting a row anywhere but the end will re-trigger the flow for all rows below it. Again, I understand how this happens, but it’s fragile. For example, I can’t add rows at the top for extra information and explanation for my non-technical colleagues.
-
There’s no warning about the delay from Google Drive, like for the “New Row” trigger.
The combination of these things, in particular #1, #3 and #6, unfortunately makes this trigger not yet usable for me. While I absolutely see how these bugs came about, I have to say I’m surprised they managed to slip into production. I’ve discussed possible implementations and potential issues for this trigger at length with someone from the team on Discord, but this seems to not have been taken into account.
However, given the speed at which you guys have been polishing lately I’m looking forward to the next iteration!