How to Debug the ACLs Like a Pro developer in ServiceNow

[Sagar Pagar]

How to Debug the ACLs Like a Pro developer in ServiceNow

Access Control Lists (ACLs) are one of the most powerful - most misunderstood - and difficult to troubleshoot in ServiceNow. Most developers treat them as trial-and-error rules instead of understanding that ACLs follow a fixed order and clear security rules.

This post walks through how ACLs really work, how to debug them step by step, and how to avoid common mistakes that can lead to security or performance issues.

1. Understand the ACL Evaluation Order

Before debugging the ACLs, it’s important to understand how ServiceNow evaluates them.

ACL Evaluation Order:

1. Table ACLs
• table.None
• table.read | write | create | delete
2. Field ACLs
• table.field.read | write
3. Roles
4. Conditions
5. Scripts
6. Requires All (AND) vs Requires One (OR)

Note: Failure at any point = access denied

Tip:

If you don’t know this order, debugging ACLs becomes very difficult — just like debugging code without knowing how it runs.

2. Turn On Security Debugging Tool

Enable Security Debugging

To start debugging ACLs, navigate to Application navigator:

System Security ---> Debugging ---> Debug Security Rules

OR

You can also turn on debugging by adding &sysparm_debug=security to the URL.

What we will see

Security debugging shows:

• Which ACLs were checked

• Which ACLs failed

• Why the ACL failed, such as:

  • A required role is missing

  • A condition did not pass

  • A script returned false

Tip:
Always test ACLs in a new browser window or incognito mode to avoid using cached roles.

3. Identify Which ACL Is Blocking You

A common mistake many developers make is thinking:

“My script is wrong”

In reality, the script may never run at all because a higher-level ACL already failed.

 

Example

You might be debugging this ACL:

incident.short_description.read

But the real problem could be this ACL:

incident.read

Tip:

Table-level ACLs must pass before ServiceNow checks field-level ACLs.

4. Use gs.log() or gs.info() carefully

ACL scripts allow you to add logs, which can help you debug issues.

Example ACL Script:

(function () {
gs.log('*** ACL check for user line no 2: ' + gs.getUserName(), 'ACL_DEBUG_INFO');
return gs.hasRole('itil');
})();

After running the test, we can check the system logs by navigating to Application navigator:

System Logs ---> All

and filter by:

Source = ACL_DEBUG_INFO

Tip:

Never leave logs in production ACLs — ACLs execute frequently and impact performance.

5. Use the “Impersonate User” Feature Correctly

When testing ACLs, make sure you impersonate a real user, not a test admin or any other account.

While impersonating, always check:

• User’s roles

• User’s groups

• User’s domain (applicable - if your instance uses domain separation)

Tip:

Admin users bypass ACLs, so impersonating an admin will not give you correct test results.

Conclusion

ACLs are not trial and error. When used correctly, they follow clear rules and work in a predictable way.

Developers who truly understand how to debug ACLs:

• Build more secure applications

• Improve system performance

• Earn trust on enterprise and regulated projects

Having a strong understanding of ACLs is a key skill for ServiceNow developers and architects.

Reference: Product documentation - Explore Access Control Lists 

Feel free to mark helpful and bookmark this article.

Thank You,

Sagar Pagar