Journey Conditions

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.

`message_status`

Does the latest message this journey actually sent to the contact during their current enrollment have the selected status?

conditionType: message_status
status: delivered
thenStepId: "step_delivered"
elseStepId: "step_not_delivered"

Choose exactly one of three outcomes:

Outcome	What it means
`delivered`	The carrier confirmed the message reached the handset.
`undelivered`	The carrier or provider refused it — either a failure receipt came back, or the send was rejected outright when we handed it over.
`dropped`	We never handed it to a carrier at all — the send was stopped by a pre-flight check or failed before hand-off.

Between them these cover every way a message can finish, so a delivery condition always has an answer to branch on. The condition checks the latest message from the current enrollment; it is not tied to a fixed source step. If that message’s outcome matches the one you selected, the contact takes the If True branch. A different outcome, or no eligible message, takes the If False branch. Either branch can lead to an Exit or another existing journey step. Message Status is available for journeys only. Click Triggers don’t support this condition type.

`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

Delivery Status Follow-Up

Send "Welcome" → Wait 15 minutes → Condition: Message Status = delivered?
→ If True: Continue welcome journey → Exit
→ If False: Send alternate follow-up → Exit

The Wait controls when the status is observed, but it is not required or changed by the condition. Set a wait window on the condition itself instead — see below — and the Wait becomes unnecessary.

Waiting for an Answer

Both delivery receipts and link taps arrive after the send: a carrier receipt takes seconds to minutes, a non-delivery can take up to 48 hours, and a tap happens over hours. A condition with no wait window checks once the moment the contact arrives, so it can branch on an answer that simply hasn’t landed yet. Set Wait up to on the condition to give it a window:

conditionType: clicked
waitFor:
  duration: 6
  unit: hours
thenStepId: "step_clicked"
elseStepId: "step_no_click"

Units are minutes, hours, or days, from a minimum of 30 minutes up to a maximum of 7 days. The minimum is twice how often a waiting condition re-checks, so every window gets at least one look before its deadline; a shorter one would reach the deadline before it ever checked again. Leave the field empty and the condition behaves exactly as before: evaluate once, branch immediately. While waiting, the contact stays active in the journey and the condition re-checks periodically. The moment the answer arrives the contact takes the If True branch — a fast answer moves fast, it does not sit out the full window. If the window runs out with no answer, the contact takes the If False branch. Time the journey spends paused doesn’t count against the window, so resuming a paused journey doesn’t dump everyone down the False branch. Wait windows are available on click and delivery conditions. Custom-field conditions don’t support them, because custom-field data doesn’t change while a contact is parked — the window would never resolve. One thing worth deciding deliberately: a delivery receipt eventually gives a definitive answer, but a tap never does. A contact who hasn’t tapped by hour 72 might still tap on day five. The False branch on a click window means “hasn’t clicked yet”, not “won’t click” — you’re choosing where to cut the tail. The journey view shows how many contacts are currently waiting at each windowed condition, so a step with a long window doesn’t look broken.

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

AI Agents & MCP

Guides

Account & Team

Integrations

Resources

Percentage Split

How Conditions Work

Condition Types

`clicked`

`clicked_step`

`message_status`

`custom_field`

Setting Up a Condition

Visual Example

Multiple Conditions

Condition Operators

Best Practices

Examples

Clicker vs Non-Clicker

VIP Treatment

Geographic Targeting

Delivery Status Follow-Up

Waiting for an Answer

Merging Branches

Next Steps

Wait Steps

Examples

​Percentage Split

​How Conditions Work

​Condition Types

​clicked

​clicked_step

​message_status

​custom_field

​Setting Up a Condition

​Visual Example

​Multiple Conditions

​Condition Operators

​Best Practices

​Examples

​Clicker vs Non-Clicker

​VIP Treatment

​Geographic Targeting

​Delivery Status Follow-Up

​Waiting for an Answer

​Merging Branches

​Next Steps

Wait Steps

Examples

Percentage Split

How Conditions Work

Condition Types

`clicked`

`clicked_step`

`message_status`

`custom_field`

Setting Up a Condition

Visual Example

Multiple Conditions

Condition Operators

Best Practices

Examples

Clicker vs Non-Clicker

VIP Treatment

Geographic Targeting

Delivery Status Follow-Up

Waiting for an Answer

Merging Branches

Next Steps