> For the complete documentation index, see [llms.txt](https://developer.emporix.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.emporix.io/vsm-guides/value-stream-designer/process-components/conditions.md). # Conditions Learn how to use filters, branching, and looping conditions to control triggers and process steps. Value Stream Modeller provides several features that let you control when steps run and how the workflow progresses. Using conditions, you can restrict steps to specific events, create branching logic, or repeat parts of the process until a requirement is met. These mechanisms allow you to build workflows that adapt dynamically to different scenarios.
:filter:Step filtersRun a trigger or step only when filter or JSON condition criteria are met.#step-filters
:code-branch:Conditional stepsCreate branches with different paths that run when their conditions are met.#conditional-steps
:repeat:LoopingRepeat steps until a condition is met, then continue to the next step.#iterator-steps
## Step filters Filters allow a trigger or a process step to run only when specific criteria are met. When a filter is applied, the step runs only if those criteria evaluate successfully. If they are not met, the step is skipped. You can define criteria in two ways: * **Filter** – restrict execution to specific event types using OR/AND logic. Event types are based on those configured in OE for your tenant. * **Condition** – define custom logic with a JSON expression that evaluates to `true` or `false`. ### Adding a step filter To open and configure filter settings: {% stepper %} {% step %} #### Choose the process step Use the three dots icon in the process step where you want to add a filter and choose **Add Step Filter**. {% endstep %} {% step %} #### Choose Filter or Condition A side panel opens with two tabs: **Filter** and **Condition**. Use **Filter** for event-type-based criteria, or **Condition** for a JSON logic expression. If you switch between the **Filter** and **Condition** tabs after making changes, a warning appears that your unsaved changes will be lost. Save or cancel your configuration before switching tabs. {% tabs %} {% tab title="Filter" %} * Select the **Field** - currently the Event Type is supported. * Choose the filter **Operator**: * OR: The condition applies if the event type matches at least one of the selected events. * AND: The condition applies only if the event type matches all selected events. Events accumulate across steps. * Choose the **Events** from the drop-down list. The list shows event types available for your tenant and the current scenario context. You can select multiple event types at one time. For example: If you select OR with `Customer opt in` and `Customer created` selected, the filter passes if either one happens. If you select AND with the same list, the filter only passes once both events happen. {% endtab %} {% tab title="Condition" %} Edit the JSON logic expression directly. When the expression evaluates to `true`, the step runs. When it evaluates to `false`, the step is skipped. The condition variables are mapped to values from the process context, for example, with the `context` operator. Use **RESET** to restore the default expression. {% endtab %} {% endtabs %} {% endstep %} {% endstepper %} When a filter is configured, an additional filter block appears below the step where it was applied. You can cancel the configuration at any time, remove an existing filter with **REMOVE FILTER**, or save your changes with **SAVE**. Example of a trigger filter: ### JSON logic operators The following custom operators extend standard JSON logic for step filter conditions. **Custom operators:** * `context` - This is used to access a dynamic value inside the process context in a way similar to the `var` operator. If access to a dotted key is needed, the dotted key should be quoted with backquotes (`` ` ``). * **Logic** ```json {"context": "`key.with.dots`.boolean"} ``` * **Process Context** ```json {"key.with.dots": {"boolean": true}} ``` * **Result** ```json true ``` {% hint style="warning" %} This operator is valid within the value stream logic. {% endhint %} **Extended behavior:** * `var` - Inside a value stream the data means the context with the parent key. For example if the process context is: ```json {"event": {"key": "value"}} ``` Then, the data for the JSON logic expression would be: ```json {"context": {"event": {"key": "value"}}} ``` Dotted keys must be backquoted to work. * **Logic** ```json {"var": "context.`key.with.dots`.boolean"} ``` * **Process Context** ```json {"key.with.dots": {"boolean": true}} ``` * **Result** ```json true ``` {% hint style="info" %} For the full list of JsonLogic operators, see the [JsonLogic](https://jsonlogic.com/operations.html) guide. {% endhint %} ## Conditional steps Conditional steps let you introduce branching logic into a workflow, allowing different sets of steps to run depending on whether specific conditions are met. You define one or more paths, each with its own condition. When the workflow reaches the conditional step, the system evaluates every path’s condition: * If a condition is true, its corresponding path is executed. * If there are multiple conditions set, the paths run in parallel. * If no conditions are met, the conditional step is skipped and the workflow continues to the next step in the main sequence. * To complete the conditional step, all of the conditions set up in the paths have to be met. This enables logic similar to if and if/else statements and allows flexible routing within the workflow. Each path contains an array of steps that run sequentially, one after another. These steps use the same structure and format as standard workflow steps in the value streams, ensuring consistency across the process. **Example:** When a customer places an order, the process can send them a coupon - but under different circumstances: * When the customer belongs to the **Premium Customers** segment, or is a first time customer * When the delivery is late because of the order splitting. If both conditions are met, the customer receives an email with a voucher for their next order. If not, that path is skipped and the process continues without sending the coupon. ### Creating a conditional step {% stepper %} {% step %} #### Add a conditional step Add a new process step and choose **Condition**. The conditional step is added to your flow. {% endstep %} {% step %} #### Define paths and conditions A sidebar opens where you define the conditions for each path. Each condition becomes a separate path (branch) of the conditional step. Define the variables for each path and save. In this example, two paths are set up: one condition checks whether the customer belongs to a specific segment, the other checks whether the order contains more than a 100 of product items. {% endstep %} {% step %} #### Add steps inside each path For each path you can add steps that run when that path’s condition is met. For example: * If the customer belongs to a Premium Customers segment, they get an email with a coupon for the next order. * If the order has more than 100 items, the order needs to be split, but if it turns out the delivery is late and takes more than 5 days, the customer also gets a coupon for the next order. {% endstep %} {% step %} #### Add a step after the conditional step Add a step that runs after the conditional checks. This step is executed only when at least one of the defined conditions is satisfied and its path leads to it. If no condition is met, the process does not continue. {% endstep %} {% endstepper %} For each path you can **Add Predicate** to refine when the path runs by combining conditions with AND or OR logic. For example, on the customer check path you can add a predicate so the path runs either for the first-time customers, or when the customer is in the Premium Customers segment. ## Iterator steps With the iterator step, you set up a loop that repeats the steps inside it until a defined condition is satisfied. After each iteration, the system evaluates the loop condition: * If the condition is false, the loop runs again. * If the condition is true, the loop ends and the workflow continues with the next step outside the loop. ### Loop execution In a linear workflow (without branching), the system executes all steps inside the loop sequentially. After the steps finish, the loop condition is evaluated. The cycle repeats until the condition becomes true, at which point the workflow proceeds to the next step in the sequence. By default, the loop can be inifite, but you can also define the number of its runs by setting up the **Limit**. **Examples:** * You can set up a value stream that is triggered by a product price update: the product is updated with the new price, and when the price decreases by 20% or more, an email is sent to customers about a final offer. The loop evaluates the price and, based on the condition, triggers the step that sends the email. Loops can also be used in paths, inside the conditional steps. It means, each path may contain its own steps, including loops. When a path is executed, any loop within that path behaves the same way–its internal steps repeat until the loop condition is met, after which the path continues with its remaining steps. * You can create a value stream for return management where the conditions check whether the return was requested within 14 days of the order, and whether the order value is above or below $200. If it is below $200, the system automatically approves the return. If it is above $200, the process retrieves the approval group members and then waits for approval; a loop in the approval path runs until approval is received. If a loop is added in the conditional step's path, and has conditions set up, it overrides the conditional steps ones defined for the path. {% hint style="info" %} For step-by-step guidance on building value streams, see [Creating a Value Stream](/vsm-guides/value-stream-designer/creating-value-stream.md). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://developer.emporix.io/vsm-guides/value-stream-designer/process-components/conditions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.