How it works
- Define a condition using an expression
- The condition is evaluated to
trueorfalse - Execution continues down the corresponding branch
- Each branch can have its own sequence of actions
Configuration
| Property | Description |
|---|---|
| Condition | An expression that evaluates to true or false |
Writing conditions
Comparison operators
| Operator | Meaning | Example |
|---|---|---|
== | Equals | {{nodes.start.status == "active"}} |
!= | Not equals | {{nodes.start.tier != "free"}} |
> | Greater than | {{nodes.score.value > 50}} |
>= | Greater than or equal | {{nodes.enrich.employees >= 100}} |
< | Less than | {{nodes.start.days_remaining < 7}} |
<= | Less than or equal | {{nodes.score.value <= 30}} |
Logical operators
Combine multiple conditions:| Operator | Meaning | Example |
|---|---|---|
&& | AND | {{nodes.score.value > 50 && nodes.enrich.employees > 100}} |
|| | OR | {{nodes.start.source == "inbound" || nodes.score.value > 80}} |
! | NOT | {{!nodes.start.is_competitor}} |
Checking for values
| Check | Expression |
|---|---|
| Value exists | {{nodes.enrich.email}} |
| Value is null/empty | {{!nodes.enrich.email}} |
| Array has items | {{nodes.search.results.length > 0}} |
| String contains | {{nodes.enrich.industry.includes("Tech")}} |
| String starts with | {{nodes.start.email.startsWith("sales@")}} |
Common use cases
Qualify leads
Route based on lead score:Check enrichment results
Handle cases where enrichment found data vs. didn’t:Handle different customer tiers
Route enterprise vs. standard customers:Validate required data
Check if required fields are present:Check previous action success
Route based on whether a previous action succeeded:Branch vs. Switch
Choose the right action for your logic:| Use Branch when… | Use Switch when… |
|---|---|
| Single yes/no decision | Multiple possible values |
| Binary condition | More than two paths needed |
| Simple true/false check | Matching against specific values |
- “Is the score above 50?” → Branch
- “Which tier is this lead: A, B, C, or D?” → Switch
Branch vs. Filter
Both can stop execution, but they work differently:| Feature | Branch | Filter |
|---|---|---|
| Paths | Two paths (Yes and No) | Single path (continues or stops) |
| Use case | Do different things based on result | Stop processing if condition fails |
| Flexibility | Handle both outcomes | Only handles the “pass” case |
Handling both branches
Always consider what should happen on each path:Yes branch actions
- Continue normal processing
- Send notifications
- Update CRM records
- Add to campaigns
No branch actions
- Log the skip reason
- Send to different workflow
- Update status to “not qualified”
- Do nothing (explicitly)
Best practices
Keep conditions readable
Keep conditions readable
For complex conditions, use a Variables node first to compute a boolean,
then branch on that variable:
{{nodes.vars.is_qualified}}Handle empty values gracefully
Handle empty values gracefully
Check that values exist before comparing:
{{nodes.enrich.score && nodes.enrich.score > 50}}Document your branches
Document your branches
Name your Branch nodes descriptively: “Is Qualified Lead?” is better than
“Branch 1”.
Consider the No path
Consider the No path
Don’t ignore the No branch. Even if you do nothing, consider logging or
tracking why the condition failed.
Example: Lead qualification routing
A workflow that routes leads based on qualification: 1. Enrich → Get company data 2. Score → Calculate lead score 3. Branch: Is qualified?- Condition:
{{nodes.score.value >= 50 && nodes.enrich.employees >= 50}}
- 4a. Allocate → Assign to sales rep
- 5a. Create HubSpot Contact → Add to CRM
- 6a. Send Slack Notification → Alert the team
- 4b. Add to Nurture Campaign → Long-term follow-up
- 5b. Update Custom Column → Mark as “nurturing”

