Disclaimer – This article is part of a series exploring the new features and capabilities introduced in the Australia release. Since we’re still in the Early Availability (EA) phase, things may change before General Availability (GA).
The Australia Release introduces much-needed transparency for user impersonations, particularly within your audit records.
Previously, tracking down impersonations and changes done while being impersonated took some investigative work. Now, ServiceNow provides a dedicated table for impersonation events and allows you to track impersonator actions directly in your audit logs. Let's look at how these two new features work.
Log impersonation history
This feature gives you a new table storing all impersonation events. It shows exactly who impersonated whom, alongside the start and end times. You no longer need to build custom reporting to capture this data.
Navigate to “All > System Logs > User Impersonation” or directly use the User Impersonation History [sys_user_impersonation_history] table.
This feature is controlled by the System Property identity.impersonation.history.enabled and is enabled by default.
The new table also logs the session ID. When you open a specific Impersonation History record, you can view the related transaction logs right there. This means you don't just see who initiated an impersonation, you can see exactly what they did during that session.
Impersonation tracking in audit logs
This brings us to the second feature, which provides even deeper visibility into the actions taken while impersonating a user.
Historically, looking at a sys_audit record didn't immediately tell you if a change was made by the actual user or by some user impersonating them. You had to cross-reference transaction logs and events to find out. The Australia release solves this by directly storing this information in the audit record.
Let’s look at an example:
Imagine the System Administrator impersonates Able Tuter and changes the Business Criticality of the SAP Payroll Service from "1 – most critical" to "4 – not critical".
Without impersonation tracking in audit logs, the sys_audit record for this change looks like this:
Notice that Able Tuter is listed in both the User and Created by fields.
To change this behavior, we need to enable impersonation tracking in audit logs. This is not enabled by default, so you must first create a system property called glide.audit.track_impersonation and set it to true.
Once this feature is enabled, let's say the System Administrator impersonates Able Tuter again to change the Business Criticality back. The new sys_audit record now looks like this:
The Created by field still lists Able Tuter, but the User field now contains a Sys ID. This references a Sys Audit Identity [sys_audit_identity] record, which shows that the change was actually made by the System Administrator.
If you manage a ServiceNow instance and want a clearer, more transparent audit trail, enabling this feature should be on your to-do list once you upgrade to the Australia release.
7 Comments
