I am trying to understand how "Update and Insert Rows" actions work when the table being updated is not the one with the triggering action.
The "step" in "Run step if this condition is met:" - is this referring to running the "action" block? Is this on a per row basis from the trigger action?
"Run the step for these rows:" refers to the rows in which table - trigger or target?
How does the "Custom" matching condition work - can I match using values from columns from both trigger and target tables?
Can I "take data from" a column in the target table's row as part of the formula?
Hello @Bainar! We are very excited that you are using Honeycode. Here are the answers in the order:
The "Run step if this condition is met" is applicable to the triggering row. A triggering row is the table row on which automation is triggered.
"Run the steps for these rows:" is applicable to the target. This condition is also known as iteration condition or iterator. The automation step runs for the iterator rows i.e. rows returned by the iterator condition.
The matching condition in Update or insert row is used for matching rows between the source or the context row/table and the destination row/table. When an iterator is present, the context row for the step or block is now iterator row.
If the target table's row is not empty, you can try to refer to this value in "take data from".
Is the iterator variable available? That is, is it possible to determine how many rows returned by the filter and which iteration you are currently on?
First off, I don't know how to get the iterator while you are doing the automation. You may be able to get the total count somehow before or after and save that somewhere.
The example I will give here is from an app I wrote a while ago, it allows you to create a Request for a meeting, and when you've created the Request it automatically adds the creator as an Attendee, and then, based on the request type adds all the attendees associated with that meeting type. This will showcase how to:
Conditionally run a step in an automation (if RequiredFields=TRUE on the current Request creation screen)
Pull rows from another table (RequestTypeDefault) to iterate through
How to actually lay down the data into a third table (Attendees)
So we have three tables: Request, Attendees and RequestTypeDefault (attendees). When we save the record in the Request table we want to add the creator or the request to the Attendees table, and pull n-number of RequestTypeDefault into Attendees table based on the type of Request this is (ie. invite Finance to a pricing meeting type, and Recruiting to a recruiting planning meeting type, etc.).
Here are the Automation steps (ignore the warnings, they are misleading the formulas work but cannot be resolved immediately and the validator is too sensitive atm. I've opened a issue about it.)
Here (second Attendees step, the setup of the Run Options for this step) is how I check if RequiredFields is true, or maybe I should check if request Type<>"" (not blank). This is where I get the default attendees to iterate over; but only the ones that are associated with request Type=$[Type] (that is only of the type that my newly entered Request is)
Finally, here (also second Attendees step, just further down) is how I write the default attendees into the Attendees table. I write the Name and the Role (and other fields as well). Notice that in this context THISROW() refers to the records I just pulled above in the "Run this step for these rows:" setting.
My fundamental problem is how to operate on a number of rows based on an input number. Even better would be to operate on a number of rows where they have a column holding a value and the operation stops once the sum of the values is >= to the input.
Is it even possible to expand a value into multiple rows? I think the word I'm looking for here is "loops"...
@Bainar, good question. I'll check with our product team to see if "loops" are possible if if that needs to go on the feature request track.
In the meantime it may help to explain (if possible) why you are trying to do loops; there are sometimes creative ways to do things.
One way I can think of doing this is to create a table called "Loops" (fields: LoopType and IterationNumber), in this table you store one row (A,1), and then two rows (B,1),(B,2), then a loop with three rows (C,1),(C,2),(C,3), etc... Then you can iterate exact number of times, based on the "loop type". On the form itself you would have to choose (perhaps in a hidden field) which loop to run. I've done something similar in the example above; in that case the RequestTypeDefault is the iterator (loop determining) table.
If possible tell us more about "why," but I'll also ask our product team about loops specifically.
