> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tracklysms.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Journey Conditions
> Add branching logic to personalize journey paths
**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?
```yaml theme={null}
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)?
```yaml theme={null}
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?
```yaml theme={null}
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:
| 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
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.
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.
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
Configure timing
Common journey patterns