See Coda doc:
This is a difficult one to address. This isn’t one action taking place, but each action happening individually, one after the other, while a certain criteria is met. After these actions have run, the values that the affected rows were changed to might be lumped in with other rows that were already of that particular value before the actions started. So reverting can’t happen based on a filter to reverse it. Depending on the action, it could be a fair amount of cache required to hold all changes.
Not saying this can’t be looked at, more just explaining for any who read why it happens this way right now. This is mostly seen when using a column button that is clicked by a canvas button set to push it.
1 Like
Thanks for the reply. I would think what is needed is some sort of atomic transaction approach such that the actions of a button are all one operation. I’m not sure how collaboration/automation would play into this if other things could be adding additional changes on top afterwards which would also need to be cleared or accounted for, but if it’s currently separate operations in RunActions then I see how it could take a considerable effort to address.
1 Like
This is where some of the complexity of creating a product like this comes into play. There are a lot of times where one row value might depend on another rows value and can possibly trigger recalculations based on those changing values. It gets pretty difficult to roll these up into single action items without those growing far out of proportion and without limiting what everyone can do with formulas.
It’s great feedback and something we look to measure against use-cases and how often this pops up.