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.
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
trueorfalse.
Adding a step filter
To open and configure filter settings:
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.
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.
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.
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 thevaroperator. If access to a dotted key is needed, the dotted key should be quoted with backquotes (`).Logic
Process Context
Result
Extended behavior:
var- Inside a value stream the data means the context with the parent key.For example if the process context is:
Then, the data for the JSON logic expression would be:
Dotted keys must be backquoted to work.
Logic
Process Context
Result
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
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.
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.
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.
Last updated
Was this helpful?