Skip to main content
Coming Soon — Condition evaluation is currently in V1. The branching logic is defined in the data model, but conditions always take the else branch during execution. The condition types and configuration documented below represent the planned behavior.
Condition steps let you branch your journey based on contact behavior or attributes. Send different messages to different segments.

​
Percentage Split

In addition to condition-based branching, you can use Percentage Split steps for randomized A/B testing within journeys: 
Percentage Split:
    ↓ 50% (Path A)      ↓ 50% (Path B)
   Branch A              Branch B
Configure N branches with custom percentages and labels. Contacts are randomly assigned based on the configured split.

​
How Conditions Work

A condition step evaluates a rule and routes contacts to different branches: 
Condition: Has clicked?
    ↓ Yes (true)      ↓ No (false)
   Branch A          Branch B

​
Condition Types

​
clicked

Did the contact click any link since enrolling? 
conditionType: clicked
thenStepId: "step_4a"
elseStepId: "step_4b"
Use case: Reward engaged users, follow up with non-clickers.

​
clicked_step

Did the contact click a link from a specific step in this journey? 
conditionType: clicked_step
stepId: "step_1"
thenStepId: "step_4a"
elseStepId: "step_4b"
Use case: Different follow-up based on whether they clicked the welcome offer specifically.

​
custom_field

Does a custom field on the contact match a condition? 
conditionType: custom_field
field: state
operator: eq
value: "California"
thenStepId: "step_2a"
elseStepId: "step_2b"
Use case: Region-specific messaging, segmentation by contact attributes.

​
Setting Up a Condition

  1. Add a condition step
  2. Set the conditionType
  3. Configure any type-specific fields (e.g., field, operator, value for custom_field)
  4. Set thenStepId — the step to go to when the condition is true
  5. Set elseStepId — the step to go to when the condition is false
  6. Merge branches or exit separately

​
Visual Example

Step 1: Send "Welcome"
    ↓
Step 2: Wait 3 days
    ↓
Step 3: Condition - Clicked welcome offer?
    ↓ Yes                    ↓ No
Step 4a: Send "Thanks!"   Step 4b: Send "Don't miss out"
    ↓                         ↓
Step 5a: Exit             Step 5b: Wait 2 days
                              ↓
                          Step 6b: Send "Last chance"
                              ↓
                          Step 7b: Exit

​
Multiple Conditions

Chain conditions for complex logic: 
Condition 1: Clicked?
    ↓ Yes        ↓ No
   Exit       Condition 2: State = CA?
                ↓ Yes        ↓ No
              Send CA offer  Send General offer

​
Condition Operators

These operators are available for custom_field conditions:
OperatorMeaningExample
eqEqualsstate eq “CA”
neNot equalsplan ne “premium”
inValue in liststate in [“CA”, “NY”, “TX”]
not_inValue not in liststate not_in [“HI”, “AK”]
existsField existsphone_number exists
containsContains substringemail contains “@gmail”

​
Best Practices

Every branch doubles complexity. Keep journeys manageable with 1-2 conditions.
Every branch should eventually reach an exit step. Avoid infinite loops.
Ensure both Yes and No branches work correctly before activating.
What if the condition can’t be evaluated? (Missing data, etc.)

​
Examples

​
Clicker vs Non-Clicker

Wait 2 days → Condition: Clicked?
→ Yes: Exit (already engaged)
→ No: Send reminder → Wait 2 days → Send final offer → Exit

​
VIP Treatment

Condition: Lifetime revenue > $500
→ Yes: Send VIP welcome → Exit
→ No: Send standard welcome → Continue normal journey

​
Geographic Targeting

Condition: State = California
→ Yes: Send CA-specific offer
→ No: Send general offer

​
Merging Branches

Sometimes branches should reconverge: 
Condition
  ↓ Yes      ↓ No
Step A     Step B
    ↘    ↙
   Merged Step C
        ↓
      Exit
Configure by pointing both branches to the same next step.

​
Next Steps

Wait Steps

Configure timing

Examples

Common journey patterns