Impersonating users

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Impersonating users

    ServiceNow administrators can impersonate other authenticated users to test system behaviors and access the platform exactly as the impersonated user would. This includes seeing the same menus and modules. Actions taken during impersonation are recorded as if performed by the impersonated user, providing a reliable testing environment.

    Show full answer Show less

    Key Features

    • Access Scope and Roles: Impersonation supports scope-protected roles and encryption module roles when configured via module access policies. However, impersonating users with admin roles restricts access to some features unless the impersonator also holds those roles.
    • Role-Specific Limitations: Application-specific admin roles (e.g., Human Resources admin or Security Incident Response) limit access to certain features and modules during impersonation unless these roles are assigned to the impersonator.
    • Session and Logging: Impersonation ends when switching to another user or logging out. ‘Impersonate Begin’ and ‘Impersonate End’ events are logged in the system log for audit purposes.
    • Mobile Support: Impersonation is available on ServiceNow mobile apps, allowing testing on mobile platforms.
    • Visibility Management: An administrator must enable the impersonation feature before users can use it.

    Practical Requirements and Considerations

    • The user account to be impersonated must have a valid user ID in the system. If missing, impersonation is not possible.
    • Multiple user accounts (e.g., admin, ITIL technician, end user) are recommended for comprehensive testing.
    • Impersonating locked-out or inactive users will automatically log out the impersonator upon any action.
    • Changes made during impersonation only affect the current session and do not persist after logging out.
    • For accuracy, it is best practice to log out and log back in after completing impersonation.

    Key Outcomes

    By using impersonation, administrators can accurately test user experiences across roles and applications without affecting actual user data permanently. This feature aids in troubleshooting, validating permissions, and ensuring proper functionality from various user perspectives while maintaining security and audit trails.

    Administrators are able to impersonate other authenticated users, a feature primarily used for testing.

    This function enables the administrator to access the system exactly as the impersonated user, including identical menus and modules. All actions performed by the administrator during impersonation are recorded as if they were executed by the impersonated user.

    Impersonation example

    Impersonation limitations

    When you impersonate a user, all scope-protected roles and encryption module roles are supported if the Impersonation option is configured in the module access policy. See Create a module access policy for details.

    Impersonating a user enables access to scope-protected and encryption roles, as defined in the access policy. However, if impersonating a user with an admin role, access to certain features and modules is limited unless the impersonator already possesses those roles.

    Impersonating a user with an application-specific admin role, like Human Resources admin or Security Incident Response, limits access to certain features such as security incidents and profile information, unless these roles are already assigned to the impersonating admin. This restriction extends to certain modules and applications in the navigation bar, and admins can’t change the password of users with application admin roles.

    The following actions or conditions cause a user impersonation to end:
    • The user impersonates a different user
    • The user session ends, for example after a user logs out of their instance
      Note:
      When an administrator starts impersonating a user, the 'Impersonate Begin' event is logged in the system log. Similarly, the 'Impersonate End' event is recorded when impersonation concludes under one of the two conditions listed above.

    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 accounts to test the system.

    • An admin account to do work
    • An information technology infrastructure library (ITIL), or similar, account to test as a technician
    • An ESS account to test as an end user
    More logins may be required to adequately test the system.
    Note:
    If you try to impersonate a user who is either locked out or inactive, the system will automatically log you out if you initiate an action or select a link. Remember that all changes made during impersonation only apply to that session. To help ensure accuracy, log out and then log back in after completing the impersonation.

    Mobile impersonation

    Mobile impersonation is available on ServiceNow mobile apps. For information on mobile impersonations, see Mobile impersonation.