---
title: Data-driven steps
slug: data-driven-steps
docTags:
createdAt: 2026-09-08T13:45:28.624Z
---
In workflows, it is possible to track the execution progress** based on data **from the **current process.**
*Administrators* can configure this feature by adding the required number of steps and specifying the conditions for their **‘ongoing’ **and **'completed’**. These conditions can reference properties that fall within the current administrator's permission scope. However, even *end users* without permissions to access those specific properties will be able to see the execution or completion status of the steps.
:::hint{type="danger"}
Please also note that if [Step node](docId\:Zcb6Dqb3jrKjhVRRxsavK) are configured in the current process, **they will be overridden by the settings of the current steps.**
:::
:::hint{type="info"}
*This feature applies to all processes within the current definition as a whole, rather than to process runs activities.*
:::
## Setting configuration
### Feature configuration
1. This feature is located in the **"Steps"** tab
2. Here you can add the number of steps
3. Number of added steps
4. Number of active steps (*enabled*)
5. List of added steps
### Step header configuration
1. Option to change the step display order (**this change will be visible to the end user**)
2. Step configuration collapse button
3. Display of the step name in the current interface language (required field)
4. Rule activation toggle (**disabling step without deletion**)
5. Rule deletion button
### Step body configuration
1. Step name input block (multilingual, required field)
2. "Ongoing/Completed" status condition block
### Condition configuration
1. Add condition property
2. Add filter group
3. Select filtering method (*AND or OR*)
4. Delete property button
5. Delete filter group button
6. Property removed from definition or inaccessible to the current administrator
## How it works
In the step settings, the *administrator* configures the number of steps, their order, their names, and the conditions for displaying them in the "Ongoing" and "Completed" states.
Conditions are configured based on the administrator's property permissions; **if the administrator lacks access to specific properties, they cannot select them.**
**Available properties, including hidden ones, can be selected.**
When an end user accesses an process, they see the configured steps at the top, regardless of their own permissions. This allows for the configuration of conditions based on properties that are unknown to the end user.
:::hint{type="info"}
The execution order of steps need not be sequential; it is based on data rather than the display order. For instance, if **"Step 1"** is awaiting data that *has not yet appeared,* while **"Step 5"** has already received the data *needed for completion*, **"Step 5"** will appear green *while* **"Step 1"** remains *gray*.
:::
## Rendering conditions
Steps have four states:
`gray` – the step is not yet due to run
`blue` – the step is "ongoing"
`green` – the step is complete
`red` – the step failed via failed process
The display of a step's state depends on several factors:
- process status
- fulfillment of one of the conditions
### Full list of states
| "Completed" condition | "ongoing" condition | Process status | Step color |
| -------------------------------- | -------------------------------- | -------------------------------------- | ---------------------------------- |
| yes | — | any | green |
| no | yes | succeeded | blue |
| no | yes | running | blue |
| no | yes | failed | red |
| no | yes | canceled | blue |
| no | no | any | gray |
**TLDR:**
In summary, there are only four output values:
\- `Green` — step completed;
\- `Red` — step is running, but the process has failed ("ongoing" and failed);
\- `Blue` — step is running with any other process status (‘started’, ‘completed’, ‘cancelled’);
\- `Gray` — step has not yet started (neither ‘completed’ nor ‘ongoing’).
## Examples
1. `Running` process
2. `Canceled` process
3. `Failed` process
