Is it possible to set up a looping action in such a way that the looping of all the items does not happen asynchronously (in parallel) and without pausing each iteration with a whole minute in between each loop? My understanding is that this is one purpose that the Delay by Zapier app is meant for when using the “Delay after queue” event. However, there is a minimum value of “1 whole minute” for the time delay. That is unacceptable for my purpose.
How can I set it up in such a way that the Looping by Zapier app follows a predetermined sequence (for simplicity’s sake, let’s just say “follows the sequence of the line item’s index number within the line item group”), and each of the loop’s iterations wait in queue to be triggered, not until their previous iteration first completes its loop?
I’m a no-code geek who is starting to mature into the world of “low code.” And there’s no way my technical requirement here is unorthodox.
I’m pretty comfortable with webhooks, paths, sub-Zaps (and getting comfortable with Storage and Code by Zapier, working with JSON/Javascript) etc. in case there are any routes to take in either of those directions.
As an added curious question: Even if I settle for using the expected asynchronous behavior of the Looping by Zapier app, is it always guaranteed that the last iteration in the loop will wait for all other iterations to first be complete?
I have a filter at the end of my loop that says “only continue if mthis line item’s value for] loopIterationIsLast = TRUE” in order to log a summary of everything so far (capture all the actions from all the loop’s iterations).
In my experience, this has worked as desired. But to my surprise, if I have examples of my “resulting summary” where ‘iteration 3 out of 5’ was the last one to get printed… suggesting that the last iteration (‘iteration 5 out of 5’) completed its “journey” (including passing the filter logic that all other iterations would get blocked by) before some other iterations completed theirs. How then, was ‘iteration 5 out of 5’ able to capture data, from the post-filter steps, that didn’t yet exist (understanding that all of this stuff happens in a weird world of milliseconds)?
Does this suggest that in my latest example, when there is a filter within a loop that gates everything except for the last iteration, it somehow naturally stages a queue for all other things to happen in parallel before proceeding with actions after the filter? I’m assuming not...
Do I ever run the risk of my post-filter ‘summary logging’ steps missing data from some of the loop’s other iterations because these post-filter steps starting to do their thing for the last iteration before such other loop iterations were completed? If there is some risk of this happening, then, functionally, what is even the point of the Looping by Zapier app producing attribute values for the iterations such as “Loop Iteration Is Last”?