In a default, out-of-box ServiceNow instance, the system is configured to audit a number of specific tables and fields.  However, in certain cases it may be necessary to disable this auditing on a certain table or field or to enable auditing on such a table or field.  This article will describe how this auditing can be enabled and disabled on specific tables or fields within a table.

There are two standard mechanisms of auditing supported by the system on a specific table, whitelist auditing, and blacklist auditing.  In whitelist auditing, the specific fields on a table which are to have modifications audited are specified.  In blacklist auditing, all fields of the table are configured to be audited, except for specific fields which are configured not to be audited.

The normal auditing mechanism will record in the auditing tables (such as sys_audit) changes in the value of a field on a specific table.

For instance, with auditing of the State field on the Incident table enabled, changing the value of the State field on an Incident record might produce an audit record similar to the following.

sys_audit record for the State field on the Incident record

This article details the general steps for auditing specific fields or specific tables.  However, in certain cases, a user might want to configure table auditing whitelist configuration instead.  Whitelist auditing is ideal in the case in which the admin wants to audit only a small number of specific fields from a certain table but not the remainder of the field on that table.  See the Additional Information section for details and instructions on how to configure and use whitelist auditing with some tables.


Auditing can be enabled or disabled at the field or table level.  The following sections will detail the steps to modify the auditing options at the table level (which will cause all fields on that table, by default, to be audited), and auditing at a field level on a particular table.

Configure Auditing for Individual Tables

A specific table on the instance can be configured to globally audit all fields on that table.  This will thus cause all non-system level fields on that table to be audited.  System fields are generally those that start with the "sys" prefix.  These steps can be performed to configure this auditing for a table on the instance:

  • Log into the instance with an account having admin rights to the instance.
  • On the instance, browse to the following location System Definition -> Dictionary
  • Filter the list to locate the record with a Table name which corresponds to the table for which you intend to enable auditing and has a Type field with a value of Collection.

Collection dictionary record for Incident

  • If the Audit column is not displayed in this list, click the cog icon to configure the list to display the Audit field.
  • Double click the Audit column corresponding to the record for which you want to modify auditing.
  • The field should then become editable.  Change the value to either true or false, depending on whether you want to enable or disable auditing for this table (use true to enable auditing for the selected table or false to disable auditing for the table).

Setting a field to not be audited

  • After making the necessary selection, click the green check icon to save the change.

Configure Auditing for Individual Fields (Blacklist Auditing)

Individual fields within a table can be configured to enable or disable auditing of any changes to that field in a record using either blacklist or whitelist auditing.  The steps below will detail blacklist auditing.

  • One way to quickly configure this can be performed with the following steps:
  • Log into the instance with an account having admin rights to that instance.
  • Using the Menu Navigator, browse to the following location on the instance: System Definition -> Dictionary.
  • A list of Dictionary records on the instance will appear.  Filter the search results to display the Table name and Field name (Column name field) for the table and field you want to modify the audit setting for.
  • The Dictionary record for the selected field should appear.  Click the related link titled Advanced view to show a more detailed display for this record.
  • Locate the Attributes text box field for this record.
    • To disable auditing for this field in this table when using a blacklist auditing scheme, add the following text to this field "no_audit=true".  If the Attributes field already contains values in the text box, add a comma after the last attribute currently found in the field and then the no_audit=true text.
    • However, if the Attributes field is currently empty, simply add the text no_audit=true into the text box. After adding this attribute click the Update button.

 Configuring a field not to be audited

To enable auditing of a field which is currently configured to not be enabled for auditing on a table that is configured for blacklist auditing, click the Attributes tab in the tabbed list near the bottom of the record.  Locate the Attribute labeled No audit and click the information icon to the left of that attribute name to open that Attribute record.

no_audit attribute

After the Attribute record opens, click the Delete button corresponding to that record.  At the Delete Confirmation dialog box that appears, click the Delete button.  This will cause the attribute to be deleted from this field.

Note, that alternatively, to enable auditing of a record that is currently set with the no_audit=true attribute, the no_audit attribute can be changed to no_audit=false.  This would also allow subsequent auditing of the selected field.

Note that table level auditing will override field level auditing.  Thus, in order for the no_audit attribute to be considered for determination of if a field should be audited, the table itself must have the Audit field set to true.  For example, if a specific field has the no_audit set to false (in order to cause changes to that field to be audited) but the table has the Audit checkbox unselected (set to false), that field on that table will not have changes to that field audited regardless of the field level audit setting.

Additional Information

As mentioned above, if an administrator prefers, he can instead use whitelisting to determine the specific fields on a certain table to audit.  This option is usually ideal when just a small subset of all the fields on a table is to be configured for auditing.  See KB Article KB0724176 - Using Field Audit Whitelists, which describes how to configure the whitelist audit configuration for a specific table.

Article Information

Last Updated:2019-08-30 02:17:19