Perspectives on Security in HRSD: Access Control Lists

As touched upon in one of our previous blogs, Perspectives on Security in HRSD: COE Security Policies, Access Control Lists (ACLs) are the standard mechanism ServiceNow uses to govern access to records. Think of them as gatekeepers, determining permissions for various actions (read, write, create, delete, and so on) for both data and individual attributes (e.g., the HR case and the number field).

Reflecting on my experience as an HRSD Architect, time and time again I have encountered client environments where out-of-the-box HRSD security has been modified, leading to technical debt that compounds. My goal in this blog is to shed light on how HRSD security is built out-of-the-box and when it is (and isn’t) appropriate to customize it. 

📦 Understanding the Out-of-Box HRSD Security

There are an astonishing number of HR ACLs—numbering in the hundreds depending upon what plugins you have active—that can make implementing new security intimidating for developers. In this discussion, I will focus on the HR case tables, as they present the most complexity (in contrast, tables like HR Profile have a simpler structure that’s easier to manage and extend).

🔄 How Case ACLs Process Requests

1. Licensing Validation:

Each case table first runs a check through the hr_license script include, verifying whether the Center of Excellence (COE) you’re trying to access is active.

2. Impersonation Check:

Next, if configured, the system checks impersonation status (whether you're viewing as yourself or another user). This is often a source of test failures for clients—check the sn_hr_core.impersonateCheck system property to see if it’s enabled. It’s strongly recommended to have this active in production and disable it temporarily during testing.

3. Access Check via Script Include:

Lastly, the system runs access checks using the hr_Case script include, which calls another script include, hr_SecurityUtils, for complex checks. These cover various conditions—such as your relationship to the case (e.g., subject person, agent), whether there are tasks or approvals involved, and whether you've been delegated the case.

4. Field-Specific ACLs:

On top of these checks, specific field ACLs verify impersonation status again and assign access based on roles (e.g., certain fields may be restricted to agents rather than employees).

The Bottom Line

HR case ACLs rely on hundreds of lines of carefully crafted code—avoid altering them directly whenever possible. The underlying script includes are updated frequently in upgrades—updating them can cause issues across numerous areas of HRSD.

🔒 Safe Avenues for Security Updates

While modifying HRSD’s default security can lead to significant maintenance challenges, there are safer ways to tailor the system to your needs:

1. Leverage Configuration Points:

Use built-in configuration options like COE settings and the impersonation system property to control behaviors instead of direct ACL modifications.

2. Utilize COE Security Policies:

As discussed in our previous blog, COE Security Policies offer a flexible way to control access to different types of cases. Take full advantage of these policies when designing HR case security.

3. Create New ACLs for Case Fields:

• Ensure you include impersonation checks.

• Add ACLs when you want specific information to be visible only to agents or higher roles.

• Evaluate whether new fields genuinely need additional security—if access to the case is already limited, extra ACLs may not be necessary.

4. Add New ACLs for Non-Agent Roles:

• For instance, if you’re granting access to department leaders, be sure to incorporate impersonation checks to prevent security gaps.

• Always create new ACLs rather than modifying existing ones to avoid tampering with the underlying script includes.

• Consider how new logic will coexist with existing rules—your goal should be to grant additional access, not to remove or alter baseline access.

Conclusion

Customizing HRSD's ACLs should be a rare occurrence, as there are often better, more configurable alternatives available. However, navigating security in HRSD can be tricky. If you need more detailed guidance or want to discuss your specific challenges, feel free to request a meeting —we’re here to help!