---
title: Condition Step
description: Route notifications into different branches based on conditions
---

The condition step evaluates rules against recipient data, actor data, or custom payload and routes each notification down the matching branch. This lets you send different notifications — or skip notifications entirely — based on who the recipient is or what triggered the flow.

## How It Works

A condition step contains one or more **branches**. Each branch has a set of conditions that are evaluated at runtime. The notification follows the first branch whose conditions match, or falls through to the default branch if no conditions match.

```
Trigger → Condition
              ├─ Premium users → Email + Push → End
              ├─ Trial users → Email → End
              └─ Default → End
```

## Configuration

Each condition step has:

- **Branches** — Named paths that notifications can follow (e.g., "Premium Users", "Trial Users")
- **Conditions** — Rules on each branch that determine which notifications follow that path
- **Default branch** — A catch-all branch for notifications that don't match any other branch's conditions

### Branch Conditions

Each branch can have one or more condition groups. Within a group, conditions are combined with **AND** or **OR** logic.

A condition consists of:

| Field | Description |
|-------|-------------|
| Property | The data field to evaluate (e.g., `recipient.plan`, `data.amount`) |
| Operator | How to compare the value |
| Value | The expected value to compare against |

### Operators

| Operator | Description |
|----------|-------------|
| Equal to | Exact match |
| Not equal to | Does not match |
| Greater than | Numeric comparison |
| Less than | Numeric comparison |
| Greater than or equal to | Numeric comparison |
| Less than or equal to | Numeric comparison |
| Contains | String contains substring |
| Does not contain | String does not contain substring |
| Starts with | String starts with prefix |
| Ends with | String ends with suffix |
| Is empty | Field is null or empty |
| Is not empty | Field has a value |

## Use Cases

**Notification preferences**

Route based on the recipient's preferred channel:

```
Trigger → Condition
              ├─ Prefers email → Email → End
              ├─ Prefers SMS → SMS → End
              └─ Default → Push → End
```

**Plan-based content**

Send different content to different user tiers:

```
Trigger → Condition
              ├─ Enterprise → Email (detailed report) → End
              ├─ Pro → Email (summary) → End
              └─ Free → Email (upgrade CTA) → End
```

**Locale-based routing**

Send notifications in the recipient's language:

```
Trigger → Condition
              ├─ locale = "es" → Email (Spanish) → End
              ├─ locale = "fr" → Email (French) → End
              └─ Default → Email (English) → End
```

**Data-driven routing**

Route based on the custom data payload:

```
Trigger → Condition
              ├─ data.priority = "urgent" → Push + SMS → End
              └─ Default → Email → End
```

## Nesting

Condition steps can appear anywhere in a flow, including inside another condition's branch. This lets you build complex routing logic:

```
Trigger → Condition (region)
              ├─ US → Condition (plan)
              │         ├─ Premium → Email + SMS → End
              │         └─ Default → Email → End
              └─ EU → Email (GDPR-compliant) → End
```

## Condition Steps vs Step Conditions

Notiflows has two different condition features:

- **Condition steps** (this page) — Route the flow into branches. Every notification goes down exactly one branch.
- **Step conditions** — A gate on an individual step. If the conditions aren't met, that single step is skipped and execution continues to the next step.

Step conditions are configured per-step in the step settings panel. Condition steps are a dedicated step type that you add to the canvas.