ACL issues are among the most frustrating debugging sessions in ServiceNow — a user reports they can't see something they need, and you're left hunting through dozens of ACLs trying to figure out which one is the culprit. This guide shows you how to systematically identify the exact ACL that's blocking access using ServiceNow's built-in debugging tools.
Why ACL debugging gets messy
Before ServiceNow added proper debugging tools, tracking down ACL issues meant manually reviewing every relevant ACL rule, trying to guess which combination of conditions was blocking access. Developers would comment out ACLs one by one or add logging statements to scripts — a time-consuming process that often missed the real problem. Users would report access issues, admins would grant broader permissions as a workaround, and the underlying ACL conflict would never get fixed. This approach led to over-permissioned users and ACL rules that nobody understood or maintained.
How ACL debugging actually works
ServiceNow evaluates ACLs in a specific order: table-level ACLs first, then field-level ACLs for each field being accessed. When multiple ACLs apply to the same object, ServiceNow uses the most restrictive result unless an ACL explicitly grants access with a wildcard or role match. The debugging process involves three tools working together: the Access Control Analyzer shows you which ACLs are being evaluated, the acl_test URL parameter captures detailed evaluation logs, and impersonation lets you test exactly what the affected user sees. The key insight is that you need to see both which ACLs are running and what each one returns.
Taking ACL debugging further
Once you can reliably debug ACL issues, the next step is building ACL rules that are easier to debug in the first place. Well-designed ACLs have clear, descriptive names that indicate their purpose, use role-based conditions instead of complex scripts when possible, and include comments in script conditions explaining the business logic. Advanced debugging techniques include setting up automated ACL testing with Test Runner to catch regressions, using the Security Log for ongoing monitoring of access denials, and building custom ACL reports that show admins which rules are actually being used versus sitting dormant.
Before you start
- •security_admin or admin role
- •Impersonation (impersonator) role if testing with specific users
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Enable ACL debugging parameters
Add ?acl_test=true to the end of any ServiceNow URL where you're experiencing the access issue. This parameter captures detailed ACL evaluation logs that show which ACLs are running and what they return. Navigate to the specific record or form where the problem occurs while keeping this parameter in the URL — the debugging only captures ACLs evaluated during that page load.
Combine this with ?sysparm_debug=true to see additional script debugging information if your ACLs use script conditions.
Impersonate the affected user
Navigate to System Security > Users and Sessions > Impersonate User. Enter the username of the person reporting the access issue and click Impersonate. This makes ServiceNow evaluate all permissions exactly as that user would see them. Don't skip this step — admin users often have implicit access that masks ACL problems.
The impersonation stays active until you click the red 'Stop Impersonating' banner at the top of the page.
Open the Access Control Analyzer
While still impersonating the user, navigate to System Security > Access Control (ACL) > Access Control Analyzer. This tool shows real-time ACL evaluations as they happen. Enter the table name where you're seeing access issues in the Table field. If this is a field-level issue, also enter the specific field name in the Field Name field.
Leave Field Name blank first to see table-level ACL evaluations, then add the specific field to narrow down field-level issues.
Navigate to trigger ACL evaluation
With the Analyzer open, navigate to the problematic record or form in a new browser tab (keeping the acl_test=true parameter). The Analyzer will populate with every ACL that gets evaluated during the page load. Look for ACLs that return 'false' or 'undefined' — these are your blocking rules. Pay attention to the Order field, as ACLs are processed in sequence.
If nothing appears in the Analyzer, the issue might be a UI Policy or Client Script rather than an ACL.
Check the Security Log
Navigate to System Logs > Security Log to see historical access denials. Filter by User and Table to find entries related to your issue. Each log entry shows which specific ACL denied access and when. This is especially useful for intermittent issues or when you need to see patterns over time rather than just the current page load.
Security Log entries are only created for actual access denials, not for successful ACL evaluations.
Review the blocking ACL rule
Click on the ACL record that's returning false from your Analyzer results. Check the Condition field for role requirements, script conditions, or other logic that might be incorrectly blocking access. If there's a Script field, review the JavaScript for logical errors or outdated references. Common culprits include hardcoded user references, role checks that don't account for inherited roles, or conditions that worked in development but fail in production.
Look at the ACL's Operation field — 'read' controls record visibility, 'write' controls field editing, and 'create' controls record creation.
Test your fix and clear cache
After modifying the ACL, navigate to System Definition > Cache Flush and flush the Security cache. This forces ServiceNow to re-evaluate ACL rules with your changes. Then repeat your test scenario while still impersonating the user to confirm the access issue is resolved. Use the Access Control Analyzer again to verify the previously blocking ACL now returns true.
ACL changes can take several minutes to propagate fully even after cache flush — test in an incognito window if you're still seeing old behavior.
Best practices
Always test ACL changes while impersonating the actual affected user — your admin account can mask ACL problems with implicit permissions.
Use the Access Control Analyzer before making any ACL changes to establish a baseline of which rules are currently firing.
Check both table-level and field-level ACLs when debugging field visibility issues — a permissive field ACL won't help if a table ACL blocks record access entirely.
Clear the Security cache after every ACL modification or your changes won't take effect immediately.
Document your ACL debugging findings in the ACL record's Description field so future admins understand the business logic and testing scenarios.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue