Portal Community
Always pair with Parallel Join: The Parallel Fork node must always be used in conjunction with a Parallel Join node. The Fork splits execution into concurrent lanes; the Join waits for all lanes to complete and merges their results. A Fork without a Join will leave the workflow in an incomplete parallel state.

Properties

Property Type Required Default Description
fail_fast boolean Optional false When true, if any parallel lane fails (throws an unhandled error), all other running lanes are immediately cancelled and the workflow transitions to an error state. When false, all lanes run to completion regardless of individual failures — failed lanes report their errors via the Join node's merged results.
max_parallelism integer Optional 0 (unlimited) Maximum number of lanes to execute concurrently. When set to a positive integer (e.g., 3), lanes beyond this limit are queued and execute as earlier lanes complete. A value of 0 means no limit — all lanes start simultaneously. Use this for rate-limited external integrations.

Execution State Flag

When the Parallel Fork node activates, it writes the following flag to the execution memory before launching the lanes:

Memory Key Value Set By Fork Cleared By
IsParallelExecutionActive true Parallel Join node (sets to false after all lanes complete)

Choosing fail_fast Setting

Scenario Recommended Setting Reason
Financial transactions (debit + credit must both succeed) fail_fast: true A failure on either side should immediately cancel the other to prevent partial transactions
Multi-channel notifications (email + SMS + Slack) fail_fast: false A failed SMS should not prevent the email from sending — partial delivery is better than no delivery
Parallel API enrichment (all results needed) fail_fast: true If any data source is unavailable, the full enriched profile cannot be assembled
Parallel document generation (best effort) fail_fast: false Generate as many documents as possible even if one renderer fails
Context isolation: Each parallel lane receives an independent copy of the execution context at the point the Fork fires. Changes made to variables within one lane are NOT visible to other lanes during execution. The Parallel Join node merges lane results into prefixed memory keys (lane_0_*, lane_1_*, etc.) — the original pre-fork variable values remain unchanged in the base context.