Differences Between Audit and History Sets

  • Release version: Yokohama
  • Updated June 3, 2026
  • 2 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 Differences Between Audit and History Sets

    In ServiceNow, the Audit [sysaudit], History Set [syshistoryset], and History [syshistoryline] tables all store historical data but serve distinct purposes and manage data differently to optimize performance and usability.

    Show full answer Show less

    Audit [sysaudit] Table

    The Audit table retains comprehensive historical data for all records indefinitely, allowing administrators to track all audited record changes over time. However, as the volume of audit records grows, querying this table directly becomes inefficient.

    History Set [syshistoryset] and History [syshistoryline] Tables

    • The History Set table identifies specific records from audited tables that have historical data, while the History table stores the actual field value changes.
    • These tables hold a recent subset of history relevant to records for which users have created or requested history, rather than the complete audit history.
    • History Sets include additional data such as journal field entries made during record creation, showing them with the same timestamp and creator as the record itself.
    • To manage storage, History Sets are automatically cleaned if not updated within 30 days, and the system uses table rotation among four History tables every seven days, ensuring a maximum retention period of 21 days.
    • If older historical data is needed, it can be regenerated from the Audit table.
    • The user interface accesses History Set data for displaying history, providing the same data view as Audit records but in a more efficient format.

    Key Outcomes

    • Administrators can rely on the Audit table for complete, long-term historical tracking.
    • Users benefit from faster and more efficient access to recent history via History Sets and History tables.
    • Data retention policies ensure optimal system performance while preserving the ability to regenerate older history if required.

    The Audit [sys_audit], History Sets [sys_history_set], and History [sys_history_line] tables store the same data, but they serve different purposes and manage data differently.

    Audit [sys_audit] table

    The Audit [sys_audit] table is where the system stores historical information for all records. These records are intended to be kept forever so that administrators can always track the history of audited records. As the number of auditing records grows over time, it becomes more inefficient to directly query the Audit table for historical information. It is much more efficient to run queries only on the smaller subset records you actually want to view historical information for.

    History Set [sys_history_set] table

    The History Set [sys_history_set] table identifies which particular records from an audited table have historical information. The History [sys_history_line] table stores the actual changes to field values that occurred.
    • The system automatically generates History Set and History records as needed from the Audit table when a user either creates a record or requests its history.
    • Rather than containing a complete history of all changes in the system, History Set and History records only contain a recent subset of historical information for records where users have created or requested such information.
    • In addition to audit data, history sets also include the information that is set during record insert, including journal field entries. Journal field entries you create before creating a record are handled in the same manner as journal entries created at the time of record creation. These journal entries appear in history sets with the same creation time and created by data as the associated record itself.

    The system limits History Set and History records by:

    • Having the table cleaner delete History Set records that have not been updated in 30 days.
    • Using table rotation to rotate between four History tables every seven days. Because the platform truncates the leading table when rotation occurs, the maximum available retention period is 21 days, not 28. One of the four tables is always in the process of being cleared in preparation for the next rotation.

    Should someone need historical information again at a later date, the system can regenerate it from auditing source records.

    After the system generates History Set records, the context menu choice History uses the History Set rather than Audit records. From the user's perspective, the same historical data is available in the same user interface, but the way the information is stored is different.