How to Use Conditional Branching

Branch nodes let you split a flow into different paths based on a condition. When the condition evaluates to true, execution follows one path. When it evaluates to false, execution follows another. This is how you add if/else logic to your workflows.

Prerequisites

• Familiarity with the flow builder (see Build a Flow)
• Basic knowledge of Vex expressions (see Use Expressions)

Adding a Branch Node

Step 1: Add the Node

In the flow builder, click the + button below an existing node and search for Branch in the activity picker. It is in the Core category.

Step 2: Place the Node

Click Branch to add it to the canvas. It appears connected to the previous node, just like any other action.

Here’s an interactive branching flow – press Run to see the True path execute:

Understanding the Branch Node

A Branch node has three handles:

Configuring the Condition

Step 1: Open the Settings Panel

Double-click the Branch node to open its settings panel on the left side of the canvas.

Step 2: Write the Condition Expression

The settings panel has a single key field: Condition. This field accepts a Vex expression that must evaluate to true or false.

Writing Conditions

Use any expression that produces a boolean result:

Simple comparisons

{{ output("trigger").rssi > -50 }}

{{ variables.count >= 10 }}

{{ output("trigger").epc == "3034ABC123" }}

String checks

{{ output("trigger").epc | string.starts_with "3034" }}

{{ variables.status != "processed" }}

Null and empty checks

{{ output("airtableGet1").records | array.size > 0 }}

{{ variables.email && variables.email != "" }}

Compound conditions

{{ output("trigger").rssi > -50 && output("trigger").epc | string.starts_with "3034" }}

{{ variables.retryCount < 3 || variables.forceRetry == true }}

Connecting the True and False Paths

After configuring the condition, connect each output handle to the nodes that should execute in that case.

Step 1: Connect the True Path

Click and drag from the True (green) handle to the input handle of the node that should execute when the condition is true.

Step 2: Connect the False Path

Click and drag from the False (red) handle to the input handle of the node that should execute when the condition is false.

Optional Paths

You do not have to connect both handles. If only one path has nodes connected, the flow simply ends for the other case. For example, you might only connect the True path if you want to take action when the condition is met and do nothing otherwise.

Merging Paths

After branching, you may want both paths to converge back to a shared step (e.g., a final log or notification). To do this:

1. Connect the last node of the True path to the shared node’s input handle
2. Connect the last node of the False path to the same shared node’s input handle

The shared node executes once whichever path completes first (or both, depending on your flow structure).

Nested Branching

You can place a Branch node inside a branch path to create nested conditions. This lets you handle multiple cases:

Is RSSI strong?
├── True: Is EPC in allowed list?
│   ├── True: Process tag
│   └── False: Log unauthorized tag
└── False: Ignore weak signal

To build this:

1. Add the first Branch node with the RSSI condition
2. Connect its True handle to a second Branch node with the EPC condition
3. Connect the second Branch’s True and False handles to the appropriate action nodes
4. Connect the first Branch’s False handle to a Log node

Tip: Keep nesting to two or three levels at most. If you need more, consider breaking the logic into separate flows or using Set Variable nodes to precompute boolean flags.

Error Handling with Error Handles

Every node (not just Branch nodes) has an error handle — a red circle on the bottom-right. When a node encounters an error during execution, the flow follows the error handle instead of the normal output.

Connecting an Error Path

1. Hover over the error handle (red circle) on any node
2. Click and drag to the input handle of an error-handling node (e.g., a Log node to record the error, or an HTTP Request to send an alert)
3. Release to create the error edge

What Happens Without an Error Handle

If a node fails and its error handle is not connected, the flow run is marked as Failed and execution stops at that node. The run log shows the error details.

Combining Branching and Error Handling

A common pattern is to use a Branch node after a risky operation to check whether it succeeded:

1. HTTP Request node calls an external API
2. Branch node checks {{ output("httpRequest1").statusCode == 200 }}
3. True path — process the response
4. False path — log the failure and send an alert

You can also connect the HTTP Request’s error handle directly to a recovery node for cases where the request fails entirely (network error, timeout).

Examples

Route Based on Tag Data

Scenario: An RFID reader reads tags. Tags starting with “3034” are inventory items and should be logged to Airtable. All other tags are ignored.

1. Device Event trigger (Tag Read)
2. Branch node — Condition: {{ output("trigger").epc | string.starts_with "3034" }}
3. True path — Airtable “Create Record” node to log the tag
4. False path — Log node: “Ignoring non-inventory tag”

Handle Missing Data

Scenario: A flow looks up a customer record in a database. If the record exists, update it. If not, create a new one.

1. Database Query node — SELECT * FROM customers WHERE tag_id = '{{ output("trigger").epc }}'
2. Branch node — Condition: {{ output("dbQuery1").rows | array.size > 0 }}
3. True path — Database Query “UPDATE” to update the existing record
4. False path — Database Query “INSERT” to create a new record

Multi-Level Classification

Scenario: Classify tags by signal strength — strong, medium, or weak.

1. Device Event trigger (Tag Read)
2. Branch node #1 — Condition: {{ output("trigger").rssi > -30 }}
3. True path — Set Variable: signalClass = "strong"
4. False path — Branch node #2 — Condition: {{ output("trigger").rssi > -60 }}
5. True path — Set Variable: signalClass = "medium"
6. False path — Set Variable: signalClass = "weak"
7. All three Set Variable nodes merge into a shared Log node: Tag {{ output("trigger").epc }} classified as {{ variables.signalClass }}

Retry with Error Handling

Scenario: Call an external API and retry once on failure.

1. HTTP Request node #1 — call the API
2. Error handle on node #1 connects to Set Variable: retryCount = 1
3. HTTP Request node #2 — retry the same call
4. Error handle on node #2 connects to Log: “API call failed after retry”
5. Normal output of both HTTP Request nodes merges into the next step

Troubleshooting

Branch always takes the same path: Check the condition expression in the run log. The condition value is logged for each run. If it always evaluates to the same result, the expression may not be referencing the right data. Use a Log node before the Branch to print the values you are comparing.

Condition throws an error instead of returning true/false: Make sure the expression produces a boolean. Expressions like {{ output("trigger").epc }} return a string, not a boolean. Compare it to something: {{ output("trigger").epc != "" }}.

Both paths seem to execute: This can happen if a node receives connections from both the True and False paths (i.e., it is a merge point). The node will execute once for whichever path reaches it. If both paths reach it, it may execute twice depending on the flow structure.

Next Steps

• Use Expressions — Learn more about the Vex expression syntax
• Build a Flow — Return to the full flow building guide
• Actions Reference — See what outputs each node type produces