Flow and subflow stages
Summarize
Summary of Flow and subflow stages
This documentation explains how ServiceNow customers can communicate the current stage of a request, flow, or subflow to end users by configuring stages within Workflow Studio. Stages provide visibility into the progress of flows or subflows and enable updating stage details on triggering records via stage fields.
Show less
Key Features
- Stage configuration: Add and customize stages in flows or subflows, including labels, names, and estimated durations.
- Stage sets: Import predefined stage sets for reuse; changes to imported copies do not affect the original sets.
- Stage fields: Display progress and states of flows/subflows tied to records, such as Service Catalog requests. Only one stage field per table is supported, displaying stages from the first defined stage field.
- Flow trigger integration: Stages display depends on the flow trigger type; record-based flows require a stage field on the triggering table, while Service Catalog-triggered flows must associate the flow with the catalog item.
- Stage states: Each stage can be in one of six states—Pending, In progress, Skipped, Complete, Cancelled, or Error—with options to customize state labels per stage.
- Error handling: Error states can be set within stages using conditional logic to communicate issues to users and optionally halt or remediate flow processing.
- System properties: Configure display options such as showing approvers assigned to stages and limiting the number of approvers displayed.
Best Practices and Guidelines
- Avoid defining stages inside For Each loops; stages can only be added before or after such blocks.
- Prevent multiple flows/subflows from overwriting each other's stages on the same record by defining unique trigger conditions.
- Do not manually update stage fields outside of flows or subflows to avoid inconsistent states.
- Use error stages to notify users of issues without interrupting flow execution and to trigger remedial actions if needed.
Practical Outcomes for ServiceNow Customers
By leveraging flow and subflow stages, customers can provide clear, real-time visibility into request or process progress directly on records. This improves communication with end users and operators, facilitates troubleshooting through distinct stage states, and enables more controlled flow execution through error state management. Proper configuration ensures that stage information is accurate and consistent across multiple flows, enhancing operational clarity and user experience.
Communicate the current stage of a request, flow, or subflow with an end user.
When configuring stages in Workflow Studio, you can:
- Add stages to a flow or subflow
- Change stage labels and names.
- Configure the estimated duration for a stage.
- Import a copy of a pre-defined stage set from the Stage Sets table. To learn more about stage sets, see Workflow stage sets. Any changes made to the copy do not affect the original stage set record.
You can view the stages of a flow or subflow from its execution details.
Displaying stages in a stage field
A stage field stores and displays the stage state and details about a specific record as a flow or subflow runs. For example, the Service Catalog table uses the Stage field to indicate the progress of a request as it is processed.
Stage fields display:
- Stage details for the specific record that triggered the flow or that was used as a subflow input. For example, the current state of a specific Service Catalog requested item.
- Stage names and states defined in the associated flow or subflow. If the associated flow calls another flow, stages set on the child flow do not display.
- Stage details from flows or subflows that have started. If a flow or subflow is not running for a record, that record will not have any stage field details.
State icons in stage fields cannot be modified. Limit the number of stages and the length of each stage name to prevent wrapping text and icons onto multiple lines.
Stage field and trigger types
Associating a flow to a stage field depends on the flow trigger type.
| Flow trigger type | Requirements |
|---|---|
| Record | For a stage field to report stages on a record-based flow, a stage field must be present on the same table as the triggering record. When a flow has stages, Workflow Studio communicates the status of each stage back to the triggering table and displays the current stage state as an icon. If more than one stage field exists on the table, only the first stage field defined in the table's dictionary definition is used. Note: Avoid creating stages for multiple flows that trigger from the same table. A stage
field only displays the stages of the final flow to run. Add different conditions to each
flow to ensure that the stages of one flow do not overwrite another flow. |
| Service Catalog | If using the Service Catalog trigger, the flow must be associated with the Service Catalog item through the Flow field. Remove any workflows associated with the item by clearing the Workflow and Execution Plan fields. The Stage field displays the current stage state on any list view of the Requested Items [sc_req_item] table. |
Stage states
During flow or subflow execution, each stage can be in one of six states.
| State | Description |
|---|---|
| Pending | This stage has not yet started. |
| In progress | This stage is executing. |
| Skipped | This stage was skipped and did not run. Typically, this state is reached when a conditional flow logic block is not executed. |
| Complete | This stage is complete. |
| Cancelled | This stage was cancelled. |
| Error | This stage has reached an error condition. When designing a flow or subflow, you can manually set its to report an Error state. To set an Error state:
|
Each stage can have its own custom state labels. For example, suppose that you have a flow with two stages. Stage 1 could have the Pending state with the label Waiting, and Stage 2 could have a Pending state with a label of Not yet started. Workflow Studio provides options to generate either the default states or approval states.
System properties
You can use these system properties to configure how a flow or subflow displays approval details.
- com.glide.hub.flow_engine.stage_display.show_approvers
- Show or hide the list of approvers assigned to a stage from a stage field. Set the value to true to show the list of approvers assigned to a stage. Set the value to false to hide the list of approvers assigned to a stage.
- Type: true | false
- Default value: true
- Location: Add to the System Properties [sys_properties] table
- com.glide.hub.flow_engine.stage_display.show_approvers_limit
- Specify the maximum number of approvers to display in a stage field as an integer value. Setting this value above 10 risks causing rendering errors in a list view. The stage field for one record can become so big that
the list cannot display additional records in the list.
- Type: integer
- Default value: 5
- Location: Add to the System Properties [sys_properties] table
General guidelines
- Avoid defining stages that depend on a For Each flow logic
- Flow Designer prevents you from adding stages within a For Each block. You can only add stages before or after a For Each block.
- Avoid creating stages for the same records in different flows or subflows
- A stage field always displays the stage information provided by the last flow or subflow to run on a table's record. If multiple flows or subflows run on the same records, then the stages defined in one flow or subflow can in theory overwrite the stages from another flow or subflow. To avoid multiple flows or subflows overwriting each other's stages, define unique trigger or start conditions for each flow or subflow.
- Avoid updating stage fields from outside a flow or subflow
- If you manage stages with a flow or subflow, avoid directly updating record stage fields from outside the flow or subflow. Manually updating the value of a stage field may produce unexpected or undesired results.
- Ensure that each flow on a table has unique trigger conditions
- Adding unique trigger conditions to each flow ensures the flows only run under those conditions and prevents the stages from one flow overwriting the stages of another flow. Specifying unique trigger conditions makes it easier to troubleshoot flows by limiting the number of flow executions that can produce record changes.
- Use error stages to communicate with the user
- The flow error state does not affect flow execution. A flow continues running even if it reaches an error stage. Use a conditional flow logic block to set the error stage and communicate to the user that the state of the current stage is Error. For example, if an approval is not approved within the required limit, you may want to communicate an error to the user.
- Use the error stage to stop processing a flow
- Use a conditional flow logic block to identify when a flow enters the error stage. Use the flow logic to stop processing the flow or take some kind of remediation action. For example, you may want to change the record state or assignment when a flow reaches an error state.