Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store

Auditing and history sets

Auditing and history sets

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

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 inherit 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 records 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 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:
  • The Unique Record Identifier (sys_id) of the record that changed
  • The field that changed
  • The new field value
  • The old field value
  • The number of times this record and field have been updated
  • The date and time when the change occurred
  • The user who made the change
  • The reason for the change (if any reason is associated with the change)
  • The record's internal checkpoint ID (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:
  • Any updates made by an upgrade.
  • Any updates made through import sets.
  • Any records in parent or child tables.
  • Any field with the no_audit dictionary attribute.
  • Any system tables not listed in the glide.ui.audit_deleted_tables property list.
  • Any field that begins 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).

Differences Between Audit and History Sets

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.

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

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.

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. This means the system drops History records that are older than 28 days.

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.

Changes to site functionality will be made starting around 6am on January 21st (Pacific Time) and lasting approximately 6 hours.  The site may be intermittently unavailable.