Branching with Filter & Path

Automations run steps sequentially by default. To create conditional logic—where different actions run based on lead data—you use Filter and Path actions. These let you branch your automation like an if/else in code.

Filter Action

The Filter action evaluates a condition. If the condition is true, the next step runs. If it's false, the branch stops and no further steps in that branch execute.

When to Use Filter

• Single branch – "Only send this email if the lead has an email address."
• Guard clause – "Stop here if the lead is marked as spam."
• Pre-check – "Only run the webhook if the lead source is 'Website'."

Example

1. Trigger: On lead creation
2. Filter: lead.email is not empty
3. Email: Send welcome email

If lead.email is empty, the automation stops before the Email action.

Path Action

The Path action splits the automation into multiple branches. Each path has its own condition. Only the branches whose conditions are true will run. Paths can run in parallel (e.g., send different emails based on lead source).

When to Use Path

• Multiple outcomes – "If source = Website, send email A; if source = API, send webhook B."
• Segmentation – Route leads to different assignees or stages based on criteria.
• A/B-style flows – Different messaging for different segments.

Example

1. Trigger: On lead creation
2. Path:
   - Path A: lead.source = "Website"  → Email (welcome)
   - Path B: lead.source = "API"      → Webhook (sync to CRM)
   - Path C: (default)                → Assign User (manual review)

Filter vs Path

Best Practices

• Order conditions – In a Path, put the most specific conditions first.
• Default path – Use a catch-all path for leads that don't match any condition.
• Avoid overlap – Ensure Path conditions don't overlap unless you intend multiple branches to run.

Next Steps

• Reference all actions
• Use variables in conditions
• Debug branching with automation logs