Differences Between Audit and History Sets

  • Release version: Australia
  • 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 Sets [syshistoryset], and History [syshistoryline] tables all store historical data for records but serve different purposes and handle data differently. Understanding these differences helps administrators efficiently track and access record change histories.

    Show full answer Show less

    Audit [sysaudit] Table

    This table stores comprehensive historical information for all audited records and is designed to retain data indefinitely. However, as the volume of audit records grows, querying this table directly becomes inefficient for retrieving historical data.

    History Set [syshistoryset] and History [syshistoryline] Tables

    • Purpose: History Sets identify specific records with historical information, while History stores the actual changes to field values.
    • Data Scope: They contain a recent subset of history for records where users have created or explicitly requested history, rather than the full audit trail.
    • Additional Data: They include audit data plus journal field entries created during record insertion, with journal entries timestamped and attributed to the record creation.
    • Data Management: History Set records that remain unchanged for 30 days are deleted by the table cleaner. The platform uses table rotation among four History tables every seven days to manage storage, limiting retention to approximately 21 days.
    • Regeneration Capability: If historical data is needed beyond the retention period, it can be regenerated from the Audit table.
    • User Experience: When users access history via the context menu, they view History Set data rather than the full Audit records, providing the same interface but optimized data retrieval.

    What This Means for ServiceNow Customers

    Administrators can rely on the Audit table for complete, long-term historical data but should use History Sets for more efficient, recent history access. The platform’s automatic management of History Sets through deletion and rotation optimizes performance while ensuring historical data can be regenerated if needed. This approach balances comprehensive record auditing with practical usability for day-to-day history review.

    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.