Flow execution details retention

  • Release version: Zurich
  • Updated July 31, 2025
  • 4 minutes to read
    • Summarize
    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 Retention

    Flow execution details in ServiceNow generate significant data, which is managed through data retention policies to maintain instance performance. These policies automatically delete flow execution data after specific retention periods depending on the flow’s state and the data type. By default, execution details are only created during test runs unless flow reporting is activated.

    Show full answer Show less

    Flow Execution Data Management

    Flow execution data is organized across multiple tables, each with distinct retention periods and purposes:

    • sysflowcontext: Stores all workflow context records and associated process plans. Retention is 2 weeks for completed flows and 6 weeks for flows in error or cancelled states. Extending retention here can degrade performance.
    • sysflowcontextchunk & sysflowcontextchunkarchive: Hold runtime data for active and inactive flows respectively. Data is cleared when flows complete or are cancelled.
    • sysflowreportdoc and related chunk tables: Contain execution detail reporting data for active and stopped flows, with similar retention as sysflowcontext tables.
    • sysflowlog: Stores replicated log entries correlated with flow contexts, cleared every 28 days by default.
    • sysflowplancontextbinding: Maintains unique identifiers for flow triggers, retained for 12 months to manage "run once" or "for each unique change" conditions. Deletion of these records may cause flows to rerun.

    These tables are managed by the system’s scheduled table cleaner based on flow states and age of records. Modifying or deleting data in active state tables is strongly discouraged to avoid disrupting flow operations.

    Impact on Flow Reporting and Recovery

    If execution details are removed by retention policies, flow reports will display messages indicating missing action reports, and links to detailed action states may be unavailable. Additionally, deactivating flow reporting disables detailed execution data generation.

    To recover deleted flow execution data, customers must contact ServiceNow Customer Service and Support to request restoration from backups, subject to the supported recovery period.

    Practical Considerations for ServiceNow Customers

    • Understand that flow execution data retention balances detailed reporting capabilities with system performance.
    • Retain critical flow data only as long as necessary; extending retention periods can negatively affect performance and new flow features.
    • Activate flow reporting deliberately to generate execution details beyond testing scenarios.
    • Monitor flow reports for messages about unavailable data and use recovery options when essential data is lost.
    • Do not manually alter or delete data in active flow tables to maintain system integrity.

    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 1. Flow reporting data tables
    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.
    • 2 weeks for completed flows
    • 6 weeks for flows in the error or cancelled state
    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.
    • Continue Sync
    • In Progress
    • Queued
    • Waiting
    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.
    • Cancelled
    • Complete
    • Error
    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.
    • 2 weeks for completed flows
    • 6 weeks for flows in the error or cancelled state
    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.
    • Continue Sync
    • In Progress
    • Queued
    • Waiting
    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.
    • Cancelled
    • Complete
    • Error
    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.
    • 2 weeks for completed flows
    • 6 weeks for flows in the error or cancelled state
    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

    A message displays at the top of the flow report to indicate that action reports are not available for a flow because of table cleanup. The Show Action Details link and Action states are not available in this case. A similar message is shown to indicate when reporting for a flow has been deactivated. In this case, a link to the report settings also displays.
    Figure 1. Sample flow execution details with data removed by the report retention policy
    Flow execution details page displaying the data retention notification, The action details for this flow have been removed according to the report retention policy.

    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.