Refining Large Workloads in SailPoint Workflows with 1K Serial Loops
When you are creating a workflow in SailPoint Identity Security Cloud you will eventually reach a limit on how many items you can handle in one workflow run. SailPoint Identity Security Cloud workflows can get really complicated.
Parallel Loops in SailPoint Identity Security Cloud are fast. There is a limit of 250 items and the order is not always the same, which makes things tricky when you are dealing with a large number of items, in a real-world enterprise using SailPoint Identity Security Cloud.
SailPoint’s new Serial Loops change the equation by letting process up to 1,000 items per loop, one at a time, with predictable execution.
In this post, we are going to see a walk through on what changed, how Serial Loops behave compared to parallel Loops, and when they’re worth using in your designs.
Why Serial Loops were needed
Parallel loops are really useful when you need to do things fast. You do not care about the order in which they happen. You can start a lot of actions at the time let parallel loops run them all, at once and trust that the system will take care of everything when they are done.
The downsides of using loops are:
You’re capped at 250 items per loop.
Iterations run in parallel; the system does not wait for iteration 1 to finish before it starts running iteration 2.
Steps that follow the loop can start even while some iterations are still running.
That’s fine for one‑off notifications or small batches. It’s less fun when you’re:
Running bulk leaver clean‑up for hundreds of identities.
Calling an external system that doesn’t like traffic spikes.
Trying to debug a workflow where state changes overlap in unexpected ways.
Serial loops are good for situations where order and predictability are more important, than just doing a lot of things at the same time. We use loops when scale is also important so we can make our work bigger if we need to.
The new building blocks: For, While, Break
The Serial Loop capability introduces three key elements you’ll see on the canvas.
For Loop
The For Loop makes sure each thing in the collection is done before moving on to the next one, in the collection.
Examples:
Joiner/mover/leaver flows that must follow a specific sequence.
Bulk entitlement or attribute updates where blasting 250 calls at once is risky.
Scenarios where you genuinely care about “item N ran after item N‑1.”
While Loop
The While Loop is really good, at doing things over while something is true.
Examples:
REST APIs Pagination – keep calling the Paginated REST APIs until there are no page tokens, from the Paginated REST APIs.
Retry loops – repeat until status == success, but stop after a max number of attempts.
Polling flows – check an external system periodically until it reports completion.
This gives you native support for pagination and long‑running flows without bizarre workarounds.
Break operator
The Break operator is, like a way when you really need it. It helps you get out of the Serial Loop.
You might:
Stop at the first successful action (e.g., first reachable system).
Abort on a critical error and jump into a failure path.
Exit once a threshold is reached instead of processing all remaining items.
You’re no longer forced to chew through every item just because the loop started.
Parallel vs. Serial at a glance
Here’s a quick side‑by‑side view you can drop straight into your post.
Aspect | Parallel Loop (existing) | Serial Loop (new) |
|---|---|---|
Max iterations per loop | 250 items per execution. | Up to 1,000 items per execution. |
Execution style | Items processed concurrently (asynchronous). | Items processed one by one (sequential). |
Downstream behaviour | Later steps can start before all items finish. | Workflow waits until loop completes or Break exits. |
Order guarantees | No guarantee which item finishes first. | Strict order of execution. |
Best suited for | Fast, independent actions and small batches. | Order‑sensitive flows, larger batches, pagination, retries. |
State handling | Shared counters and variables can clash due to concurrency. | Safer to update shared variables because only one iteration runs at once. |
Early exit option | No built‑in early exit; all items are processed. | Supports early exit via Break operator. |
This table gives a clear picture of when to pick each loop type.
How Serial Loops change execution flow
The other big difference is what happens after the loop.
When you are using a Parallel loop the things that happen after the loop can start even if the loop is not finished. The workflow does not have to wait for the parallel loop to be completed.
When you are using a Serial loop the workflow has to wait for the loop to finish before the next things to do. It will start until the serial loop is completed or stopped.
That makes patterns like ‘Walk every page of an API, then write one combined record somewhere else’ much easier to understand and think about.
Parallel Loop vs. Serial Loop
Stick with parallel Loops when:
You have up to 250 independent items.
Order is irrelevant.
You want the most work to be done in a time and the target system is able to handle burst of work.
Reach for Serial Loops when:
You need to handle up to 1,000 items without splitting flows.
Execution order matters.
You’re working with pagination, retries, or long‑running checks.
You want to avoid concurrency issues.
On that last point: counters and shared variables are risky in parallel Loops because multiple iterations try to update the same variable at the same time. Serial Loops don’t have that problem - only one iteration is active - so iteration counters and stateful variables behave much more predictably.
Where to start refactoring
If you are already sitting on a lot of workflows these workflows are ones to start with.
Flows chained together purely to escape the 250‑item limit.
Customized pagination or retry patterns that are hard to maintain.
Swapping those out for Serial For/While Loops plus Break usually results in simpler, more readable workflows that behave the way you expect under load.
Conclusion
Serial Loops are not replacing parallel Loops; they give a different tool for a different set of problems. Parallel still wins when you want sheer speed for small, independent actions. Serial shines when you care about order, scale, and control.
