Parallel Join Node
Wait for all parallel lanes to complete, merge their results, and continue the workflow as a unified execution.
lane_0_*, lane_1_*, etc.), assembles a lane_outputs collection, sets IsParallelExecutionActive = false, and fires its success port to continue the workflow.
Key Capabilities
- Waits for ALL parallel lanes before proceeding — provides a clean synchronisation barrier ensuring no downstream node runs before all parallel work is complete.
- Collects each lane's final execution context into
lane_N_*prefixed memory keys, making all lane results accessible to downstream nodes through standard$varexpressions. - Creates a
lane_outputsarray in memory containing all lane result objects, enabling downstream nodes to iterate over results or access specific lanes by index. - Restores single-thread execution by setting
IsParallelExecutionActive = false, signalling that normal sequential execution has resumed. - Records per-lane success/failure status, allowing downstream logic to check which lanes succeeded and which failed when
fail_fastis false. - Requires no configuration — the Join node automatically detects which Fork node it is paired with based on the workflow graph structure.
Business Benefits
The Parallel Join is the essential counterpart to the Parallel Fork — without it, parallel execution would produce results that cannot be used by subsequent workflow steps. The Join node provides the structured merge mechanism that makes parallel execution practical for real business workflows.
The prefixed lane output structure (lane_0_*, lane_1_*) gives downstream nodes precise access to each lane's individual results. A node after the Join can compare the email send result (lane_0_status) independently from the SMS result (lane_1_status), enabling fine-grained post-parallel routing based on exactly which channels succeeded.
The lane_outputs collection enables aggregate analysis of all lane results. Downstream nodes can count how many lanes succeeded, sum numeric results from all lanes, or identify which lane produced the best outcome — patterns that are common in scenarios like parallel supplier price queries where you want to select the lowest quoted price from multiple concurrent results.
By setting IsParallelExecutionActive = false after joining, the execution engine cleanly transitions back to sequential mode, ensuring that subsequent nodes behave normally without any special parallel-context considerations.
Use Cases
Aggregate Results from Parallel API Calls
After a Parallel Fork calls three enrichment APIs concurrently, the Join node merges their results. A downstream Set Variable node combines $var.lane_0_creditScore, $var.lane_1_riskLevel, and $var.lane_2_loyaltyTier into a single unified customer risk profile object ready for the decision engine.
Combine Parallel Notification Outcomes
After parallel email, SMS, and push notification lanes complete, the Join node provides per-channel delivery results. A downstream If Condition can check whether at least one notification channel succeeded and route accordingly — if all three failed, escalate to a manual contact task.
Merge Concurrent Data Enrichment Results
Multiple data enrichment lanes — each calling a different data provider — run concurrently and complete at different times. The Join node waits for the last provider to respond, then presents all enriched fields in a structured format for the record update node.
Consolidate Parallel Validation Results
Four parallel validation checks (credit, identity, income, address) run concurrently. The Join node collects all four pass/fail results. A downstream If Condition checks whether ALL four lanes returned success — if any failed, the loan application is routed to a human review queue with the specific failed checks identified.
In This Guide
Configuration
The Parallel Join has no configuration. This page explains auto-pairing with Fork, the memory structure written, and the execution state transition.
Input & Output
The success port, lane_N_* memory keys, lane_outputs collection structure, and data flow after the join completes.
Examples
Complete Fork+Join configurations for notification aggregation, API result merging, and parallel validation consolidation.