> ## Documentation Index
> Fetch the complete documentation index at: https://help.maestra.io/llms.txt
> Use this file to discover all available pages before exploring further.
# 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.
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.
### 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.
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.
**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:
| 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.
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:
Set up the balance-related condition using the **By balance change** context.
Set up the customer-related condition using the **Customer** context in a separate block.