--- 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 execution details # Flow execution details {#ariaid-title1} * Release version: Australia * * Updated March 12, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 10 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 Execution Details Flow Execution Details in ServiceNow provide runtime and configuration information about flows, subflows, and actions directly from the Workflow Studio design environment. This enables users to monitor the current state, execution duration, input/output values, and related records for each flow run. Access to execution details is controlled by user roles to ensure appropriate data visibility. Show full answer Show less ## Reporting Levels The system supports four reporting levels that control the amount of execution detail generated during flow operations: * **Off:** No execution details generated except during testing, which uses Trace level. * **Basic:** Captures runtime states and durations for flows, subflows, and actions, including trigger and subflow data. * **Full:** Includes configuration and runtime details for all items, suitable for debugging but only allowed on non-production instances. * **Trace:** Provides the most detailed information including all configuration and runtime values, intended for testing and support, and requires special roles. Note that production instances restrict reporting to Basic or lower, and execution details are only available for flows run with reporting enabled at the time. ## Flow States and Management Flows can be in various states such as Completed, Cancelled, Waiting, Paused, Presumed Interrupted, or Error. Each state provides different levels of execution detail to help diagnose flow progress or issues. Users can refresh flow data manually or configure preferences for automatic updates during testing. ## Accessing Related Records and Logs From the execution details page, users can open related records including the flow configuration, context records, logs, triggering records, and actions. Changes to flow or action configurations do not affect already active flows. Logs display timestamps in UTC to maintain consistency across nodes. ## Flow Statistics and Execution Information Detailed statistics include calling source, user roles at runtime, integration metadata (if applicable), configuration input/output variables, logs, and step-level details for custom actions. The system property `com.snc.processflow.reporting.serialized.valsizelimit` controls truncation of large runtime values. Execution duration metrics cover all processing stages, including queue times, flow engine execution, MID Server communication, and retries when enabled. ## Calling Sources Flows can be triggered from various sources such as Workflow Studio tests, CRUD triggers, scheduled date triggers, metric triggers, service catalog requests, or scripts, aiding in identifying flow initiation context. ## Subflow Execution Details Subflow executions are viewable inline within parent flows or independently. This allows process analysts to monitor nested flow runs comprehensively. ## User Role-Based Access Access to flow execution details is governed by roles: * **flowoperator:** View execution details, dashboards, and logs without edit permissions. * **fdreadoperations:** View basic execution details like runtime state and duration. * **fdreadoperationsall:** View all available execution details as allowed by reporting level. Additionally, users must possess any privileged roles under which the flow ran to view corresponding execution details, ensuring secure access especially when field encryption or elevated permissions are involved. ## Practical Benefits for ServiceNow Customers ServiceNow customers can use flow execution details to effectively monitor, troubleshoot, and optimize their workflows by accessing detailed runtime data and logs. Controlled visibility based on roles helps maintain security while empowering administrators and process analysts to diagnose and improve flow performance. The integration of execution details within Workflow Studio streamlines flow development and support activities, enhancing operational efficiency and governance. View run-time information about an action or flow directly from the design environment, such as the current state, items run, and values produced. Open related records from embedded ServiceNow AI Platform editors or in a new tab. Each time you test a flow, the system generates information about the configuration and runtime values produced as flow execution details. You can view flow execution details from the Operations tab of Workflow Studio. Select a flow execution to open its associated execution details page. Figure 1. Example flow execution details for today's executions Each execution details page displays runtime information about the flow. * Name of the flow * Refresh flow data * Flow state * Related record options * Flow Statistics {#flow-execution-details__ul_qxc_l1c_tbb} Figure 2. Sample execution details ## Reporting level {#flow-execution-details__section_iyg_vhq_wsb} The reporting level determines what execution details a flow, subflow, or action generates during normal operations. By default, Workflow Studio doesn't generate any execution details during normal operations. Workflow Studio generates full flow execution details when you test an individual flow, subflow, or action. When your instance generates and stores more execution details, reporting has more performance impact on your instance. Each reporting level generates progressively more flow execution details. {#flow-execution-details__flow-reporting-level-off}Off{#flow-execution-details__flow-reporting-off-dt} : The system doesn't generate flow execution details. The system only generates execution details when you run a test. Note: Testing an action or flow generates execution details at the Trace level.{#flow-execution-details__flow-reporting-off-dd} {#flow-execution-details__flow-reporting-off-dd} {#flow-execution-details__flow-reporting-level-basic}Basic: Runtime states and durations only{#flow-execution-details__flow-reporting-basic-dt} : The system generates runtime execution details for each flow, subflow, and action run. You can see the runtime state and duration for these basic items. You can also see configuration and runtime values for flow triggers, subflow inputs, and subflow outputs.{#flow-execution-details__flow-reporting-basic-dd} {#flow-execution-details__flow-reporting-basic-dd} {#flow-execution-details__flow-reporting-level-full}Full: Action configuration and runtime values (for debugging only){#flow-execution-details__flow-reporting-full-dt} : The system generates configuration and runtime execution details for each flow, subflow, and action run. You can see the runtime state, duration, input values, and output values for all items. For custom actions, you can also see the runtime state, duration, input values, and output values of its steps. You can also see the configuration values for flow triggers, subflows, actions, and steps that are part of a custom action. Important: This reporting level is only valid on non-production instances. Production instances prevent you from setting the Full reporting level and instead revert the reporting level back to the Basic option. Also, only users with the fd_read_operations_all role can see configuration and runtime information such as record values in the flow execution details. Users without this role will only see basic details about the state and duration.{#flow-execution-details__flow-reporting-full-dd} {#flow-execution-details__flow-reporting-full-dd} {#flow-execution-details__flow-reporting-level-trace}Trace: All values (for testing and Support only){#flow-execution-details__flow-reporting-trace-dt} : The system generates configuration and runtime execution details for each flow, subflow, action, and step run. You can see the runtime state, duration, input values, and output values for all items. You can also see the configuration values for flow triggers, subflows, actions, and steps. Important: Only users with the fd_read_operations_all role can see configuration and runtime information such as record values in the flow execution details. Users without this role will only see basic details about the state and duration. Testing an action or flow generates execution details at the Trace level.{#flow-execution-details__flow-reporting-trace-dd} {#flow-execution-details__flow-reporting-trace-dd} If a flow runs while reporting is off, past execution details are never available for the flow, even if the reporting level later changes. If a flow runs while reporting is on, execution details are available for that flow execution, even if the reporting level changes. The reporting level has no effect on context and log records. You can configure the default reporting level the system uses to generate execution details each time a flow is run. For more information, see [Activate flow reporting](https://servicenow-prod.fluidtopics.net/0Wvrk7uR2kF3HtdQTZpAVg#enable-flow-reporting "Choose whether to generate execution details for all flows and actions run, just for individual flows and actions, or just when you test a flow or action. Specify the level of detail the execution details contain."). ## Refresh flow data {#flow-execution-details__section_v13_cjf_q5b} Update flow runtime data as needed. Set a flow preference to refresh flow data automatically when you run a test. See [User preferences for flows](https://servicenow-prod.fluidtopics.net/3jnWFAmktUE0C0bhnwyQAg "Enable or disable user preferences for flow to change options available to Workflow Studio."). ## Flow state {#flow-execution-details__section_xpk_4bc_tbb} All active flows are in one of these states. Completed : The flow successfully ran all actions. The flow statistics display configuration and runtime details for each action. Cancelled : The flow was either stopped because the flow's run time duration exceeded the flow time out value, or someone manually cancelled the flow. Waiting : The flow paused on an action that is waiting for some condition to be met before continuing. The flow statistics display configuration and runtime details for completed actions as well as any actions waiting for a condition to be met. Flows in the Waiting state display a Cancel Flow UI action in the header. Paused : The flow paused to enable higher priority flows to run or to enable a graceful node shutdown. The flow statistics display configuration and runtime details for completed actions. Presumed Interrupted : The flow has been running for more than 15 minutes and no longer has a valid transaction ID for the current node. Alternatively, the flow has been running for more than eight hours on another node. The flow may have stopped because of an unexpected interruption such as its transaction being terminated or its node being restarted. Error : The flow stopped with an error. The flow statistics display configuration and runtime details for completed actions and configuration details for the action that produced the error. Flows in the Error state display a Go to error UI action in the header. Note: When an action results in an error, the flow stops executing at that point and results in an error state. ## Related record options {#flow-execution-details__section_lgg_vdc_tbb} From the Execution details page, you can access records related to the current flow. Open Flow : Use this option to make configuration changes and publish a new instance of the flow. Changing the flow configuration doesn't change any currently active flow. Open Context Record : Use this option to view the flow state, run duration, and related log entries from a standard form view. This option opens the context record in a new tab. Open Flow Logs : Use this link to view detailed log information about each action. This link opens the log entries list in a new tab. Open Current Record : For flows that have a record-based trigger, use this link to view the triggering record in a pop-up window. Open Action : Use this link to make configuration changes and publish a new instance of the action. Changing the action configuration doesn't change any currently active flow. This link is unavailable for the core actions provided by ServiceNow. ## Flow statistics {#flow-execution-details__section_rkp_p3c_tbb} Use flow statistics to see configuration details and runtime values for each flow component. Selecting a trigger or action expands the row and displays configuration and runtime details about it. Figure 3. Sample flow statistics The following types of execution details are available. Calling source : View the calling source that started a flow, subflow, or action. Run as : Identify whether the flow was Run as the system or the user who triggered the flow. Run with roles : Identify the roles granted to the user who triggered the flow. Integration Metadata : View transaction data such as connection and credential used, MID Server used, target host, and payload size. Integration Metadata is only displayed for integration steps and requires a separate Integration Hub subscription. For more information, see [Integration steps](https://www.servicenow.com/docs/access?context=integration-steps&version=australia&pubname=australia-integrate-applications&ft:locale=en-US). Configuration Details : View the list of input variables to identify any configuration errors with the action. Each variable has its own row displaying its name, data type, configuration settings, and runtime value. The configuration settings display dynamic values as pills. The runtime values display generated records as a link. Note: Variables that have transform functions only display one runtime value, which is the result of all transformations. Output Data : View the list of output variables to identify any configuration errors with the action. Logs : Use the log entries to identify potential processing or performance issues. Each log entry has its own row displaying the creation date, log level, and log message. If the action doesn't generate any logs, the statistics displays the string No Logs. Note: Logs display time in UTC format because logs must be saved as strings so that the instance can share the log data between its multiple nodes. Because each node can reside in a different time zone, the UTC format is used as a common format to preserve correct time values. Steps : Use the list of steps to identify any configuration errors with the action. Each step has its own row displaying the variable name, data type, configuration settings, and runtime value. Core actions don't display steps because you can't change their configuration. Change the com.snc.process_flow.reporting.serialized.val_size_limit system property to truncate runtime values in the flow execution details step configuration. To learn more, see [Workflow Studio flow system properties](https://servicenow-prod.fluidtopics.net/QISjE_DknwhS_u_mrxbXbQ "Configure how the system processes flows."). Start time : View the local time when an action started. Run duration : Use the run duration to identify potential processing or performance issues. The run duration is measured in milliseconds. As of the Washington DC release, the run duration lists the total time to execute an item. The total time includes these items. * Time in the event queue * Time in the ECC queue * Time processing the event * Time running in the flow engine * Time communicating with a MID Server {#flow-execution-details__ul_vzh_mt3_ldc} Retry Info : Use the retry info section to view details about the retry policy. Details include the type of retry strategy, elapsed time, and the next scheduled retry request. The Retry Info section appears only when the retry policy is enabled in the step. For more information, see [Retry policy](https://servicenow-prod.fluidtopics.net/0bm~6rEbfL1vkX3HaQJyLg#retry-policy "Automatically retry failed requests when a step encounters an intermittent issue such as a network failure or request rate limit. Set a retry policy to prevent having to manually trigger the step again."). ## Calling source {#flow-execution-details__section_lpq_wdt_ycb} The calling source lists what started a flow, subflow, or action. {#flow-execution-details__table_cjr_h2t_ycb__entry__2} | Source | Description | |-|-| | Workflow Studio Test | The flow started because someone selected the Test option from the Workflow Studio interface. The flow trigger conditions were ignored. | | CRUD Trigger | The flow started when the record-based trigger conditions were met. | | Date Trigger | The flow started when the schedule-based trigger conditions were met. | | Metric Trigger | The flow started when the MetricBase trigger conditions of a [MetricBase](https://www.servicenow.com/docs/access?context=metricbase&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US) were met. | | Service Catalog Trigger | The flow started when a Service Catalog item was requested. | | Script | The flow started from a method call in a script, such as a business rule. | | Background Script | The flow started from a method call in the Scripts - Background module. | [ ] {#flow-execution-details__table_cjr_h2t_ycb} ## Embedded text viewer {#flow-execution-details__section_t44_dms_tbb} Workflow Studio displays large text-based configuration and runtime output records, such as email output, XML payloads, or script steps using an embedded text viewer. The embedded text viewer can format text as HTML, plain text, or color-coded JavaScript. For script steps, the text viewer highlights code lines containing errors. Figure 4. Sample text view of a script step ## Viewing results for each item in flow logic {#flow-execution-details__section_q2n_4j3_vbb} Workflow Studio displays a selector control to view the configuration and runtime results for each item processed by flow logic. Select a record number to see its configuration and runtime details. Figure 5. Sample flow statistics for each item in the flow logic ## Subflow execution details {#flow-execution-details__section_wvh_ncp_rnb} Process analysts can view subflow execution details from multiple locations. Parent flow : A parent flow lists the flow execution details of each subflow that it calls as inline elements. Expand the subflow step to see the subflow execution details. Subflow : The system generates flow execution details for each subflow run. View subflow execution details directly from the list of flow executions. ## User role support {#flow-execution-details__section_jnp_vm3_ldc} You can control access to flow execution details by granting user roles. For more information about available Workflow Studio user roles, see [User access to Workflow Studio flows](https://servicenow-prod.fluidtopics.net/It9~lSDhYhBThAAusolhpg "Administrators can grant users access to Workflow Studio flows by assigning delegated development permissions or directly assigning a user role. Administrators can also specify which features and content a user can access based on user roles. Application developers can access Workflow Studio functionality through APIs for flows, subflows, and actions."). {#flow-execution-details__table_utq_v2r_nnb__entry__3} | Role title \[name\] | Description | Contains Roles | |-|-|-| | flow_operator | Enables you to view flow execution details, dashboards, and logs. Administrators can grant this role to users that want to be able to view execution results but not create, change, or test them. | none | | fd_read_operations | Enables you to view basic flow and action execution details. When reporting is enabled, users with this role can only see basic execution details such as the runtime state and duration. If the reporting level generates additional details, users with this role cannot see them. Administrators can grant this role to users that only need to view basic execution results but not create, change, or test flows and actions. Note: Read only roles are incompatible with roles that provide write access. Avoid granting the same user both a read only and a write access role. | none | | fd_read_operations_all | Enables you to view all generated flow and action execution details. When reporting is enabled, users with this role can view all available execution details. The user can only see as much detail as defined by the reporting level system property. Administrators can grant this role to users that need to view all flow results but not create, change, or test flows and actions. Note: Read only roles are incompatible with roles that provide write access. Avoid granting the same user both a read only and a write access role. | fd_read_operations | [Table 1. Workflow Studio roles for execution details] {#flow-execution-details__table_utq_v2r_nnb} ## Run with roles support {#flow-execution-details__section_npm_5jm_3fc} When a flow runs with one or more privileged roles, a user must also have these privileged roles to see the flow execution details. For example, if a flow runs as System, then a user must have the admin role to view its flow execution details. In addition, if a flow runs with a role that can access field encryption, then a user must also have that role in order to view its flow execution details. For more information about field encryption and roles, see [Field Encryption](https://www.servicenow.com/docs/access?context=field-encryption&version=australia&pubname=australia-platform-security&ft:locale=en-US).