In flows, you can narrow down which data the flow should fire on by using contextual filters in the Condition block.
Different entities (contexts) are available in the Condition block depending on what you need to check. For example, a price-drop flow should only run when a product is available, while an abandoned cart flow should only run after a session in which the customer added items to their list.
For details about the multi-branch mode, see the article on how multi-branch mode works in the Condition block.
Contexts available in all flows
The following entities are available in every flow, regardless of the trigger event.
By customer
Determines whether the flow should fire for the customer who entered it.
Example. Use the Customers context to check that the customer has a valid email, is subscribed, and has not received any campaigns in the last 24 hours.
These contexts set firing conditions that do not depend on customer data.
A product segment can be of any type (real-time, recalculated, or static).
Example. The flow fires if the New arrivals segment contains at least five products.
A promo code pool can come from any campaign. The pool must be live.
Example. The flow fires if the For the 10% promo pool contains at least one available promo code.
Event-specific contexts
The events that trigger flows carry their own data.
For example, if the event is an order, that data includes the order value, purchased products, line item statuses, and so on.
Choosing a specific trigger event makes it possible to filter the entities passed in that event using dedicated contexts.
Let’s look at how this works with orders and sessions as examples.
By order
Available in flows triggered by the New order, Order data changed, and Order status changed events.
Task: the flow should fire when an order with a value of $30,000 or more is delivered.
Create a flow triggered by Order status changed and set the condition:
Use the Orders context. This way you check exactly the order that triggered the flow.
How checking by order differs from checking by customer:
When you use the Customers context, you set a condition that the customer has the required data, but there is no link to the triggering event:
The check confirms that the customer has an order of $30,000 or more. That could be either the order that triggered the flow or any other order in the customer’s history. This context is not suitable for the task above.
By session
Available in flows triggered by the Customer left site or app event.
Task: to build an abandoned cart flow, you need to verify that the customer added products to their list during the session.
Use the Session context. This way you check exactly the session that triggered the flow.
How checking by session differs from checking by customer:
You would be setting a condition that the customer has products in their cart, but they are not necessarily products added during this session. This context is not suitable for the task above.
By operation variables
Available in flows triggered by the Operation called event.
The comparison logic is the same as in multi-branch mode, but there are nuances depending on variable type.
Integer and decimal numbers
Range boundaries are inclusive: “less than 3” means 3 and below; “from 1 to 5” means 1, 2, 3, 4, 5.
Decimal numbers must match the specified value exactly. With the condition “equal to 7.77,” the value 7.77221 will go to the No branch. Control precision on the integration side.
nps_score variable. The condition block has three branches:
- 3 or less → an apology email asking what went wrong
- Between 5 and 8 → “Thanks for your rating, we’ll keep improving” email
- Between 9 and 10 → “Thanks for the high rating, we appreciate you” email
Example: decimals. A customer places an order. The operation passes the purchase amount into the order_amount variable. The condition block has three branches:
- Between 1,000.00and4,999.99 → email with a selection of related products and a promo code
- More than $5,000.00 → email thanking the customer and offering increased cashback on the next purchase
Date / Date and time UTC
Values of the “Date and time UTC” type are stored in UTC and converted to the project’s time zone for comparison.
- In range — both the left and right boundaries are inclusive. For example, with the condition “occurs in 3–7 days,” a customer with a date exactly 3 or exactly 7 days from now will go to the Yes branch.
- More than N / Less than N — the boundary is not included. For example, with the condition “occurs more than 3 days from now,” a customer with a date exactly 3 days from now will go to the No branch.
- Today triggers when the value matches the current calendar day in the project’s time zone.
Example: Date and time UTC. A courier is running late on a delivery. The operation passes the courier’s expected arrival time into the arrival_time variable. The condition block has three branches:
- Occurs in 15–30 minutes → apology email, no compensation
- Occurs in 31–60 minutes → email with a 10% discount on the next order
- Occurs more than 1 hour from now → email with a $10 promo code
String and Enumeration
Compared by exact value match.
Example. A new pickup point is opening. The operation passes the city and district into the city_district variable. The condition block has two branches:
- Value equals “Boston Back Bay” → email with a selection of new pickup points in Back Bay
- Value equals “Chicago” → email with a selection of new pickup points in Chicago, and so on
Boolean
Accepts Yes or No.
Example. A customer signs up for a subscription. The operation passes a premium-subscription flag into the is_premium variable. The condition block has two branches:
- Value equals Yes → welcome email describing premium features
- Value equals No → email offering an upgrade to premium with a discount
Other entities
The remaining contexts work on the same principle.
Filters and the events they’re available in:
| Context | Events |
|---|
| By session | Customer left site or app |
| By order | New order, Order data changed, Order status changed |
| By order line item | Order line item delivered, Order line item paid |
| By action | New order, Order data changed, Order status changed, Viewed product changed, Product-related action granted, Customer changed email, Customer changed mobile phone, Customer balance went negative, Bonus points became available, Discount card status changed, Discount card replaced |
| By product in list | Product in product list changed, Product list changed |
| By viewed product | Viewed product changed |
| By product | Order line item delivered, Order line item paid, Product in product list changed, Product list changed, Viewed product changed, Preferred product changed, Product-related action granted |
| By promo code | Promo code granted, Customer applied promo code, Customer’s referral promo code used |
| By balance change | Customer balance went negative, Bonus points became available |
| By discount card information | Discount card status changed |
| By operation variables | Operation called |
How to combine filters from different contexts
Flows with multiple contexts
Many use cases require setting conditions across different entities at once.
Task: customers who register for an online history course before the start of the school year receive a bonus.
Create a flow triggered by Product-related action granted and check two entities:
- the action (whether the registration happened)
- the product (whether the right course was passed)
What order to put the blocks in
In most cases the order doesn’t matter. But if the flow processes large volumes of events (several million per hour) and you want to reduce load on the project, put the blocks that filter out the most irrelevant events first.
How you should and shouldn’t check the customer
Check the customer only by using the Customer context.
By balance change
Set up the balance-related condition using the By balance change context.
By customer
Set up the customer-related condition using the Customer context in a separate block.
