---
sourceDocument: Brazil Build workflows
sourceDocumentLink: https://www.servicenow.com/docs/r/build-workflows

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Flow execution settings

# Flow execution settings {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 settings

Flow execution settings allow you to specify runtime parameters for individual flows, subflows, or actions within ServiceNow, such as run priority, reporting level, and logging level.
These settings override system-wide reporting properties, enabling selective collection of execution details only for specific items you want to monitor.
Show full answer Show less  
Execution settings records are created per flow, subflow, or action and control how execution details are gathered and logged when these items run directly. When actions or subflows run as part of a parent flow, the parent's execution settings apply. These records are managed within the Flow administration module.

## Key Features

* **Execution Setting Fields:**
  * **Flow/SubFlow/Action:** Specifies the exact item the settings apply to.
  * **Report all iterations:** Option to collect execution details for every loop iteration instead of only the first and last iterations.
  * **Reporting:** Defines the reporting level for gathering execution data.
  * **Logging:** Sets the logging threshold for messages written to the Flow engine log entries table.
  * **Flow Priority:** Controls the priority for background flows (hidden by default, configurable).
* **Override Capability:** Execution settings override global system properties, allowing targeted monitoring without enabling reporting globally.
* **Selective Reporting:** Enables detailed execution data collection only for flows or actions under investigation.

## Best Practices

* **Avoid enabling execution reporting on production instances** to prevent performance degradation since execution detail collection consumes system resources.
* **Create and configure execution setting records** on non-production test instances to safely generate and validate execution data.
* **Limit memory usage by avoiding full iteration reporting** unless necessary, as reporting all loop iterations increases memory consumption.
* **Test flows, subflows, and actions at the debug logging level** before deploying to production, ensuring proper data generation and performance.
* **Use execution reporting and the "report all iterations" option only during troubleshooting** and disable or remove these settings afterward to reduce resource impact.  
Specify the runtime settings for an individual flow, subflow, or action such as the run priority, reporting level, and logging level.  
Figure 1. Sample execution setting record list

You can create an execution settings record for each flow, subflow, or action for which you want to collect execution details. An execution setting record \[sys_flow_execution_setting\] overrides the reporting system properties for a
particular item. For example, you can keep the system wide reporting level off, and create execution setting records just for the items that you want to collect execution details.  
You can create as many execution settings records as you like. The system generates execution details each time the flow, subflow, or action is directly run. Actions or subflows that run from a parent flow use the execution settings record of the parent flow.  
Note:  
You can call actions and subflows directly using the action API or script API.

Execution setting records are available from the Flow administration module.

## Execution setting record fields {#flow-execution-settings__section_iwg_m23_v1c}

Figure 2. Sample execution setting record

An execution setting record \[sys_flow_execution_setting\] contains these fields.  
{#flow-execution-settings__table_vdh_n13_v1c__entry__2}

| Field | Description |
|-|-|
| Flow/SubFlow/Action | Individual flow, subflow, or action to which the execution settings apply. |
| Report all iterations | Option to gather execution details for all iterations of a loop that have run rather than just storing execution details for the first and last run iterations. If a flow pauses between iterations, then the execution details include all iterations that have run. When this option is false, the execution details only include the first and last iterations run. |
| Reporting | Reporting level at which to gather execution details. |
| Logging | Logging level threshold required for Workflow Studio to write a message generated by the flow engine to the Flow engine log entries \[sys_flow_log\] table. |
| Flow Priority | Priority value used to run a background flow. For more information about setting flow priority, see [Flow priority](https://www.servicenow.com/docs/2NcqUmKf2iDgMl_32OE~Lw "Specify the priority that you want a background flow to have in relation to other flows waiting to be run. Run a group of higher priority flows before running any lower priority flows."). Note: This field is hidden by default. For more information about showing the flow priority field, see [Show flow priority field](https://www.servicenow.com/docs/KK7SxnOiiAtj3BtGQjZTQQ "Configure the Setting list and form to show the Flow Priority field.").. |
[Table 1. Execution setting record fields]

{#flow-execution-settings__table_vdh_n13_v1c}

## General guidelines {#flow-execution-settings__id_bwc_fj3_v1c}

Use these general guidelines when creating execution setting records to capture execution details.

Avoid reporting on production instances
:   Avoid performance issues on your production instance by only activating and configuring reporting on a non-production instance that you use for testing. Generating and storing execution details consumes instance
    resources, which can lower performance.

Create execution setting records on a non-production test instance
:   Create execution setting records on a non-production testing instance to minimize the performance impact of generating and storing execution details.

Reduce the amount of memory consumed by flow loops
:   Reduce the amount of memory consumed by generating execution details by not using the option to report all iterations. The more iterations you report on, the more memory is required.

Test flows, subflows, and actions to generate execution details
:   Test your flows, subflows to generate execution details at the debug level. Only deploy your items to a production instance after you verify that they generate the data you want and that they perform as expected.

Use flow reporting and the report all iterations options only during flow troubleshooting
:   Use the flow reporting and report all iterations options only when you need to troubleshoot a flow. These settings generate information that consume instance resources. To reduce their performance impact, either turn off
    these settings or delete the settings record altogether when you are done troubleshooting the flow.

