How Contextual Filters Work in the Condition Block of a Flow

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.

​

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.

​

By promo code availability and By products in segment

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. Example: integers. After an order is delivered, the operation passes an NPS survey score into the 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.00 and$4,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:

​

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

Do not set customer conditions through other contexts. In new flows, that option is no longer available. Instead of combining checks in one block, split the conditions into separate blocks: