Option for serial execution of a ForEachRow Scheduled Event

[Marc_Dillon]

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.

---

Scenario #1

• 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).

---

Scenario #2

• 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 issue:
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.

[MultiTech]

While I totally agree with this, being able to run things in serial would be most helpful, there might be another way you could go about things as of now.

Marc_Dillon:

Scenario #1

• I have a large Table of records that are being populated via Zapier.

Did you know about the Google sheet automation ad-on? (I assume you’re using Google Sheets as your data source, using Zapier and all. I could be wrong though!)

• This might help solve the problem of duplicates during parellel processing, because the automation is triggered from the sheet side when a record is added - and this by nature will run serially… I would think you’ll likely get around your parellel processing issue.

---

Marc_Dillon:

Scenario #2

The issue:
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 Day s.

• For this I would make use of the “Create a record in another table using values from this row” action to make the 3 individual child records - one action per record needed to be created.

  • I would then make use of a bot, triggered upon an Add to the Parent table, that runs the record creation actions automatically.

• Because these actions are executed when a parent record is created - by nature they’ll run serially.

---

Again, I totally agree with being able to run bots serially - it would be extremely helpful in certain situations

• Just throwing out other options. (^_^)
  

[Marc_Dillon]

Thanks for the suggestions. I thought of the exact same things. For #1 though, I believe that external eventing add-on doesn’t work for records that come in from Zapier, only manual changes. I haven’t actually tried it though…

MultiTech_Visions:

I would then make use of a bot, triggered upon an Add to the Parent table, that runs the record creation actions automatically.

I also don’t think this would work, because the parent record is created by a Bot. Bot adds don’t trigger other Bots.

(but don’t worry, I already have solutions for both of these scenarios)

[MultiTech]

Marc_Dillon:

I also don’t think this would work, because the parent record is created by a Bot. Bot adds don’t trigger other Bots.

• Just FYI

---

All this is besides the point…

- Being able to run bots serially over a set of records would be extremely helpful

• Another benefit from this would be Loops within automation (similar to looping with actions)

[Rifad]

I hope the bots are running serially, but they are hitting a timeout and not updating any rows. The 'ForEachRow' function used to update in real-time for hundreds of rows, allowing us to see updates until a timeout occurred. Currently, the bot waits for all rows to process before updating, hitting a hard limit on timeouts. The audit log indicates completion, but actual updates to the sheet/database only occur after processing is fully complete with a return value.

It should operate as follows: Row 1 -> Update Return Value, then Row 2 -> Return Value. Instead, it processes Row 1, Row 2, ... Row 100 -> Update Return Value

This is executing external API calls for hundreds of requests but not returning any data. It's unclear whether this is intended behavior, and support has been unable to offer any answers or solutions.