---
sourceDocument: Australia Build workflows
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/build-workflows

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Flow and subflow stages

# Flow and subflow stages {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Flow and Subflow Stages

This guide provides essential information on configuring and managing flow and subflow stages in ServiceNow's Workflow Studio.
It outlines how to communicate the current status of requests through stages, which can enhance user experience and operational efficiency.
Show full answer Show less  

## Key Features

* **Add and Configure Stages:** Users can add stages to flows or subflows, modify their labels, and set estimated durations.
* **Stage Field Functionality:** Displays the current stage details for specific records within a flow or subflow, including stage names and states.
* **Stage States:** Each stage can be in one of six states: Pending, In Progress, Skipped, Complete, Cancelled, or Error.
* **Subflow Stage Visibility:** Option to display subflow stages within a parent flow for better tracking.
* **System Properties:** Users can configure properties to control the display of approval details within stage fields.

## Key Outcomes

By effectively managing flow and subflow stages, ServiceNow customers can expect improved clarity in process tracking, enhanced user communication about request statuses, and streamlined troubleshooting through unique trigger conditions. This structured approach ensures that overlaps in stage information are minimized, allowing for efficient flow execution and error handling.  
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](https://servicenow-prod.fluidtopics.net/C_WxRt_xH~ag_kFHDPWPjA#c_WorkflowStageSets "Stage sets are named groups of workflow stages commonly used together. Create a stage set and assign it as a default set to any number of tables. You can import the choice list values of a workflow field as stages for a workflow, and export a stage set to create a new one."). Any changes made to the copy do not affect the original stage set record.
{#flow-designer-stages__ul_sdb_b3c_cdb}

You can view the stages of a flow or subflow from its execution details.

## Displaying stages in a stage field {#flow-designer-stages__section_h4v_gmv_bdb}

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.
{#flow-designer-stages__ul_bn3_z5m_ddb}

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.  
Note:  
Only add one stage field per table. If there is more than one stage field, the system only displays stages from the first stage field defined in the table dictionary entry.

## Stage field and trigger types {#flow-designer-stages__section_fjb_nxt_ddb}

Associating a flow to a stage field depends on the flow trigger type.  
{#flow-designer-stages__table_i5y_rxt_ddb__entry__2}

| 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](https://servicenow-prod.fluidtopics.net/cjPjkQFYMtXJzVm8~GKbZw "Start a flow when a Service Catalog item is requested to automate the fulfillment process."), 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. |
[ ]

{#flow-designer-stages__table_i5y_rxt_ddb}  
Note:  
While you can add stages to a flow that has a scheduled trigger, the stages are never displayed to an end user because there is no associated trigger record for the stage field. Only add stages to flows and subflows that have a trigger or input record.

## Stage states {#flow-designer-stages__section_opc_tpj_cdb}

During flow or subflow execution, each stage can be in one of six states.  
{#flow-designer-stages__table_wwy_pgk_cdb__entry__2}

| 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: * The flow or subflow must have at least one stage defined. * The Error can only be set within a stage. When an Error condition is reached, the current stage is set to Error. * The Error can only be set within a conditional flow logic block. {#flow-designer-stages__ul_ab2_qfn_ddb} |
[ ]

{#flow-designer-stages__table_wwy_pgk_cdb}

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.

## Seeing subflow stages in a parent flow {#flow-designer-stages__section_kh1_dcw_lfc}

Figure 1. Sample flow and subflow stages

The Flow Stages dialog box can display subflow stages from a parent flow. Use the Show Subflow Stages option when configuring a subflow to include subflow stages in the parent flow.

## System properties {#flow-designer-stages__section_dsb_vpk_dzb}

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
    {#flow-designer-stages__ul_org_hqk_dzb}

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
    {#flow-designer-stages__ul_atp_zqk_dzb}

## General guidelines {#flow-designer-stages__id_mf4_ysb_ptb}

Follow these general guidelines when creating flows or subflows with stages.

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.
{#flow-designer-stages__ul_dq5_4wm_xsb}
* **[Configure stages and add them to a flow](https://servicenow-prod.fluidtopics.net/j9aPIJwHLrGiUPkN0w7yKA)**   
  Configure when stages display to a user, define stage state labels, and add stages to a flow or subflows within Workflow Studio.
* **[Show subflow stages in a parent flow](https://servicenow-prod.fluidtopics.net/U2INCl~ccONFC~cLvllRaQ)**   
  Show subflow stages as part of the execution details of a parent flow.