Skip to main content

​
Multi-Split Branch

The Multi-Split Branch step creates multiple conditional paths in your workflow. Each branch has its own label, conditions, and execution path, allowing you to route workflows through different paths based on complex logic.

​
Overview

Multi-Split Branch steps are ideal for:
  • Routing to multiple paths based on different conditions
  • Implementing switch/case-like logic
  • Creating workflows with 3+ possible outcomes
  • Handling multiple scenarios in a single step

​
Configuration

When you add a Multi-Split Branch step, you’ll configure multiple branches, each with:

​
Branch Label

A descriptive name for the branch path (e.g., “Premium Users”, “Standard Users”, “Trial Users”). This label appears in the workflow canvas and helps identify the execution path.

​
Logical Operator

Choose how conditions within each branch are combined:
  • AND: All conditions in the branch must be true
  • OR: At least one condition in the branch must be true

​
Conditions

Each branch can have one or more condition rules, configured the same way as True/False Branch conditions:
  • Field: The workflow variable to evaluate
  • Operator: The comparison operator (Equal, Contains, Greater Than, etc.)
  • Comparison Target: What to compare against (static value, dynamic field, or relative time)

​
Execution Flow

When a Multi-Split Branch executes:
  1. Conditions are evaluated for each branch in order
  2. The first branch with matching conditions is selected
  3. Execution follows the path for that branch
  4. If no branches match, execution can follow a default path (if configured)
Trigger
  ↓
Multi-Split Branch
  ├─ Branch 1 (user.type === "premium") → Path A
  ├─ Branch 2 (user.type === "standard") → Path B
  └─ Branch 3 (user.type === "trial") → Path C

​
Example Use Cases

​
User Tier Routing

Route users to different onboarding flows based on their tier: 
Trigger (Event: User Signs Up)
  ↓
Multi-Split Branch
  ├─ Premium (user.tier === "premium" AND user.verified === true)
  │   └─ Send Email (Premium Onboarding)
  ├─ Standard (user.tier === "standard")
  │   └─ Send Email (Standard Onboarding)
  └─ Trial (user.tier === "trial" OR user.tier === "free")
      └─ Send Email (Trial Onboarding)

​
Order Status Handling

Handle different order statuses with appropriate actions: 
Trigger (Event: Order Status Changed)
  ↓
Multi-Split Branch
  ├─ High Value (order.amount > 1000)
  │   └─ Send Email (High Value Order Notification)
  ├─ Medium Value (order.amount > 100 AND order.amount <= 1000)
  │   └─ HTTP Request (Update Inventory)
  └─ Low Value (order.amount <= 100)
      └─ Send Email (Order Confirmation)

​
Geographic Routing

Route workflows based on user location: 
Trigger (Event: Support Ticket Created)
  ↓
Multi-Split Branch
  ├─ North America (user.region === "US" OR user.region === "CA")
  │   └─ HTTP Request (Assign to NA Team)
  ├─ Europe (user.region === "UK" OR user.region === "DE" OR user.region === "FR")
  │   └─ HTTP Request (Assign to EU Team)
  └─ Asia Pacific (user.region === "IN" OR user.region === "AU")
      └─ HTTP Request (Assign to APAC Team)

​
Branch Evaluation Order

Branches are evaluated in the order they appear in the configuration. The first branch with matching conditions is selected, and subsequent branches are not evaluated.
Order matters! Place more specific conditions first, and more general conditions later. If a general condition comes first, it may match before more specific conditions are evaluated.

​
Default Path

If no branches match their conditions, you can configure a default path that execution will follow. This is useful for handling edge cases or unexpected data.
Always include a default path or a catch-all branch to handle cases where none of your conditions match. This prevents workflows from getting stuck.

​
Best Practices

Place the most specific conditions first, and more general conditions later. This ensures the correct branch is selected.
Choose clear, descriptive branch labels that make it obvious what each path represents. This improves workflow readability.
If a branch has many conditions, consider using AND logic for validation and OR logic for alternatives. Very complex conditions may be better split into multiple steps.
Create test scenarios that trigger each branch to ensure your workflow behaves correctly in all cases.
Always configure a default path or catch-all branch to handle unexpected data or edge cases.
If multiple branches could match the same data, only the first matching branch will be selected. Ensure your conditions are mutually exclusive or ordered correctly.