How To Impersonate A User in ServiceNow

Impersonating A User In ServiceNow

ServiceNow Admins (and impersonators) can impersonate any end user in their environment, and it’s a really neat trick.

There are countless reasons to impersonate an end user.

Say an end user swears that they’re experiencing a certain issue or bug with their user account, but you’re not seeing it when you’re logged in as ‘admin’?

Just quickly jump in and impersonate that user and you’ll quickly be able to replicate their session, in real team, and see exactly what they see.

If you were to make a comment on a case when you’re impersonating a user, the system will treat that as that user making the comment. So it’s exactly like you’re logging in as them, but don’t need their password.

End users are never aware that an admin impersonated their account, as there’s no functionality to notify them.

Impersonating a user is extremely beneficial during implementations and when you’re engaging in testing. Admins should always impersonate the user that they’re building an application for, during the development and test cycles – not just waiting for production.

What us admins see, and what they (our end users) see – are sometimes completely different.

Requirements To Impersonate

Due to it’s power, the impersonate power is restricted for a very limited number of users in an instance.

Currently, only users with the admin role OR the impersonator role can impersonate a user. Not many admins realize that the impersator role exists, but it does an we need to all be aware of who has it.

We can to make sure that the right people are able to impersonate, so be very careful when giving the “impersonator” role out to users.

In order to impersonate a user account, that user account must have a user id value, it can’t be empty.

The user must be an active user that’s not locked out. If you try to impersonate a locked out or inactive user, ServiceNow will automatically log you out of your session on top of not allow you to impersonate this user.

How To Impersonate A User

Role required: Admin or Impersonator

1) Login under an admin account, and go to the right, on the top banner, click “Impersonate User”

2) After selecting “Impersonate User” and a Modal Window will pop up in the middle of the UI

3) Select the user to impersonate, and the session will be automatically routed to being logged in as that user – no password needed

4) Once you’re done – select “End Impersonation” and you’ll be redirected back to your true user account. The admin account that you orignally were using.

5) There are logs that are thrown in System Logs  [sys_log], documenting all of this. They look like the below, with a source of “Impersonation”

System Logs Related To Impersonating A User

When you impersonate a user in ServiceNow, there are logs in the background that indicate who is doing the impersonation, when they’re doing it and who they’re impersonating.

The logs also indicate when the impersonation begins, and when it ends.

Not many admins know that you can actually turn this logging off.

Not sure why ServiceNow would allow admins the ability to prohibit logs from being created around impersonating users, during interactive sessions – but they do.

If you want to turn this logging off – navigate to the System Property (glide.sys.log_impersonation) and turn the value to false. It should be defaulted to true. And if the System Property doesn’t exist in your environment, you can create it and the system will know how to handle it automatically.

Interactive vs. Non-Interactive Impersation

When most admins think of impersonating an ITIL or end user in ServiceNow, they’re probably thinking about a manual impersonation which is the most likely scenario for impersonating.

But there is actually the ability to perform non-iteractive logging.

ServiceNow Admins can engage non-interactive logging in the system via scripts and automation, it doesn’t have to be only through the ServiceNow UI.

We rarely see this sort of behavior occur in ServiceNow.

So if you know that the only impersonating you’re going to be doing in the system is manual/UI based impersonation of end users. You can actually revoke the ability for non-interactive sessions to impersonate users.

Navigate to the System Propert (glide.sys.log_impersonation.non_interactive.exclusion) and change the value field to false.

This will stop any impersonations that are not UI based.

How Application Scope Is Handled While Impersonating A User

If you don’t have scoped applications – then this section won’t apply to you.

But as scoped applications are becoming more popular – more admins are going to need to understand how this works.

When an admin impersonates a user, if they have any “scope protected” roles, those are NOT granted or accessible to the impersonating user.

So for example, say that I am an admin, and I’m impersonating a user that is an HR Admin, in the scoped HR Case Administration Application.

I will still be able to impersonate the user, but I will not be able to view data or have application access that is granted by their HR related, scope-protected roles. This setting, of whether or not to allow admin access to a scoped application, is found directly on the scoped application record settings.

You should consider turning this feature on, or double checking it from a security perspective, if you have scoped applications in your environment.

Final Thoughts

There will always be situations for admins to impersonate an end user.

I still impersonate users for testing on a near daily basis.

When do you impersonate users?

Is there anything else your company does related to this process that wasn’t mentioned in the post?

Let us know.