I’d like to see an On/Off option (defaulted to Off as it is now) available for Schedule-type Events, when ForEachRowInTable is turned on, that makes the execution of the associated Process happen serially for each record, rather than in parallel like how it works now.
I think the best way to explain the “why” for this feature, is to describe a scenario or two which I’ve just recently built that would benefit from it.
- I have a large Table of records that are being populated via Zapier.
- One of the columns contains a [Location].
- I need to keep a separate Location Table, that consists of unique values from the [Location] column.
- New unique values are coming in very often, so I need to keep it up to date.
So I’ve created a ForEachRow Schedule Event that runs every night, it checks each [Location] against the existing Location records, and adds a new record if one doesn’t exist.
Here’s the problem though:
If more than one new record exists in the first Table, with the same new unique [Location] value, then the Bot is going to create more than one new Location record, with that same value. That is because the Event conditions are checked against every record at the same time, instead of one after another. (i.e. in parallel, instead of serially).
- This is a daily time-keeping type log app.
- It is used by several different users.
- It is set up for each user to see only their own Day record.
- Each Day record comes with a few standard child records.
- For ease of use, I want each Day record, and its associated standard child records to be auto-generated for the users.
So I set up a ForEachRow Schedule event, that runs every morning, to add the records for each user per day.
The Bot was originally set up with 2 Processes, one to add the Day record, and one to add the standard child records associated with each Day. I wanted to use something like
MAXROW( Day , _RowNumber) to auto-populate the Ref value in each child. The problem was though, that since the execution wasn’t done serially, every child record got associated with only one Day record, instead of spread out between the different record how they needed to be. i.e., there were 15 child records associated with one Day, instead of 3 child records each, across 5 different Days.
There are certainly different workaround solutions for the scenarios mentioned above, however I feel that it would be more “natural” to set them up how I originally attempted, which would only work if I could turn on a serial execution option.
Thanks for reading and considering. Please let me know if the above makes sense, and if anyone else has other scenarios that could benefit from this feature.