You have a list of 500 invoices to process, and your For Each loop is taking forever because it handles them one at a time. You’ve heard UiPath has “parallel” options that can speed things up — but there are actually two of them, Parallel For Each and Parallel, and they are not the same thing. Which one do you reach for, and when does parallelism actually help instead of breaking your automation?
Understand how sequential and parallel execution differ in UiPath, when each loop type is safe to use, and how to pick the right one without introducing race conditions or unpredictable output.
Solution
For Each Activity
Use the For Each activity when you need to process items one after another, in a guaranteed order. This is the default, safest choice for almost every UiPath workflow.
Dependencies UiPath.Core.Activities
- Activity: For Each Activity.
- Execution: Strictly sequential — item 2 never starts before item 1 finishes.
- Output: Predictable, ordered results every single run.
Parallel For Each Activity
Use Parallel For Each when you need to loop through a collection, but the items don’t depend on each other and you want to process several of them at the same time to save time.
Dependencies UiPath.Core.Activities
- Activity: Parallel For Each Activity.
- Execution: Multiple items processed concurrently, up to a configurable degree of parallelism.
- Output: Faster overall runtime, but the order of completion is not guaranteed.
Parallel Activity
Use the Parallel activity when you have a fixed, small number of different branches (not a collection) that all need to run at the same time — for example, checking three separate applications simultaneously before proceeding.
Dependencies UiPath.Core.Activities
- Activity: Parallel Activity.
- Execution: Runs distinct branches concurrently until all (or one, depending on config) complete.
- Output: Combines results from independent branches, not from a looped collection.
Sequential vs Parallel Execution
| Aspect | For Each | Parallel For Each | Parallel |
|---|---|---|---|
| Input | Collection | Collection | Fixed set of branches |
| Order | Guaranteed | Not guaranteed | Not guaranteed |
| Speed | Slowest | Fastest for large lists | Fast for few branches |
| Complexity | Low | Medium-High | Medium |
Thread Safety
This is where most beginners get burned.
- For Each is inherently thread-safe — there’s only one thread doing the work, so shared variables never collide.
- Parallel For Each runs on multiple threads. If two iterations write to the same shared variable (like a counter or a shared DataTable) at the same time, you can get corrupted data or missed updates. Use thread-safe collections, locking, or accumulate results after the loop instead of during it.
- Parallel has the exact same risk — each branch is its own thread, so avoid writing to shared state without protection.
Performance Comparison
- For Each on 500 items: if each item takes 2 seconds, expect roughly 1,000 seconds total.
- Parallel For Each on 500 items (5 threads): roughly 200 seconds — a real, measurable win when items are independent.
- Parallel on 3 branches: runtime is close to the slowest branch, not the sum of all three.
The speed gain from parallelism only shows up when the work itself is the bottleneck — not when you’re limited by API rate limits, application UI response time, or a single database connection.
💡 Best Practices
- Default to For Each unless you have a proven, measured performance problem.
- Only use Parallel For Each when items are truly independent — no shared state, no dependency on previous results.
- Set a sensible MaxDegreeOfParallelism — don’t let 500 threads hit a UI application at once.
- Log with item identifiers, not just messages, since parallel logs can interleave and become hard to trace.
- Use Parallel for a small, known number of distinct tasks, not as a substitute for looping.
⚠️ Common Mistakes
- ❌ Using Parallel For Each on UI automation against a single application window (multiple threads fighting over the same UI element).
- ❌ Writing to a shared DataTable or Dictionary inside Parallel For Each without any locking.
- ❌ Assuming Parallel For Each preserves item order in the output.
- ❌ Using Parallel when you actually have a collection to loop through (that’s what Parallel For Each is for).
- ❌ Not setting a degree-of-parallelism limit, overwhelming downstream systems or hitting API rate limits.
When to Use Which?
- For Each → UI automation, order-dependent processing, anything touching shared state, and honestly, most workflows.
- Parallel For Each → Bulk API calls, independent file processing, or any large, order-independent dataset where speed genuinely matters.
- Parallel → A handful of distinct, independent checks or tasks that should kick off together (e.g., validating 3 separate systems before continuing).
Cheat Sheet
| Need | Use |
|---|---|
| Guaranteed order | For Each |
| Large independent collection, speed matters | Parallel For Each |
| Few fixed independent branches | Parallel |
| Touching shared UI/state | For Each |
| Bulk API/file processing | Parallel For Each |
Rule of thumb: start with For Each. Only reach for parallelism once you’ve confirmed the workload is independent and the sequential version is actually too slow for your use case.