Journey Conditions

Rolling out now — until condition evaluation is enabled for your account, every condition takes the If False branch.Click conditions look at messages sent by this journey to this contact during the current enrollment — clicks on older campaigns, other journeys, or a previous run of the same journey don’t count. If a condition can’t be evaluated (missing configuration, unavailable data), the contact takes the If False branch.

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 a link from any message this journey sent them 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 (during the current enrollment)?

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

Add a condition step
Set the conditionType
Configure any type-specific fields (e.g., field, operator, value for custom_field)
Set thenStepId — the step to go to when the condition is true
Set elseStepId — the step to go to when the condition is false
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:

Operator	Meaning	Example
`eq`	Equals (exact, case-sensitive)	state eq “CA”
`ne`	Not equals (exact, case-sensitive; also true when the field is missing)	plan ne “premium”
`exists`	Field is present and not null	phone_number exists
`contains`	Contains substring (case-insensitive)	email contains “@gmail”

eq and ne require a Value; a condition saved without one is rejected.

Best Practices

Don't over-branch

Every branch doubles complexity. Keep journeys manageable with 1-2 conditions.

Always have an exit

Every branch should eventually reach an exit step. Avoid infinite loops.

Test both paths

Ensure both Yes and No branches work correctly before activating.

Consider edge cases

A condition that can’t be evaluated — missing configuration, a “Step to Check” that was deleted, or unavailable click data — routes the contact down the If False branch. The same applies to a contact whose earlier send was skipped (quiet hours, cooldowns, suppression): they never received the message, so a click condition sees no click and routes them to If False.

Give clicks time to happen

Put a Wait step before a click condition and make it generous (15–60 minutes or more). The wait starts when the message is handed off for delivery, so carrier latency and human reading time both eat into short windows — a 2-minute wait will classify many real clickers as non-clickers.

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: plan eq "vip"
→ 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

Getting Started

Guides

Account & Team

Integrations

Resources

Percentage Split

How Conditions Work

Condition Types

`clicked`

`clicked_step`

`custom_field`

Setting Up a Condition

Visual Example

Multiple Conditions

Condition Operators

Best Practices

Examples

Clicker vs Non-Clicker

VIP Treatment

Geographic Targeting

Merging Branches

Next Steps

Wait Steps

Examples

​Percentage Split

​How Conditions Work

​Condition Types

​clicked

​clicked_step

​custom_field

​Setting Up a Condition

​Visual Example

​Multiple Conditions

​Condition Operators

​Best Practices

​Examples

​Clicker vs Non-Clicker

​VIP Treatment

​Geographic Targeting

​Merging Branches

​Next Steps

Wait Steps

Examples

Percentage Split

How Conditions Work

Condition Types

`clicked`

`clicked_step`

`custom_field`

Setting Up a Condition

Visual Example

Multiple Conditions

Condition Operators

Best Practices

Examples

Clicker vs Non-Clicker

VIP Treatment

Geographic Targeting

Merging Branches

Next Steps