---
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


---

# Exploring Auditing

# Exploring Auditing {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 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 Exploring Auditing

Auditing in ServiceNow tracks changes to records on enabled tables, including creation, updates, and deletions.
By default, auditing is active on key tables like Incident, Change, and Problem.
This capability helps you monitor data modifications for compliance, troubleshooting, and operational oversight.
Auditing stores change information in specific audit-related tables and supports selective field tracking to optimize performance and relevance.
Show full answer Show less  

## Auditing Scope and Configuration

* **Table and Field Auditing:** Auditing applies only to tables explicitly enabled and does not inherit audit settings from parent or child tables. For example, enabling auditing on *cmdbci* audits only that base table, while enabling it on *cmdbcicomputer* audits computer CIs and their specific fields.
* **System Tables:** By default, deletions on system tables are not audited. To audit deletions, you must add the table to the `glide.ui.auditdeletedtables` system property list.
* **Selective Field Auditing:** You can audit all fields in a table or limit auditing to specific fields by either excluding certain fields (exclusion listing) or including only selected fields (inclusion listing). This is important to reduce performance impact and focus on critical data changes.

## Performance Considerations

Auditing tables with high transaction volumes, such as workflow contexts or event management alerts, can degrade system performance. To mitigate this, audit only essential fields rather than entire high-traffic tables.

## Audit Data Captured

When enabled, auditing records the following details for each change:

* Unique record identifier (sysid)
* Changed field name
* Old and new values
* Number of updates on the field
* Timestamp of change
* User who made the change
* Reason for change, if provided
* Internal checkpoint ID for versioned records

## Exemptions and Limitations

Certain updates are excluded from auditing even if auditing is enabled:

* Changes from upgrades or import sets
* Records in parent or child tables not explicitly audited
* Fields marked with the `noaudit` dictionary attribute
* System fields prefixed with `sys`, except `sysclassname` and `sysdomainid`
* Updates triggered by UI Pages or inactivity monitors
* Manual changes to Performance Analytics scores

## Auditing Deletions

By default, deletions are audited when performed from a form, unless the table's `noauditdelete` attribute is set. Deletions from lists are audited only if auditing is enabled on the table and the table is not listed in the `glide.db.audit.ignore.delete` property, which requires manual configuration.

## Improved Audit Reliability

Starting with the Brazil release, audit records are created immediately within the same transaction as the record change, reducing the chance of losing audit data due to transaction cancellations. This enhanced audit process is enabled by default, controlled by the `glide.db.audit.lazy` property (defaulting to False). If this property is set to True, the enhanced auditing is disabled. It is recommended to remove this property to benefit from reliable audit logging.  
Track record changes on auditing-enabled tables. By default, the system tracks changes to the incident, change, and problem tables, among others.{#exploring-auditing__audit-desc}

Enabling auditing tracks the creation, update, and deletion of all records in the table. If you want to audit individual fields in a table, you can hide fields you don't want to track using a dictionary attribute.  
Auditing information is kept in these tables:

* The [Audit](https://www.servicenow.com/docs/Gosj_O~Vp6dxDpmJExET3Q#c_UnderstandingTheSysAuditTable "The ServiceNow AI Platform tracks inserts and updates to audited records in the Sys Audit (sys_audit) and Audit Relationship Change (sys_audit_relation) tables.") table.
* The [Knowing about History sets](https://www.servicenow.com/docs/zKRx9mny3DymWF7x4_k5XQ "The system automatically generates History Set records as needed from the Audit table when a user either creates a record or views its history.") table.
{#exploring-auditing__ul_hxz_g2l_sq}  
Warning:  
Auditing system tables that receive a large amount of traffic, such as workflow Contexts \[wf_context\] or Event Management Alerts \[em_alert\], can impact performance. For this reason, you can't audit the em_alert table as a whole. Instead, audit selected fields of interest. Set audit=true on both the em_alert table and the selected fields. Try to audit as few fields as possible.

## Auditing parent and child tables {#exploring-auditing__section_uy3_qlm_ryb}

Tables don't derive the audit flags from parent or child audited tables.

* For example, if you enable auditing for the Configuration Items \[cmdb_ci\] table, only CIs stored in that base table are audited.
* Likewise, if you enable auditing for the Computers \[cmdb_ci_computer\] table, only the computer CI records are audited, including any fields on the Computers \[cmdb_ci_computer\] table that is derived from the Configuration Items \[cmdb_ci\] table.
{#exploring-auditing__ul_om2_kxt_h4b}

## Auditing system tables {#exploring-auditing__section_vy3_qlm_ryb}

By default, the system doesn't audit the deletion of a record from system tables. To audit a system table, add it to the list of tables in the glide.ui.audit_deleted_tables property list.

## Auditing deletions from a form or list {#exploring-auditing__section_wy3_qlm_ryb}

By default, the system audits deletions of individual records from a form. To prevent auditing, set the table's dictionary attribute no_audit_delete.  
The system audits deletions from a list when it audit is selected on the table dictionary, and the table isn't listed in the glide.db.audit.ignore.delete property.  
Note:  
By default, the glide.db.audit.ignore.delete property isn't present in the System Property \[sys_properties\] table. To change the property, and its associated values, you must first manually add it. However, when manually added, it overwrites the following default values:

`glide.db.audit.ignore.delete =
sys_mutex,sys_db_cache,sys_lucene_block,sys_lucene_file,sys_lucene_directory,sys_user_preference,sys_audit,sc_cart,sc_cart_item,sys_trigger,wf_context,wf_activity,wf_condition,wf_executing,wf_history,wf_log,wf_transition,wf_transition_history,
cmdb_ci_windows_service, cmdb_sam_sw_install, cmdb_software_instance, cmdb_sam_sw_usage, sam_sw_counter_detail`

To learn more about adding system properties, see [Add a system property](https://www.servicenow.com/docs/access?context=t_AddAPropertyUsingSysPropsList&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US)

It is to be noted that by default, the audit deletes are enabled whether the record is deleted from the form view, list view, or through a script/scheduled job.

## Information audited {#exploring-auditing__section_xy3_qlm_ryb}

Auditing tracks the following record changes:

* Unique Record Identifier (sys_id) of the record that changed
* Field that changed
* New field value
* Old field value
* Number of times this record and field have been updated
* Date and time when the change occurred
* User who made the change
* Reason for the change (if any reason is associated with the change)
* Internal checkpoint ID for the record, if the record has multiple versions.
{#exploring-auditing__xn5_wdc_tw}

## Information exempted from auditing {#exploring-auditing__section_yy3_qlm_ryb}

Some updates aren't audited despite enabling auditing on a table. For example, you may see 132 updates in a record's history, but only seven audited ones.  
Auditing excludes the following information:

* Updates made by an upgrade.
* Updates are made through import sets.
* Records in parent or child tables.
* Fields with the no_audit dictionary attribute.
* System tables are not listed in the glide.ui.audit_deleted_tables property list.
* Fields that begin with the sys_ prefix (system fields), except the sys_class_name and sys_domain_id columns.
* UI Pages can sometimes trigger updates to a record without creating an audit log.
* Anytime an inactivity monitor touches a record. It prevents you seeing possibly hundreds of updates listed against an incident, with the noise drowning out the useful data.
* Manual changes to Performance Analytics scores.
* Applying Update Set
* Import XML
{#exploring-auditing__vrs_dfc_tw}

## Auditing a table {#exploring-auditing__section_zy3_qlm_ryb}

For instructions on how to audit a table, see [Configuring auditing for a table](https://www.servicenow.com/docs/okNflsWYZt25aLpQoK0FMA "You can enable table auditing to track changes to all or some of the table's fields.").  
By default, the system tracks all fields in an audited table. You can audit a subset of fields in a table in one of two ways:

* You can enable auditing for the entire table, then exclude those fields you don't want to include. It's appropriate when you want to audit most, but not all, fields, and is referred to as an exclusion listing. For more information, see [Exclude a field from being audited (exclusion listing)](https://www.servicenow.com/docs/u4U_I_SMScoqNtF_zIG3AQ "Prevent the ServiceNow AI Platform from tracking a subset of fields in an audited table by excluding those fields from an audit.").
* You can enable auditing for the table, but only for specified fields. It's appropriate when you want to audit only a small number of the table's fields and is referred to as an inclusion listing. For information on how to include a field using an inclusion listing, see [Include a table field in auditing (inclusion listing)](https://www.servicenow.com/docs/OTPcLI5uaRQ~lUhRs5EmuQ "Track a subset of fields in an audited table by add those fields to an inclusion listing.").
{#exploring-auditing__r2d_1zb_tw}

## Non-cancellable audit records {#exploring-auditing__section_gjw_slm_nzb}

Reduce the chances of audit records not being recorded when a transaction is canceled with the new default setting.  
Audits have been set to create a record immediately in the same transaction with the target record write operations. If the target record gets deleted, the audit still gets created and retained under NCA Test Audit Delete module.  
Note:  
The enhanced audit process is enabled by default. If the `glide.db.audit.lazy `property is set to `True`, the enhanced audit process is disabled.
Prior to Brazil release, if a transaction is cancelled, certain auditable operations were missed being recorded. This is because the platform executes some operations between the record change and is cancelled before audit creation. But, now audits are created immediately after the record is changed, reducing the chances of a cancelled transaction aborting the operation before the audit is recorded.  
Audits are now recorded in the same thread as the transaction. Earlier audits were created in a background thread. This change redefines the default value of the `glide.db.audit.lazy` property from True to False. This property is not usually defined in the Properties table because the majority of instances start using the new default value and behavior. On some instances, this property might be already present and set as True, which means that these instances won't be able to use this change to audit behavior.  
Note:  
It is recommended to delete this property to leverage the update.