---
sourceDocument: Brazil Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Differences Between Audit and History Sets

# Differences Between Audit and History Sets {#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 Differences Between Audit and History Sets

The Audit, History Set, and History tables in ServiceNow store record change data but serve distinct purposes and manage data differently to optimize performance and usability for administrators and users.
Show full answer Show less  

## Audit \[sysaudit\] Table

This table stores a comprehensive, permanent history of all audited record changes across the system. It is designed for long-term retention, enabling administrators to track every change made. However, as the volume of audit records grows, querying this table directly becomes inefficient.

## History Set \[syshistoryset\] and History \[syshistoryline\] Tables

History Sets identify specific records from audited tables that have historical information, while History stores the actual field value changes. These are automatically generated from the Audit data when users create records or explicitly request history.

Unlike Audit, History Sets and History tables only contain a recent subset of historical data relevant to user interest, including journal field entries made during record creation. Journal entries created before record creation are treated the same as those created at the time of record creation, maintaining consistent timestamps and authorship information.

## Data Retention and Management

* History Set records not updated within 30 days are deleted by the table cleaner.
* The system uses a rotation scheme across four History tables every seven days, limiting retention to a maximum of 21 days instead of 28 days because one table is always being cleared.

If historical data beyond this retention period is needed, it can be regenerated from the Audit records.

## User Experience

When viewing record history, users interact with History Set data rather than the full Audit data. This approach provides the same historical insights via the familiar interface but improves performance by leveraging a smaller, more manageable dataset.  
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 {#c_DiffBtwnAuditHistSets__section_wvf_dfw_3mb}

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 {#c_DiffBtwnAuditHistSets__section_flt_2fw_3mb}

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.
{#c_DiffBtwnAuditHistSets__ul_jnw_3fw_3mb}

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.

{#c_DiffBtwnAuditHistSets__properties_vgd_nft_5t}

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.