Parallel Window

The Parallel Window block is a container that processes a collection with a bounded number of items active at a time. A new item starts when one finishes, and the results keep the input order.

Use a Parallel Window when a collection is too large for the Parallel block (more than 20 items). Also use it when the body calls an API that cannot take every item at once. It accepts up to 1,000 items and runs between 1 and 20 of them concurrently.

Configuration Options

Items

The collection to process. Enter a JSON array directly or a single reference that resolves to an array, such as <api.data> or <start.input.leads>. Anything else fails the block before any item runs with parallel_window items must be a JSON array or an array reference or parallel_window items must resolve to an array.

The collection may hold up to 1,000 items. An empty collection skips the body. The block then outputs an empty results array and total: 0, and the workflow continues.

Maximum Active Items

How many items run at the same time, from 1 to 20 (default 5). When an item finishes, the next queued item starts in its place, so the number of in-flight items never exceeds this value.

Item Result

Exactly one <block.field> reference to a block inside the window, for example <finish.result>. Its value for each item becomes that item's value in the window's results.

The reference must point at a body block. If that block did not run for an item (for example a Condition routed around it), the item fails with Item result block did not execute. If the referenced field is missing, the item fails with Item result did not resolve. A field that is explicitly null is kept as null.

Unhandled Item Errors

What happens when a block inside an item fails and no error path handles it:

Stop the window (default): the first unhandled error fails the Parallel Window block and the workflow run.
Record failure and continue: the error becomes a rejected cell for that item. The rest of that item's body is skipped, and the remaining items still run.

How to Use Parallel Windows

Creating a Parallel Window

Drag a Parallel Window block from the toolbar onto your canvas
Set Items to a JSON array or an array reference
Drag the blocks that should run for each item inside the container
Connect the blocks as needed
Set Item result to the output of the last block in the body, for example <finish.result>
Choose Maximum active items
Choose how to treat Unhandled item errors

Referencing Parallel Window Data

Inside the window, use <parallel.> references to access the current item:

<parallel.index>: Position of this item in the collection (0-based)
<parallel.currentItem>: The item being processed
<parallel.items>: The full collection

// Inside a Function block within the window
const idx = <parallel.index>;           // 0, 1, 2, ...
const item = <parallel.currentItem>;    // This item

Body blocks can also reference blocks that ran before the window and body blocks earlier in the same item. They cannot read the window's own results, total, completed, active, or queued. Those values are not final until every item has settled.

Example Use Cases

Rate-Limited Enrichment - Enrich hundreds of records without exceeding an API's concurrency limit

API (Fetch 500 leads) → Parallel Window (5 active) → API (Enrich) → Function (Normalize) → Table (Insert results)

Bulk Notifications - Send one message per row while keeping a handful of requests in flight

Table (Query rows) → Parallel Window (10 active) → Slack (Post) → Function (Summarize failures)

Advanced Features

Body Restrictions

SteelEngine validates a Parallel Window before the run starts. If the body breaks a rule, it fails the run with parallel_window <id>: <reason>. Inside the window you can use Function, API, Condition, Router, and integration blocks (third-party service blocks such as Gmail or Slack). Other block types are rejected, including Agent, Evaluator, Knowledge, Table, Variables, Wait, Workflow, Human in the Loop, and Response. Document generation is also rejected.

The following are also rejected:

Nesting: a Loop, Parallel, or Parallel Window inside the body, or a Parallel Window placed inside a Loop or Parallel
Connections that cross the boundary: every connection from a body block must stay inside the window. Body blocks can only be entered from the window
Disabled body blocks: disable or delete them
References out of the body: a block outside the window that references a body block's output
Concurrent variable writers: a Variables block anywhere in the workflow that does not run strictly before or strictly after the window. Workflow variables are shared across the whole run, so they cannot be written while items run concurrently

Failure Handling

With Stop the window, the first unhandled error in any item fails the block and the workflow. Queued items never start. With Record failure and continue, the failed item is recorded as { index, status: 'rejected', error }. The remaining blocks in that item are skipped, and the other items keep running. The window still completes, and downstream blocks decide what to do with the rejected cells. An Item result that cannot be resolved counts as an unhandled error and follows the same setting.

An error path connected to a body block handles the error inside the item. Only unhandled errors reach this setting.

Limitations

The collection is limited to 1,000 items and the window to 20 active items. Larger inputs fail the block before any item runs. Nested windows are not supported.

Parallel Window vs Parallel

Feature	Parallel Window	Parallel
Collection size	Up to 1,000 items	Up to 20 instances
Concurrency	1-20 items active, refilled as items finish	All instances at once
Body	Function, API, Condition, Router, integration blocks. No nesting	Any blocks, including nested Loops and Parallels
Results	Flat array, one settled cell per item	One array of settled cells per instance
Failures	Stop the window or record and continue	Always recorded as rejected cells

Inputs and Outputs

Items: JSON array or a reference that resolves to an array (up to 1,000 items)
Maximum active items: Integer from 1 to 20 (default 5)
Item result: One <block.field> reference to a body block
Unhandled item errors: 'Stop the window' or 'Record failure and continue'

Best Practices

Size the window to the slowest dependency: Match Maximum active items to the concurrency the body's API tolerates rather than the maximum of 20
End the body with one block: Route every path in the item to a final Function block. Point Item result at it, so the result resolves for every item
Record and continue for bulk work: Choose Record failure and continue when one bad item should not discard the rest. Inspect the rejected cells downstream
Keep variables outside: Read workflow variables inside the body if you need them, but place Variables blocks before or after the window

Common Questions

A Parallel block runs every instance at once and is limited to 20. A Parallel Window accepts up to 1,000 items and keeps only a bounded number (1 to 20) running. It starts the next item as soon as one finishes. Its results are a flat array with one settled cell per item. It also lets you choose whether an unhandled item error stops the window or is recorded so the other items continue.

Yes. Each cell carries the item's index, and SteelEngine assembles the results array by index. So results[0] is the first item regardless of which item finished first.

It depends on Unhandled item errors. With 'Stop the window', the first unhandled error fails the block and the workflow run. With 'Record failure and continue', the item becomes a { index, status: 'rejected', error } cell. The rest of that item's blocks are skipped, and the remaining items still run. Errors handled by an error path inside the item do not count as unhandled.

Function, API, Condition, Router, and integration blocks such as Gmail or Slack. Validation rejects Agent, Evaluator, Knowledge, Table, Variables, Wait, Workflow, Human in the Loop, and Response blocks before the run starts. It also rejects nested Loop, Parallel, or Parallel Window blocks.

No. A Parallel Window must sit at the top level of the workflow, and it cannot contain another container. The workflow fails validation with 'nested windows are not supported' otherwise.

Workflow variables are shared across the whole run. A Variables block that could run at the same time as the window would race with the items. So every Variables block must run strictly before or strictly after the window. Move it upstream of the window or connect it after the window's exit.

It names the single value that represents each item, as one <block.field> reference to a block inside the window. That value becomes the item's value in results. If the referenced block did not run for an item, the item fails with 'Item result block did not execute'. If the field is missing, the item fails with 'Item result did not resolve'.

Parallel Window

Common Questions

On this page