Skip to main content

Node: Join

The Join node is responsible for synchronizing parallel branches within a workflow. It waits for the convergence of all ongoing branches before allowing the flow to continue to the next step. Without it, branches running in parallel never meet again, and the rest of the process cannot proceed in a controlled manner.

Think of Join as a synchronization barrier: no branch passes alone. The flow only advances when the last parallel path also arrives at the join node.

When to use​

Use the Join node whenever your workflow has split the flow into more than one simultaneous path (fork) and you need all those paths to end before continuing.

Practical examples of situations where Join is needed:

  • Send an email to the requester and at the same time record the data in a spreadsheet, and only confirm process completion when both actions are done.
  • Trigger notifications for different teams in parallel and, after all are sent, update the instance status.
  • Request approvals from different approvers in separate branches and wait for all responses to arrive before making a final decision.

Whenever you create a fork in the canvas (that is, connect multiple outputs of a node to different nodes), you will need a Join to bring those branches together into a single flow.

Understanding Parallel Branches (Fork)​

A fork occurs when, from a single node, multiple transitions are activated at the same time. Each of these transitions starts an independent branch, which executes its own nodes without waiting for the others.

Branches are truly independent: if one of them gets stuck at an approval node waiting for a response, the others continue executing normally alongside it.

Nodes that can create a fork​

Any node that has more than one output connected to different nodes can create a fork. The most common cases are:

  • Approval: each configured outcome (for example, "Approved", "Rejected", "Review") is a separate output. If you connect two of these outcomes to different nodes that then need to come together, you will have a fork.
  • If/Else: the True and False outputs can also create branches that need to converge.
  • Webhook Out: the Success and Error outputs can generate parallel branches.
  • Send Slack Message / Send Microsoft Teams Message: success and error outputs.
  • Any node where you manually drag multiple connections from the same output to different nodes that then come together in the canvas.
Parallel branches execute independently

Each branch of a fork runs autonomously. They do not share state with each other. The only planned meeting point is the Join node, which knows how many branches to expect and waits for all of them before proceeding.

Configuration​

The Join node is intentionally simple: it has no functional configurations beyond the label, which serves only for visual identification in the canvas.

The number of inputs the Join will wait for is not configured manually. The workflow editor calculates this number automatically based on the connections drawn in the canvas. Each arrow that arrives at the Join node represents a branch it will need to wait for.

This means:

  1. Connect all parallel paths to the Join node in the canvas.
  2. The system automatically detects how many branches arrive at it.
  3. There is no numeric field to fill in.
The number of connections must reflect the actual fork

The Join node waits for exactly the number of branches that arrive at it in the canvas. If you create a fork with three paths and connect only two of them to the Join, the third will never arrive and the Join will never advance. Make sure all branches of the fork are connected to the Join.

Execution Behavior​

During the execution of a workflow instance, the Join node behaves as follows:

  1. The first branch that arrives at the Join is received and the node enters wait mode.
  2. The instance status is updated to indicate that the flow is waiting for the remaining branches to converge.
  3. As each additional branch arrives, the Join records its arrival.
  4. When the last expected branch arrives, the Join releases the flow and the next node connected to the Join output is executed.

What happens if a branch fails​

If any of the parallel branches encounters an unhandled error during its execution, the Join records the failure. The flow does not advance and the instance is marked with Failed status. This ensures the process does not continue in an inconsistent state, with partially processed data.

Example Flow with Join​

Below is a textual example of how a workflow with fork and Join works in practice:

Scenario: When receiving a new form response, the workflow should send a confirmation email to the requester and export the data to a Google Sheets spreadsheet at the same time. Only after both actions complete should the instance status be updated.

[FORM_RESPONSE_TRIGGER]
        |
        v
    [Node A: If/Else]  ← checks if form is complete
        |
    (True)
        |
       FORK ──────────────────────────────────┐
        |                                     |
        v                                     v
[Branch 1: Send email]          [Branch 2: Export to spreadsheet]
  Sends confirmation               (Google Sheets or Microsoft Excel)
        |                                     |
        └──────────────┬──────────────────────┘
                       v
                    [JOIN]
                       |
                       v
              [Set Status]
           Status: "Processing completed"

In this example:

  • The If/Else node evaluates whether the response is complete. If yes, the flow proceeds to the fork.
  • Branch 1 executes the confirmation email send.
  • Branch 2 executes the data export to Google Sheets.
  • Both branches run in parallel, independently.
  • The Join node waits for both branches to finish.
  • Only after the Join does the Set Status node execute and update the instance status.

Best Practices​

  • Plan the fork before adding the Join. Visually identify all paths coming from the fork and make sure each one reaches the Join node.
  • Avoid "open" Joins. Never leave a Join with fewer connections than the actual number of branches. The flow will be stuck indefinitely waiting for branches that will never arrive.
  • Use the label for documentation. Even being simple, name the Join node with something descriptive like "Waits for email and spreadsheet" to make the workflow easier to read by other team members.
  • Handle errors in branches. If a branch can fail (for example, a webhook call or external service integration), consider handling it before the Join to avoid the entire instance being marked as failed.
Join is required to re-synchronize parallel branches

Without the Join node, parallel branches never converge and the flow does not know when it can proceed. Whenever you create a fork in the canvas, add a Join at the end of the branches to ensure the process continues in an orderly and predictable manner.