Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.


Log in to subscribe to topics and get notified when content changes.


Track record changes on auditing-enabled tables. By default, the system tracks changes to the incident, change, and problem tables, among others.

Enabling auditing tracks the creation, update, and deletion of all records in the table. If you just want to audit individual fields in a table, you can hide fields you do not want to track using a dictionary attribute.

Auditing information is kept in these tables:
Caution: Auditing certain system tables that receive a large amount of traffic, such as Workflow Contexts [wf_context], can impact performance and is not recommended.

Auditing parent and child tables

Tables do not derive the audit flags from parent or child audited tables. For example, if you enable auditing for the cmdb_ci table, only CI's stored in that base table are audited. Likewise, if you enable auditing for the cmdb_ci_computer table, only the computer CI records are audited, including any fields on the cmdb_ci_computer table that are derived from the cmdb_ci table.

Auditing system tables

By default, the system does not 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

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 audit is checked on the table dictionary and the table is not listed in the property glide.db.audit.ignore.delete.

Information audited

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.

Information exempted from auditing

Some updates are not audited despite enabling auditing on a table. This is why 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 made through import sets.
  • Records in parent or child tables.
  • Fields with the no_audit dictionary attribute.
  • System tables 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.
  • Any time an inactivity monitor touches a record. This prevents you seeing possibly hundreds of updates listed against an incident, with the noise drowning out the useful data.

Auditing a table

For instructions on how to audit a table, see Enable auditing for a table.
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 do not want to include. This is appropriate when you want to audit most, but not all, fields and is referred to as blacklisting. For more information, see Exclude a field from being audited (blacklisting).
  • You can enable auditing for the table but only for specified fields. This is appropriate when you want to audit only a small number of the table's fields and is referred to as whitelisting. For information on how to include a field using whitelisting, see Include a table field in auditing (whitelisting).