ServiceNow auditing (history) feature for a table and troubleshoot related issues

ServiceNow's auditing feature lets you track who changed what, and when, on any table in your instance. It's the foundation for the record History you see on forms, and it's what compliance, security, and troubleshooting work all lean on. This article walks through how to enable it, what it actually captures, and how to troubleshoot it when it doesn't seem to be working — updated for current ServiceNow releases.

Enabling auditing for a table

1. Navigate to System Definition > Dictionary.
2. Filter for the table you want to audit (for example, alm_asset).
3. Open the dictionary entry for the table itself — the one with an empty Column name and a Type of Collection (not one of the individual field entries).
4. Check the Audit checkbox.
5. Click Update.

Once this is enabled, ServiceNow tracks inserts, updates, and deletions on that table and stores the changes in tables such as sys_audit, sys_audit_delete, and sys_history_set.

A few things worth knowing that weren't as relevant a few years ago:

• Many out-of-the-box tables are already audited by default. Task-based tables (Incident, Problem, Change Request, and anything extending Task) generally ship with auditing turned on. Before assuming you need to enable it, check the Dictionary entry first — it may already be set.
• Field-level (inclusion list) auditing. By default, enabling the Audit checkbox on a table audits every field except system fields (an "exclusion list" or blacklist approach — any field can be individually excluded with the no_audit dictionary attribute). If you only want to track a handful of fields on a large or high-traffic table, you can instead set audit_type=whitelist as a table attribute and then mark only the specific fields you care about as audited. This avoids bloating sys_audit with noise from fields nobody needs history on.
• Audit Management Console. Newer releases (Zurich and later) include an Audit Management Console (search "Audit Management Console" in the navigator) that gives you a single UI to see which tables are audited, toggle auditing on/off, manage which fields are included, and configure audit retention/purge policies (for example, automatically purging audit records after a set period, from one month up to seven years). This is generally a faster way to manage auditing at scale than editing individual Dictionary records.

Enabling auditing for system tables

By default, ServiceNow does not audit deletions from tables with a sys_ prefix, since many of these are high-volume internal tables. To track deletions from a system table, add the table name to the glide.ui.audit_deleted_tables system property.

Be cautious about turning on full auditing for busy system tables (for example, Workflow Context [wf_context]) — the volume of changes can create a large number of audit records and impact performance. In general, only audit system tables when you have a specific, deliberate need to track them (for example, sys_user, excluding frequently-changing fields like "Last login").

What gets recorded

When a field on an audited table changes, ServiceNow records:

• The unique record identifier (sys_id) of the record that changed
• The field that changed
• The new field value
• The old field value
• How many times that record/field combination has been updated
• The date and time of the change
• The user who made the change
• The reason for the change, if one was provided
• The record's internal checkpoint ID, if it has multiple versions

Some changes are intentionally excluded from auditing, even on an audited table:

• Changes to fields with the sys_ prefix (system fields), with the exception of sys_class_name and sys_domain_id
• Updates made by the inactivity monitor (otherwise a single stale incident could generate hundreds of noise entries)

Viewing audit history

• List view: Right-click the form header and select History > List.
• Calendar view: Right-click the form header and select History > Calendar.
• Audit History related list: Right-click the form header, choose Configure > Related Lists, then move Audit History to the Selected column and save.

One important update for current instances: these right-click context menu options (History, Configure) are part of the classic UI (UI16). If you're working in Agent Workspace or another Now Experience (UI Builder-based) workspace, that right-click menu generally isn't available — workspace record pages don't currently support the classic History Calendar or the "Configure > Related Lists" flow. If your users live in a workspace, you'll typically need to add a History-related component/list to the workspace record page in UI Builder, or have them switch to classic UI to review full history.

Troubleshooting: when auditing doesn't seem to work

Sometimes auditing looks broken — either changes aren't showing up in History at all, or they appear inconsistently. Before troubleshooting further, get clear on scope: is this happening for one specific table, or across the whole instance? A single-table issue usually points to a script or configuration problem on that table; instance-wide issues are much rarer and usually point to a property or platform-level setting.

Start with the basics

• Confirm the Audit checkbox is actually set on the table's collection dictionary entry (not just a field entry).
• If it's a system table (sys_ prefix) and you're missing delete tracking, confirm it's listed in glide.ui.audit_deleted_tables.
• Check whether the table uses whitelist auditing (audit_type=whitelist). If so, only fields explicitly marked as audited will show history — everything else is excluded by design, not by a bug.
• Confirm the field in question doesn't have the no_audit attribute set on its dictionary entry.

Check for scripts suppressing auditing

The most common cause of "auditing isn't working" on a specific table is a Business Rule, Script Include, or UI Action calling:

current.autoSysFields(false);
current.setWorkflow(false);

What these do:

• autoSysFields(false) disables updates to sys_updated_by, sys_updated_on, sys_mod_count, sys_created_by, and sys_created_on. It's typically used to update a record without disturbing its "last modified" metadata — but it also means sys_mod_count won't increment, which can affect Activity formatters, History sets, and Metrics.
• setWorkflow(false) disables the business rules that would normally fire for that GlideRecord operation — including the ones that write to sys_audit. If setWorkflow is set to false, that insert/update will not be audited.

To find where these are being called, search your Script Includes, Business Rules, and UI Actions related to the table for autoSysFields(false) and setWorkflow(false). You can disable candidates one at a time (or all at once) and retest to isolate the cause.

Use session debugging to trace it live

If scanning scripts doesn't turn up the cause, use the built-in session debugger:

1. Navigate to System Diagnostics > Session Debug, and enable:
   • Debug Business Rule (or Debug Business Rule (Details) for a more detailed trace, including field values changed)
   • Debug SQL (Detailed), if you need to see the underlying database activity
2. Update a record on the table in question (right-click the header and choose Save, if you want to stay on the same page).
3. Review the trace output at the bottom of the form:
   • === means a business rule was skipped because its condition didn't evaluate to true
   • ==> means the business rule is being entered
   • <== means the business rule is exiting

This will usually show you exactly which business rule is running (or being skipped) around the point where auditing should occur.

If you find a legitimate need to force auditing

If autoSysFields(false) or setWorkflow(false) are being used deliberately elsewhere in the platform and you can't simply remove them, but you still need that table audited in all cases, you can add a Before Insert/Update business rule on the table, set its Order higher than any other business rule on that table (so it runs last), and include:

current.autoSysFields(true);
current.setWorkflow(true);

This is a blunt, brute-force fix — it overrides any other script's attempt to suppress system field updates or workflow on that record. Use it as a last resort, understand what it's overriding, and test thoroughly, since forcing setWorkflow(true) will also re-enable any other business rules that were deliberately being skipped. If the problem persists after this, it's worth engaging ServiceNow support, since at that point the cause may be a platform-level configuration rather than something in your scripts.

---

This article reflects general auditing behavior across current ServiceNow releases. Some specifics (menu names, available consoles, default retention limits) can vary slightly by release family — when in doubt, check your instance's in-product documentation via the (?) help icon, which is tied to your specific version.