Home New York Now Platform Administration Now Platform administration Platform security Auditing

Auditing

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:

The Audit table.
The History sets table.

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. The em_alert table itself can have audit=true, but the fields are not audited unless you explicitly set audit=true for a field.

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.
UI Pages can sometimes trigger updates to a record without creating an audit log.
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).

Previous topic

Next topic

Send feedback

Release version

Auditing

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

Auditing information is kept in these tables:

The Audit table.
The History sets table.

Auditing parent and child tables

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.
UI Pages can sometimes trigger updates to a record without creating an audit log.
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).

How search works:

Topics are ranked in search results by how closely they match your search terms

Auditing

Auditing

Auditing parent and child tables

Auditing system tables

Auditing deletions from a form or list

Information audited

Information exempted from auditing

Auditing a table

On this page

Auditing

Auditing

Auditing parent and child tables

Auditing system tables

Auditing deletions from a form or list

Information audited

Information exempted from auditing

Auditing a table

Log in to personalize your search results and subscribe to topics