We are excited to announce a new set of Serial Loop operators in Workflows that support up to 1,000 iterations per loop. With these operators, you can process large lists one item at a time and repeat steps until a condition is met without hitting the 250-item limit of today’s ParallelLoop operator.
What you need to know
The new loop operators run in serial (one iteration after another). They do not replace the existing parallel Loop operator (250-item cap) - both will be available.
Serial loops support up to 1,000 iterations per loop.
This release includes the following new features:
For Loop: iterates once for each item in a data set.
While Loop: iterates while a user-defined condition is met.
Break Operator: exits a loop early (for example, on first success or first failure).
Existing parallel Loop operators in your workflows keep working and are not converted.
Problem
Today, Workflows only supports parallel loops with a 250-item cap. Customers building bulk identity updates, paginated API consumption, and retry-style flows have told us they need:
Higher iteration counts than 250 items.
Serial (one-at-a-time) execution instead of parallel, to reduce memory/load and to keep ordering predictable.
A way to repeat until a condition is met (e.g., “retry create until it succeeds,” “loop while there is a next page”).
Without these, customers either split work across multiple workflows, build custom retry logic outside Workflows, or simply can’t automate the use case at all.
Solution
This release delivers four main value drivers:
Process larger lists, in order: Use a For Loop to iterate over up to 1,000 items in serial. This can be used for things like bulk identity updates and other use cases that exceed today’s 250-item parallel Loop.
Repeat until a condition is met. Use a While Loop with a defined condition to iterate until success, loop while there is more data, or stop as soon as something changes. Combine with Break to exit early on a success or first failure.
Love this new functionality - I assume the documentation won’t be updated until the production rollout date? I was hoping to find out whether the serial loops have this same behavior as the existing parallel loop:
“Later actions and operators in the workflow can begin before the loop step has finished iterating over all objects in the list. However, the workflow itself can’t end until the loop has finished executing. For this reason, adding additional steps outside of the loop between the Loop operator and the end step is not recommended.”
Will a serial loop hold up steps that are outside of the loop between the loop and the end step, or will the rest of the workflow still process while the serial loop is still iterating?
Hey @MattUribe You are correct. We’ll be publishing documentation when we roll out to production.
Will a serial loop hold up steps that are outside of the loop between the loop and the end step, or will the rest of the workflow still process while the serial loop is still iterating?
For Serial Loops, the workflow will pause/wait for the loops to complete before processing the rest of the workflow
Hi, has this been rolled out to Sandbox tenants yet please or when is it scheduled to? I can see May 11th it was meant to roll out but can’t see it in my tenants as of yet. Thanks
Hi Takato, thank you for this I can see it. Is the Break Operator not included as of yet as I can see on that one you can do first success or first failure but this looks to be not currently available.
This may be out of your scope, but do you happen to know when this will be rolled out to all tenants, like the devrel-ga tenants that ambassadors have? I was looking to test out this functionality there, but not seeing the option there like I do in my clients sandbox tenants. This may be a question for @tyler_mairose.
Is there an ETA or date that we know this change will be added in production?
We currently have the workaround using $.loop.loopInput and want to be sure our workflows in production don’t stop working or producing incorrect results due to this update. Will $.loop.loopInput continue to work after this bug fix is updated or will we need to make a change when this is pushed?
@trettkowski@yuyanglee I apologize, I was incorrect. The expression should follow the activity name. ($.<Loop_Name>.loopInput). In your examples if would follow $.serialLoop.loopInput if your activity name was serial loop
The bug fix was deployed so please let us know if you’re still seeing issues.
I noticed some behavior that I wanted to be sure is intended. If possible, I would love an explanation of how this works in the backend.
In my workflow I’m using a Serial For Loop, but when I perform a Get Identity inside, it seems to work and provide the correct output, but if I try to use the data from the output ($.getIdentity.managerRef.id), it always takes the data from the first execution. I would expect to see my Define Variable update with the output from Get Identity in execution 2. Is this correct?
I noticed that when running a test workflow with a serial loop, it seems to limit the execution to 50 iterations. Has anyone else encountered this? I couldn’t find any mention of this specific limitation in the documentation, so I wanted to see if this is intended behavior.
