I'm trying to set up an automation step that will create a set of filtered rows combined with values from the trigger row.
When the filter runs, the source table scope changes to the filtered row making the trigger row values no longer available.
Is there a way to still access the trigger row values from within an automation step that has a conditional filter in place?
I have a solution that may work for you
(I'll note that I just removed a previous reply of mine, as I realized it may not have helped with your scenario.)
If the context source changes to a different row (such as by filtering a different table), here's a way to get desired values from the initial trigger row:
You can set up another table with a column to temporarily store the desired value for the automation, which you would delete at the end of the automation. You'll be using that temporary value to write to your new desired location.
These are the steps:
Create a table with a column to temporarily store the value. (i.e. a Temp_Table table with Temp_ID column).
Then in your automation, for the first action, have the desired value write to that column in the temporary table:
Then in your next action, add a row to your desired table and add in your run conditions (the filter). And in the "take data from" field, take desired value from the last row added to to the temporary table. This will write the desired value to your specified location:
Then add one more action to the automation that deletes the temporary row that was added:
Let me know if this works for you.
Moderator Note: Post edited, updated with new solution.
How clever @Alyssa! This does the trick.
With this approach, have you ever seen race conditions arise compromising the data integrity? Theoretically if two people were on the application at the same time, and performing similar actions, there's the possibility of their data getting commingled in the last row.
Won't happen if it's only one user, but curious to see if it's an actual problem that's come up for people.
Awesome! I'm happy that worked for you.
And that's a great question to ask. I just confirmed that in Honeycode, when blocks are in the same automation, they will never result in a race condition. In other words, they won't conflict as the execution is sequential, and there is no parallel execution on same workbook.
So for the automation I suggested in the solution, you will not see a race condition that you will need to account for.
Moderator note: Post edited, confirmed information around Honeycode model.
Thanks for the clarification. One last question.
We're using the automation to create a row in another table. That table has some formula columns populated when the row is created.
If we're creating another trigger when the row is added to that table, does that trigger ever execute before the formula populates the column? Or do we need to set a trigger to track the cell change of that column?
Another great question! Happy to answer -
If you have a formula set as metadata in the column (i.e. in the format of the column), the formula would execute before the automation trigger is executed.
This means that it wouldn't be necessary to set a trigger to track a cell change of the column.
Let us know if you have any other questions.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.