Changing Data of multiple Rows

Good Day everyone,

Im wondering how i would change multiple rows in my table based on an edit of a row.

lets say my Table has 5 columns.

If the user edits the 4th of 5th column in any row, I want to update all corresponding row Columns 4 & or 5 based on a conditional check on column 1, 2 & 3.

You’d want to use actions. You could attach the actions to the form to be performed when the form is saved, or you could create a workflow that triggers on the row update.

1 Like

Im getting the following errors, So i want to update the following columns of said rows as in my behaviour formula from the values of the said row that was updated.

Refer to the column you want instead. For instance, [Waffle Weight].

This is what I have and everything Is triggering but if does not seem to be working.



Screen Shot 2020-01-25 at 11.11.03 PM
!

Am I missing something?

Thanks,

I’m betting that you lost the context of which row the system was “in” to begin with, going from workflow to action. So, by setting the “Oven Temp” to [Oven Temp], you are literally assigning it to itself, and it is blank.

If I may suggest. Add a “flag” column to the table (hidden). When this whole action-set starts, set some value to that column. Then in your “Update Rows” action, you’ll assign each column with:

LOOKUP(“flag value” , “Types” , “flag” , “column to return (oven temp, line temp, etc)”)

And make sure to add another action at the end to clear away that flag value.

There may also be a better and more efficient way to do all this…

1 Like

@Jonathan_S
Firstly, in your SELECT(…) expression,provided [Id] is the key column for your Types table (which I assume it should be), there is no need to use the FALSE statement at the end because key is by-nature unique and it can’t contain recurring/duplicate key information.

Right of course, anything regarding a better way than Marc is suggesting though??

Do you know of a better solution? Rather not have a column in my table just for flagging.

Unfortunately, actions have no inherent way to discover from where or why they were invoked, so a work-around like the one @Marc_Dillon suggests is among your few alternatives. If you don’t want to or cannot augment your existing tables to accomplish the goal, you can instead use a separate table created exclusively for this. It’s a little more complex, but cleaner and is more broadly usable.