The Branch and Merge nodes are structural flow-control nodes used together to create parallel execution paths within a workflow. The Branch node splits a single path into multiple parallel paths, and the Merge node brings those parallel paths back together into a single path. They are always used as a pair — Branch to fan out, Merge to converge.

Neither node has any configurable logic. They carry no conditions, no request configuration, and no data transformation. Their sole purpose is to control the shape of the workflow graph — enabling you to run multiple steps simultaneously and then synchronize before continuing.

Both nodes are hidden from the end user's progress tracker. They are invisible infrastructure; the user only sees the meaningful steps (actions, inputs, approvals) that run inside the parallel branches.

---

When to Use

Use a Branch and Merge pair when your workflow needs to:

• Run multiple actions in parallel rather than sequentially (e.g., simultaneously create a ticket in ServiceNow, send a Slack notification, and update a Salesforce record).
• Fan out to several independent processing paths and wait for all of them to complete before moving on.
• Split work across different systems or teams that do not depend on each other, then reconverge to a single downstream step (e.g., an approval that should only start after all parallel integrations finish).
• Reduce overall workflow execution time by running non-dependent steps concurrently instead of one after another.

---

Branch Node

The Branch node is an unconditional fan-out point. When execution reaches a Branch node, the workflow immediately proceeds down all of its outgoing edges simultaneously. There is no condition evaluation — every connected downstream path starts executing in parallel.

How It Works

1. A single execution path arrives at the Branch node.
2. The Branch node completes instantly — it performs no processing or data transformation.
3. The executor identifies all outgoing edges and enqueues each downstream node as an independent execution job.
4. All parallel paths begin executing concurrently.

Unlike a Decision node (which evaluates conditions and follows only the matching path), the Branch node follows every outgoing path unconditionally. It is a pure structural splitter.

Edge Rules

Configuration

The Branch node has no configurable properties beyond its name and description. There are no conditions, mappings, timeouts, retries, or request settings. It is a zero-configuration structural node.

---

Merge Node

The Merge node is the convergence counterpart to the Branch node. It collects all incoming parallel paths and waits until every one has completed (or been skipped) before allowing execution to continue downstream. This synchronization ensures that the step after the Merge node only runs once all parallel work is finished.

How It Works

1. The first parallel path reaches the Merge node. The system records that this path has arrived but does not continue downstream yet.
2. Additional parallel paths arrive one by one. Each arrival is tracked.
3. When the last expected path arrives — meaning the number of arrived paths equals the number of incoming edges — the Merge node completes and execution continues down its single outgoing edge.

The Merge node uses an atomic counter to track how many paths have arrived. Each time a path reaches the Merge node, the counter increments. Only when the counter matches the total number of incoming edges does the node release and allow downstream execution to proceed.

Skip Propagation

If all incoming paths to a Merge node were skipped (e.g., because they were on the losing side of upstream Decision nodes), the Merge node itself is also marked as skipped. This skip status propagates downstream — all subsequent nodes after the Merge are also skipped until the workflow reaches a node that breaks the skip chain.

If at least one incoming path executed normally (was not skipped), the Merge node executes normally regardless of how many other paths were skipped.

Edge Rules

Configuration

Like the Branch node, the Merge node has no configurable properties beyond its name and description. There are no conditions, mappings, timeouts, or retries.

---

Using Branch and Merge Together

A typical parallel execution pattern looks like this:

[Previous Step] → [Branch] → [Path A: Action Node]     → [Merge] → [Next Step]
                           → [Path B: Action Node]     ↗
                           → [Path C: Input Node → ...]↗

The Branch node fans out to three parallel paths. Each path can contain one or more nodes of any type — actions, inputs, approvals, decisions, delays, or even nested branch-merge pairs. The Merge node waits for all three paths to complete before the Next Step begins.

Pairing Guidelines

Branch and Merge nodes are designed to work as a pair, but the system does not enforce a strict one-to-one pairing at the model level. Instead, the following structural rules apply:

• A Branch node can fan out to any number of paths, and those paths can reconverge at the same Merge node or at different Merge nodes.
• A Merge node can receive paths from any number of sources, not only from a single Branch node.
• However, a Branch and a Merge node must not form a cycle — if the system detects a cycle that contains both a Branch and a Merge node, it flags it as an invalid "irrelevant cyclic execution" and blocks publication.

What Can Go Inside Parallel Branches

Each parallel path between a Branch and a Merge can contain any combination of workflow nodes, including Action nodes, Function nodes, Input nodes, Approval nodes, Decision nodes, Delay nodes, Async Callback nodes, and even nested Branch-Merge pairs for more complex parallel structures.

There are no restrictions on the types of nodes that can appear within a parallel branch. However, keep in mind that the Merge node will wait for all paths to complete — so a long-running path (e.g., one containing an Approval node waiting for a human response) will hold up the Merge node and everything after it.

---

Behavior in Different Contexts

Inside a Synchronous Block

Both Branch and Merge nodes can be placed inside a Synchronous Block. When used in a sync block, parallel paths are executed sequentially (one after another within the same in-memory queue) rather than truly in parallel, because sync block execution happens in a single real-time request. The Merge node still waits for all paths to complete before continuing, but the wait is sequential rather than concurrent.

Inside a For Each Loop

Branch and Merge nodes can be placed inside For Each loops. In this case, the branch-merge pattern executes once per loop iteration, with each iteration fanning out and reconverging independently.

Async Execution (Standalone)

In a standard async workflow (the most common case), each outgoing path from a Branch node is enqueued as a separate background job. These jobs run in true parallel across available workers. The Merge node's synchronization counter is managed atomically to handle the concurrent arrivals safely.

---

Data Center Output

Neither the Branch nor the Merge node produces meaningful data for downstream nodes. They do not have executionData (no API response or computed data). They do produce standard executionDetails metadata (status, scheduled-at, completed-at timestamps), but these are rarely useful in practice since these nodes are purely structural.

Downstream nodes should reference the outputs of the nodes inside the parallel branches (e.g., the Action nodes or Function nodes) rather than the Branch or Merge nodes themselves.

---

Validation Rules

The workflow builder validates Branch and Merge nodes at publish time:

Branch Node:

• Must have exactly 1 incoming edge. More than one incoming edge triggers an edge mismatch error.
• Must have at least 1 outgoing edge. Zero outgoing edges triggers a missing edge error.
• Must not be abandoned (zero incoming and zero outgoing edges).

Merge Node:

• Must have at least 1 incoming edge. Zero incoming edges triggers a missing edge error.
• Must have exactly 1 outgoing edge. More than one outgoing edge triggers an edge mismatch error.
• Must not be abandoned (zero incoming and zero outgoing edges).

Cycle Restriction:

• A Branch node and a Merge node must not appear together in the same cycle. If the workflow graph contains a cycle that includes both a Branch and a Merge node, the validator flags it as an "irrelevant cyclic execution" error and blocks publication.

---

Best Practices

• Use parallel branches for independent steps only. If Step B depends on the output of Step A, they should be sequential, not parallel. Parallel paths should not depend on each other's outputs.
• Keep parallel branches balanced in execution time when possible. The Merge node waits for the slowest path. If one branch takes 5 seconds and another takes 5 minutes, the downstream step won't start until the 5-minute branch completes.
• Avoid placing long-running human steps in parallel branches unless you intentionally want to block the Merge node. For example, putting an Approval node in one branch means the Merge won't release until the approval is granted — even if all other branches completed instantly.
• Use nested Branch-Merge pairs for complex parallelism. If one parallel branch itself needs internal parallelism, you can nest a second Branch-Merge pair inside it.
• Remember that both nodes are invisible to end users. They won't see "Branch" or "Merge" in their progress tracker — they'll only see the meaningful steps inside the parallel paths.
• Don't create cycles between Branch and Merge nodes. The validator will block publication if a cycle contains both node types.
• In sync blocks, parallelism is sequential. If you need true concurrent execution, use Branch and Merge outside of sync blocks in the async portion of the workflow.