The Parallel block is a container that runs the block inside it concurrently — once per item in a collection, or a fixed number of times. It is the concurrent counterpart to a Loop: reach for it when the work is independent and order doesn't matter.
Parallel Types
Runs a fixed number of identical instances at once. If the count is larger than the batch size, Sim runs serial batches and preserves the original result order.
Distributes a collection across instances — each one processes a single item as <parallel.currentItem>. Large collections run in serial batches, preserving each item's index.
Configuration
Set the parallel type, then the value it needs:
- Count — how many instances to run (count-based)
- Collection — the array or object to distribute (collection-based)
- Batch size — how many branches run at once, from 1 to 20 (default 20). Lower it to ease off rate-limited APIs
Referencing parallel data
References differ inside the parallel and after it.
Inside, read this instance's context with <parallel.*>:
<parallel.index>— the instance number, starting at 0<parallel.currentItem>— this instance's item (collection-based only)<parallel.items>— the full collection (collection-based only)
These are only available to blocks inside the parallel container.
After it finishes, read the collected results by the block's name — not <parallel.*>:
// a parallel named "Process Tasks"
const all = <processtasks.results>; // [result1, result2, ...]For large result sets, reference just the entry or field you need, like <processtasks.results[10][0].id> — Sim keeps results indexable and hydrates oversized entries only when an indexed path is referenced.
Each instance runs in isolation: a separate variable scope, no shared state, and a failure in one instance doesn't stop the others.
Examples
A collection-based Parallel calls an endpoint for each task at the same time, and a Function aggregates <parallel.results> after they finish. The same container holds the block for either type:
- Batch API processing —
Parallel (Collection) → API (Call Endpoint) → Function (Aggregate) - Multi-model processing —
Parallel (["model-a", "model-b", "model-c"]) → Agent → Evaluator (Select best)
Parallel vs Loop
| Feature | Parallel | Loop |
|---|---|---|
| Execution | Concurrent | Sequential |
| Completion order | Not guaranteed | Sequential |
| Result order | Input/instance order | Iteration order |
| Best for | Independent work | Dependent steps |
| Resource use | Higher | Lower |
Nesting and limits
Containers nest. You can place parallels inside parallels, loops inside parallels, and any combination, to build multi-dimensional workflows.
A Parallel runs up to 20 branches at a time. Larger counts or collections run in serial batches once the current batch finishes. Because instances run concurrently, watch for API rate limits and memory use on large datasets.
Best Practices
- Use it for independent work only. Instances can't share state, so each one must stand alone.
- Mind rate limits. Lower the batch size, or add a Wait, for API-heavy work.
- Handle errors per instance. One failure won't stop the others, so each instance should handle its own.
- Separate result order from completion order. Results retain input/instance order even when branches finish out of order. Use Loop when the work itself must happen sequentially.