Flow execution details retention
Summarize
Summary of Flow execution details retention
ServiceNow instances manage flow execution details data through retention policies to control storage use and maintain performance. This data, which captures details about flow runs, is automatically deleted after specified time periods based on the flow’s state and associated tables. Understanding these retention policies is essential for customers who rely on flow execution reporting for troubleshooting and analysis.
Show less
Flow Execution Details Generation
By default, execution details are generated only during flow testing. Customers can enable broader generation of flow execution details by activating flow reporting to gain more visibility into flow performance and results.
Scheduled Table Cleanup and Retention Periods
Flow execution data is stored across multiple related tables, each with its own retention timeframe and role in the flow lifecycle:
- sysflowcontext: Parent table holding flow context records and process plans; retains completed flows for 2 weeks and error/cancelled flows for 6 weeks. Extending retention here may degrade performance.
- sysflowcontextchunk: Stores runtime data for active flows; data is deleted when flows stop and archived.
- sysflowcontextchunkarchive: Archives inactive flow data; retention mirrors sysflowcontext.
- sysflowreportdoc and related chunk tables: Store execution detail reports for active and inactive flows; follow similar retention as context tables.
- sysflowlog: Contains replicated log entries linked to flow contexts; entries are removed after 28 days or when context records are deleted.
- sysflowplancontextbinding: Records unique identifiers for triggered flows to enforce “run once” or “for each unique change” conditions; retention is 12 months.
Some legacy tables such as sysjsonchunk are used for older flows and should not be modified.
Important Considerations
- Modifying retention periods, especially increasing them, can negatively impact instance and flow performance.
- Direct modification or deletion of data in active flow tables is discouraged to avoid flow errors and performance degradation.
- When execution details are deleted due to retention policies, flow reports will indicate unavailable data and disable detailed action state views.
- If retention removes unique identifiers for “run once” flows, those flows could rerun if trigger conditions occur again.
Recovery Options
If critical flow execution data is deleted, customers can contact ServiceNow Customer Service and Support to request restoration from instance backups. Recovery requests are subject to backup retention policies as described in the Now Support Knowledge Base.
Due to the large amount of data consumed by flow execution details, your instance uses data retention policies to delete this data after a set time period.
Generating flow execution details
By default, the system only generates execution details when you run a test. To generate flow execution details, see Activate flow reporting
Scheduled table cleanup
The system uses a standard table cleaner records to determine when to remove execution details. Each type of flow execution content is stored in its own table and has its own retention period. Once a record is older than its default retention period, it is deleted if it is in a completed state. To learn more about how to find and configure table cleaner records, see Table cleaner.
| Table | Description | Default retention period |
|---|---|---|
| sys_flow_context |
Parent table that stores all Workflow Studio context records and their associated process plans. Context records store the state and references to the data used to run a flow or action. See the child tables for context records in specific states. Warning:
This table doesn't support running custom business rules. Trying to gather state information from this table may cause performance issues or unexpected flow errors. |
Warning:
Deactivating or increasing the retention period of Flow Context records can negatively impact instance performance. Retaining more flow contexts can impact flow performance and the ability to use
new flow features. |
| sys_flow_context_chunk | Child table that stores context records and runtime data for currently running flows
and actions. This table replaces the sys_json_chunk table as the location to store data for
active context records. A running flow or action can be in one of these states.
Danger: Do not change or delete data in this table. Workflow Studio uses this table for flows and actions that are in an active
state. |
The system removes these records when the flow stops running and creates an entry in the sys_flow_context_chunk_archive table. |
| sys_flow_context_chunk_archive | Child table that stores context records and runtime data for flows and actions that
have stopped running. This table replaces the sys_json_chunk table as the location to store
data for inactive context records. A stopped flow or action can be in one of these
states.
Note: Workflow Studio uses this table for flows and actions that are in an
inactive state. |
Removed when the associated sys_flow_context record is removed.
|
| sys_flow_report_doc | Parent table that stores references to Workflow Studio context records that have execution detail reporting data available. See the child tables for the execution details of flows and actions in specific states. | The system removes these records when it removes the parent context record from sys_flow_context. |
| sys_flow_report_doc_chunk | Child table that stores the reporting data and execution details for currently running
flows and actions. A running flow or action can be in one of these states.
Danger: Do not change or delete data in this table. Workflow Studio uses this table for flows and actions that are in an active
state. |
The system removes these records when the flow stops running and creates an entry in the sys_flow_report_doc_chunk_archive table. |
| sys_flow_report_doc_chunk_archive | Child table that stores the reporting data and execution details for flows and actions
that have stopped running. A stopped flow or action can be in one of these states.
Note: This table replaces the sys_json_chunk table as the location to store reporting
data for inactive execution details. |
The system removes these records when it removes the parent context record from
sys_flow_context_chunk_archive.
|
| sys_json_chunk | Table that stores compiled process plans for future, running, and completed flows and actions created prior to the San Diego release. Danger: Do not change or delete data in this table. Workflow Studio uses this table for flows and actions that are in an active state. |
The system removed these records when it removed the parent record. |
| sys_flow_log | Table that stores replicated log entries from the Log [syslog] table. Enables users to correlate logs with flow contexts. | The system removes these records in 28 days when the table is rotated or when it removes the context record, whichever comes first. The table rotation on sys_flow_log is configurable. For more information, see Table rotation. |
| sys_flow_plan_context_binding | Table that stores a unique identifier for each context record and the trigger that started it. Whenever a triggering event occurs, the system calculates the unique identifier and compares it to a
sys_flow_plan_context_binding record. If the calculated unique identifier matches an existing sys_flow_plan_context_binding record, then the triggered flow is not started. Note: This unique identifier is used to
determine when to run flows with either the "run once" or "for each unique change" conditions. |
The system removes these records 12 months after creation. Important: The system may rerun flows whose unique identifier was removed by the retention policy. For example, if the trigger conditions of a "run once" flow are met, and the sys_flow_plan_context_binding
record was removed, then a new unique identifier is created and the flow runs. |
Unavailable flow data
Recovery options
Contact Customer Service and Support to restore data from an instance backup.
To know the period until which a data recovery request is accepted, see the Instance Backup and Recovery [KB0547654] article in the Now Support Knowledge Base.