Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Impersonate a user

Log in to subscribe to topics and get notified when content changes.

Impersonate a user

Administrators can impersonate other authenticated users for testing purposes and view impersonation logs. The impersonation option is not visible in the mobile view of the platform.

When impersonating another user, the administrator has access to exactly what that user can access in the system, including the same menus and modules. The instance records anything the administrator does while impersonating another user as having been done by that user.

Impersonation limitations

  • When you impersonate any user, all scope-protected roles and encryption context roles are removed from the user being impersonated. However, if the impersonating user (the admin, for example) has a scope-protected role, that role is not removed from the list of roles for the user being impersonated.
  • When you impersonate a user with an application-specific admin role (for example, an application admin for Human Resources or Security Incident Response), you cannot access features granted by the application admin role, including security incidents, profile information, or other scope-protected features, unless you already have those roles. Access to modules and applications in the navigation bar is also restricted. Admins cannot change the password of any user with an application admin role.
  • Impersonating a user is not supported for mobile phones. For most mobile phones, however, you can impersonate a user by switching to standard view, performing the impersonation, and switching back to mobile view. Some mobile devices may have problems rendering the Impersonation dialog.

Impersonation requirements

The user account to be impersonated must have a user ID. You can find this ID in the User [sys_user] record for the account. If this value is missing, the message The user you selected could not be impersonated appears.

You need several different logins to test the system:

  • An admin account to do work.
  • An itil (or similar) login to test as a technician.
  • An ess login to test as an end user.

More logins may be required to adequately test the system.

Note: When you impersonate a user who is locked out or is inactive, the system forces a logout after you generate an event or click a link. All changes made while using impersonation affect the current session. Make sure you properly logout, then login after impersonation is completed.

Impersonate a user in UI16

You can select a user or enter a different user name to perform impersonation.

Before you begin

Role required: impersonator


  1. In the banner frame, click your user name to open the user menu.
  2. Select Impersonate User.
    The Impersonate User dialog box appears.
  3. Select a user from the Recent Impersonations list or enter a different user's name in the user selection field.
  4. To return to your original login, follow these same steps then select your name from the list.

Impersonate a user in UI15

You can click the impersonate icon and select a user name to perform impersonation.

Before you begin

Role required: impersonator


  1. Click the impersonate icon (UI15 impersonate icon) in the banner frame.
    The Impersonate User dialog box appears.
  2. Select the user from the Recent Impersonations list, click the lookup icon and select the user's name from the full list, or type the user's name.
  3. Click OK.

Impersonation logs

Impersonations are logged in the System Log.

Log impersonations for either interactive (UI) or non-interactive sessions.

Impersonation logging for interactive sessions

Interactive sessions are performed through the user interface (UI). Enable or disable impersonation logging for interactive sessions using the glide.sys.log_impersonation property.

If you enable impersonation logging for interactive sessions by setting glide.sys.log_impersonation to true, all interactive sessions are recorded in the impersonate log.

Property Description
glide.sys.log_impersonation Enables (true) or disables (false) impersonation logging for interactive sessions.

Impersonation logging for non-interactive sessions

Non-interactive sessions are performed by applications and scripts, not through the UI.

Impersonation logging of non-interactive sessions is turned off by default. If you enable impersonation logging by setting the glide.sys.log_impersonation.non_interactive property to true, impersonations of non-interactive sessions are recorded in the impersonate log.

Even with glide.sys.log_impersonation.non_interactive set to true, the system does not log certain common impersonation tasks performed on behalf of the default users (system, soap.guest, and guest) because the application impersonates those default users to perform a variety of tasks.

Use the glide.sys.log_impersonation.non_interactive.exclusion property to exclude impersonations by other users in addition to the default users.

Property Description
glide.sys.log_impersonation.non_interactive Enables (true) or disables (false) impersonation logging for non-interactive sessions.
glide.sys.log_impersonation.non_interactive.exclusion Excludes impersonation logging of non-interactive sessions for specified users.

Enter user names as a comma-separated list. Default users (system, soap.guest, and guest) do not need to be included in the list.

Force logout

In some cases, impersonating a user might cause an issue that makes it difficult to switch back (for example, if in a test environment, the user is being presented with a broken page).

To return to the user, navigate to http://<instance name> and log back in.