Bypass sn_hr_core.impersonateCheck

[YvanMartino]

I have a select few users that need to be able to impersonate users without worrying about the sn_hr_core.impersonateCheck property being set to true.

I haven't found a recommended way of bypassing that property aside from toggling it back and forth on demand, which is going to be too cumbersome for our team, has anyone found a way that works for them?

I've considered editing the OOB Security Attribute (instead of the  100+ ACLs) to account for users that explicitly have  sn_hr_core.admin or are explicitly part of a very specific impersonator group of our creation; but we're trying to avoid editing OOB records as much as possible.

[sachinvic]

@YvanMartino 

Hi Yvan,

sn_hr_core.impersonateCheck is designed to prevent an admin from accessing sensitive HR information while impersonating another user. ServiceNow currently recommends keeping this property true, particularly in Production.

For a small group of authorized users, rather than bypassing the property or modifying the OOTB Security Attributes/100+ ACLs, first check whether the requirement can be handled through the appropriate HR roles and security configuration.

You can also identify exactly where sn_hr_core.impersonateCheck is being evaluated:

System Applications >>Studio >>Code Search

Search for:

sn_hr_core.impersonateCheck

This will show the OOTB Script Includes and ACLs that reference the property.

I would avoid changing those OOTB ACLs just to create an exception for a few impersonators. If the business requirement is to allow specific users to access HR data while impersonating, treat that as a security exception and validate the impact with ServiceNow Support before implementing a custom bypass.

FYR: https://www.servicenow.com/docs/r/platform-security/instance-security-hardening-settings/sc-check-im...

Helpful? Please mark the response as Accepted Solution ✅ and close the thread — this helps future readers find the solution faster.

Regards,
Sachinvic
✨ ArchX Certified | ✨ 16x ServiceNow AI MVP

[YvanMartino]

The need here is to allow trusted admins on the HR teams to be able to view HR data while impersonating during testing.

While I did do Studio search to track down where the property is referenced, I didn't find anything that resembled an OOB method to allow for exceptions.

The idea of editing the Security Attribute for exceptions (which really is a grasping at straws idea at this point) stems primarily from the fact editing ACLs is always a bad ide, and duplicating the ACLs themselves would make no sense maintenance wise.

About all I haven't done is speak with ServiceNow Support themselves.

[sachinvic]

Hi Yvan,

That clarification helps. The requirement is to allow only a controlled group of trusted HR admins to view HR data while impersonating, while keeping sn_hr_core.impersonateCheck = true for everyone else.

The important limitation here is that sn_hr_core.impersonateCheck is an application-level system property. When it is set to true, ServiceNow prevents HR information from being accessed while impersonating another user. The current documentation does not provide a role/group-based exception for this property.

Because of that, modifying the OOTB Security Attribute or duplicating the HR ACLs to create an exception would be a fairly invasive customization, and I would not recommend going down that route without ServiceNow guidance.

For this specific requirement, the best next step would be to raise a case with ServiceNow Support and ask whether there is a supported mechanism for a trusted HR-admin exception to sn_hr_core.impersonateCheck.

If Support confirms that no exception is supported, then the practical options are either:

• use a controlled non-production environment where the property can be disabled for testing, or
• implement a custom security solution only after understanding the impact on the OOTB HR ACL model.

So, in short: the property itself does not provide a clean “allow these users but block everyone else” configuration. I would avoid modifying the OOTB HR Security Attribute/ACLs just to achieve this exception.

https://www.servicenow.com/docs/r/platform-security/instance-security-hardening-settings/sc-check-im...

Helpful? Please mark the response as Accepted Solution ✅ and close the thread  — this helps future readers find the solution faster.

Regards,
Sachinvic
✨ ArchX Certified | ✨ 16x ServiceNow AI MVP

[sanjaygupta]

The property works as one switch for the whole application, so there is no built-in way to exempt a chosen group while keeping it on for everyone else. When it is true, ACLs refuse HR data to anyone who is impersonating. The recommended value is true, especially in Production, because it stops an admin from seeing another user’s HR information through impersonation. So your instinct to avoid editing the out-of-box Security Attribute is a sound one.

A community reply to this exact question says that changing the Security Attribute or duplicating the HR ACLs to add an exception is invasive. It suggests doing that only after understanding the impact on the HR ACL model, and ideally with ServiceNow guidance.

These are the safer routes to try first:

• Ask what the impersonators need to do. If they only need to see HR data as a given agent would, give that agent role to the trusted users directly, so they log in as themselves.
• Do impersonation-based testing in a sub-production instance, where the property can stay false.
• Turn on glide.sys.log_impersonation so any impersonation is logged.
• Keep sn_hr_core.impersonateCheck set to true in Production for everyone.
• To see exactly where the property is used, go to System Applications > Studio > Code Search and search for sn_hr_core.impersonateCheck. It lists the script includes and ACLs that reference it.

If the business insists on an exception, treat it as a security-reviewed customization. Make the change in a scoped app or update set, never directly on the out-of-box records. Add a narrow check for a dedicated group, and test it in sub-production first. The change affects a large number of ACLs, so it also needs a plan for future upgrades. I can’t confirm from the documentation that any supported per-user exception exists. 

Sources:

• Bypass sn_hr_core.impersonateCheck
• Check impersonation on ACL evaluation in HR App
• HR Security setup: (HR) Admin