Data-driven steps

9 min

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 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 this feature applies to all processes within the current definition as a whole, rather than to process runs activities setting configuration feature configuration feature config this feature is located in the "steps" tab here you can add the number of steps number of added steps number of active steps ( enabled ) list of added steps step header configuration step header config option to change the step display order ( this change will be visible to the end user ) step configuration collapse button display of the step name in the current interface language (required field) rule activation toggle ( disabling step without deletion ) rule deletion button step body configuration step body config step name input block (multilingual, required field) "ongoing/completed" status condition block condition configuration condition config add condition property add filter group select filtering method ( and or or ) delete property button delete filter group button 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 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 \`running`\ process example running process \`canceled`\ process example canceled process \`failed`\ process example failed process