The Parallel container runs its blocks for multiple items or instances concurrently. Use it when the work is independent; use Loop when iterations must run in sequence.
Process tasks in batches
Name the container Process Tasks and distribute a task array. The inner API reads <parallel.currentItem>. After every batch finishes, the Function reads <processtasks.results>.
Configuration
Counts or collections larger than Parallel Batch Size run in serial batches. Lower Parallel Batch Size for rate-limited APIs. A Wait within each branch spaces that branch's work, but does not impose a global request rate across all branches or runs.
References and outputs
Inside the container:
Arrays yield their values as currentItem. Objects yield [key, value] pairs, so <parallel.currentItem[0]> is the key and <parallel.currentItem[1]> is its value.
After completion, use the container's normalized name: <processtasks.results>. Generic <parallel.*> references select an enclosing parallel context, not a completed container outside it.
Results retain input/instance order, even when branches finish out of order. Each entry contains that branch's block outputs. For a single API per branch, read a field with <processtasks.results[10][0].data.id>. Indexed paths hydrate oversized entries only when needed.
State and failures
Each branch has its own item, index, and block outputs. Workflow variables are shared across branches; they are not an isolated per-branch store.
An empty collection skips the body and returns empty results. Parallel and Loop containers can nest in either direction; use the reference picker to select the intended scope.
Parallel or Loop
A Parallel can compare the same prompt across several models or call an API for each record. Bound concurrency and collection size according to provider limits and the workflow's execution budget.