Bypass sn_hr_core.impersonateCheck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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.
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
