Access control: When users can't see what they should

Claire_Conant · 3 hours ago

Your users can't see records they should have access to, or they're seeing records they shouldn't, and you've already checked roles and confirmed group membership settings are correct. Reviewing access control list rules are the logical place to start, but there are other causes you can check. The fastest route is to take advantage of Access Analyzer, and then work through the different symptoms that then route you to the resource that addresses your specific scenario.

Access Analyzer: the automated path

Your instance has an automated solution: The ServiceNow AI Platform Access Analyzer. It evaluates a specific user’s permissions against tables and records, compares access between two users, and simulates the impact of role changes, without requiring you to manually trace through ACL rules or business rules.

Go to System Security > Access Analyzer to access Evaluate Access, Compare Access, and Access Simulator.

See: Access Analyzer overview

When the problem is an ACL

ACL rules operate at several levels, including table, field, query, and report. The symptom you're seeing usually points to which level is involved.

1. Access fails with no clear error message

This is the most common starting point. ACLs evaluate in two gates: table-level access first, and then field-level access. If a user fails the table-level check, field-level ACLs are never evaluated, even if they would pass. Most “can’t see records” problems trace back to this evaluation order.

See: How Access Control List (ACL) evaluation works in ServiceNow

2. Records appear in the platform UI but not in Service Portal

ACLs apply the same way in Service Portal as in the platform UI, but the debugging tools work differently. The standard debug security output doesn’t display on portal pages. You need to load /ui_page.do in a separate tab after triggering the portal page to capture ACL evaluation results.

See: Use ACL debugging tools in Service Portal or angular pages

3. Reports or dashboards show “Access denied based on report_view ACLs”

report_view ACLs are a separate access control layer from regular read ACLs. A user can have full read access to a table and still be blocked from reports or dashboards that reference it. If you’re seeing “Access to this content denied based on report_view field ACL” or “Access to this content denied based on extra security on READ ACLs,” the problem is in the report_view layer.

See: Troubleshoot report_view ACL access-denied errors on reports and dashboards

4. Filtered lists or reports return partial or empty results

If you’re seeing “Part of the query has been ignored because of insufficient access for ‘query_range’ operation” or “Security prevents reading [field], no records displayed,” a May 2025 security maintenance update is the likely cause—nothing in your configuration changed; the platform’s enforcement did.

Note: On Australia and later, this runs as default platform behavior, so you can see it on a default ServiceNow table you never configured, not only as a one-time change from the May 2025 maintenance.

See: Troubleshoot query_range and query_match ACL access issues

For a broader explanation of why filtered queries get checked separately from record-level read access, see How ServiceNow evaluates ACLs.

5. Users lost access after an upgrade or patch

Platform upgrades can silently insert new ACL records that restrict access. These new ACLs don’t appear in the standard System Upgrades table (sys_upgrade_history). You need to check the Upgrade Details table (sys_upgrade_history_log) filtered by file names starting with sys_security_acl.

See: How to resolve denied access when ACL blocks table access after upgrade

6. Admins can access data after you unchecked Admin Overrides

If you’ve unchecked Admin Overrides on an ACL and admins can still access the data, the checkbox may not be the issue. The admin role inherits most normal roles, which means admin users can pass the role check legitimately, regardless of the Admin Overrides setting.

For more on why this happens and how to better restrict admin access, see ACL rules that pass review and still fail in production.

Still stuck? Check for non-ACL causes

If none of the previous ACL scenarios match your situation, another mechanism may be restricting record visibility. Each of the following can silently affect what users see.

Before Query business rules

These rules can silently filter records before query results are returned. For example, the base system “incident query” business rule restricts non-ITIL users to only incidents they created or were created for them. Records simply don’t appear and there’s no error message.

See: Before Query business rules

Domain separation

In domain-separated instances, users only see records in their assigned domain or its child domains. If a user is assigned to the wrong domain, records are invisible without any error.

See: Domain separation explained

Security Data Filters

These filters restrict record visibility at the query level by appending conditions to every query on a table. They run before ACLs and can silently remove records from results. The “Number of rows removed by security constraints” message is generated by read ACLs, not Security Data Filters, so the absence of that message doesn’t rule them out.

See: How Security Data Filters affect security constraints messages

Where to go from here

Access control issues can look confusing at first, but they usually trace back to identifiable mechanisms once you know where to check. If none of these scenarios match what you're seeing, capture the exact symptom before going deeper: whether Security Debug shows a denial message, which table or field is blocked, and whether the affected records share a domain or business rule condition. That detail is what turns a vague "can't see records" into a specific, solvable problem. The access control product documentation covers how each of these mechanisms is meant to behave, and the symptom-specific articles above go deeper on each path.