> For the complete documentation index, see [llms.txt](https://docs.sortment.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sortment.com/journeys/journey-components/flow-control.md).
# Flow Control
Flow control blocks allow you to determine how users progress through a Journey based on attributes, behaviours, or experimentation logic. These steps dynamically shape user paths, enabling precise audience targeting and optimisation.
There are three types of flow control components:
* Filter
* Split
* Experiment
***
## Filter
Use a **filter** step to evaluate users based on static or dynamic conditions. This step creates two distinct branches:
* **Qualified** – users who meet the filter criteria
* **Everyone else** – users who do not meet the criteria
#### Example use case
Filter users who:
* are on the “Premium” subscription plan **AND**
* have triggered the `app_opened` event within the past 7 days.
These users will continue down the **qualified** path, while others will be routed to **Everyone else**.
#### Configuration
1. **User properties**
Pick an existing audience or create one using related tables, events, and traits. (e.g., `subscription_plan = "Premium"`, `signup_date > 01-01-2025`, `Total Order Count > 25`, etc.).
2. **Journey activity**
Toggle on to filter users based on journey-related activity or dynamic behaviour (e.g., "has opened the app in the last 7 days").
***
## Split
A **split** step segments users into multiple branches based on the value of a selected property. This is commonly used to customise the experience for different user segments.
#### Configuration
1. **Split on:** Select a property to evaluate (e.g., `rating`, `region`, or `driver_status`).
2. **Define paths:** Create one or more conditions to group users into specific paths:
* **Path 1**: `rating` is less than 2
* **Path 2**: `rating` is between 2 and 4
* **Path 3**: `rating` is greater than 4
Users are evaluated against these conditions in the order listed and routed accordingly. Any user who doesn't match a condition will follow the default **everyone else** path.
#### Example use case
Split users by satisfaction rating to deliver tailored follow-up experiences:
* <2: Show apology and collect feedback
* 2–4: Offer support tips
* 4 - 5: Prompt referral invitation
### Experiment
An **experiment** step enables randomised testing across multiple paths to measure and optimise user outcomes. This is useful for A/B or multivariate testing.
#### Example use case
Test two onboarding email sequences by splitting users 40/60. Track which sequence results in more app opens within 7 days, and automatically switch all future users to the winning version after 7 days.
#### Configuration
1. **Variant distribution**
Specify what percentage of users should go down each path (e.g., 40% to Path 1, 60% to Path 2). You can optionally add more paths or a control group.
2. **Conversion tracking**
* **Conversion event**: Select the event that signifies success (e.g., `app_opened`).
* **Tracking window**: Define how long to measure conversions (e.g., 7 days).
* **Auto-switch to winning path**: Automatically route future users to the top-performing path after a fixed period (e.g., 12 days).
3. **Control group**\
Set a percentage of users who do not receive anything from the experiment. This helps you to analyse the experiment on an absolute basis – how much did each variant do compared to users who did not receive any communications.
{% hint style="warning" %}
The sum total percentages for all variants and control group should add up to 100%.
{% endhint %}
####
