ACL rules that pass review and still fail in production

Claire_Conant · 3 hours ago

Most access problems don't surface while you're writing the rule. They surface weeks later in production when a user can't open a record that they should or an admin reaches something they shouldn't. The scenarios below can pass a quick review and then come back as access cases. Knowing them now is faster than diagnosing them under pressure.

Does this apply to you?

These six scenarios appear on any ServiceNow instance using role-based ACLs on standard tables. Four of them aren't version-specific quirks—they're properties of the ACL evaluation model itself, so version doesn't gate whether you'll see them. The other two are tied to specific platform updates: the post-upgrade ACL change (most likely after a move between major releases) and the May 2025 query_range enforcement.

Before you start: For any of these, Access Analyzer is the tool to reach for first. It shows what a user can actually reach on a table or record without you having to trace rules by hand.
See: Access Analyzer overview: evaluate, compare, and simulate access permissions

If the table-first sequence, what Admin Overrides actually controls, and how Access Analyzer works aren't yet familiar, start with this article. What follows will make more sense once that context is in place. How ServiceNow evaluates ACLs: why access doesn't always match the role.

Unchecking Admin Overrides won't keep admins out of the data

What the checkbox actually does. The Admin Overrides flag controls one thing: whether the admin role skips ACL evaluation entirely. It doesn't determine whether an admin passes a rule on the merits. Because the admin role inherits most other roles, an admin usually clears a role-based check legitimately, so clearing the flag leaves that access in place.

How to effectively restrict an admin. Add a condition or script that denies the admin role outright instead of relying on the checkbox. The opposite catches people too: an admin can be denied on a field even when Admin Overrides is selected. That happens when the field has more than one ACL and Admin Overrides is cleared on any one of them. A single cleared box makes the effective setting false for all of that field's ACLs, so the admin loses the override.

A field ACL can't grant what a table ACL already blocked

Where the block really is. Evaluation is table-first. The platform checks table-level access, and if that check fails it stops there, so the field ACL never runs, even when it's written to grant exactly what the user needs. The symptom looks like a broken field rule, when the real block sits one level up.

Check this before touching the field rule. Confirm the user clears the table read first. A gate that already closed upstream isn't something a field rule can reopen, so a correct field ACL won't help until the table read passes.

A report_view denial isn't a table problem, and the table ACL won't fix it

What's really gating the report. A user opens a record, but then a report on the same data returns "Access to this content denied based on report_view field ACL." The read ACL isn't the cause. report_view ACLs are a separate layer, evaluated only when a report runs, and they work from roles rather than scripts.

Where the fix happens. Editing the table read ACL won't clear the error. Grant the required role, or add a report_view ACL for a role the user already holds. For step-by-step troubleshooting, see: Troubleshoot report_view ACL access-denied errors on reports and dashboards.

If access changes after an upgrade, it may be intentional, not a regression

What may have changed. Platform updates can include security updates, and those sometimes add base-system ACLs to a table. When a user loses access right after an upgrade and your configuration didn't change, verify whether the upgrade added a new base-system ACL. Don't assume regression before you've confirmed the change wasn't intentional.

How to check (only if you've hit it). Most upgrades won't change anyone's access, so look into this only when an unexpected block actually happens. Then confirm whether a new ACL came with the upgrade and is meant to be there before you change anything. Reverting a deliberate security change can reopen access you didn't mean to grant. If you've run into this, see How to resolve denied access when ACL blocks table access after upgrade.

A filtered list or report can return partial results even when the user can open the records

What the May 2025 change did. A maintenance change tightened how the platform enforces the query_range ACL — the rule that governs filtered and range-based queries that use operators like greater-than, less-than, between, and contains. These queries are denied by default now unless a query_range ACL grants them. So a user who opens an individual record without trouble can still hit a wall the moment they filter a list, sort across a range, or run a report over the same table. The tell is a list or report that comes back partial or empty, with the message "Part of the query has been ignored because of insufficient access for 'query_range' operation."

How to handle it. Treat this as the platform working as designed, not a regression—the change closed a path where someone could infer a value they couldn't read directly by narrowing a filter until a sensitive field gave itself away. Where a role legitimately needs filtered access, define a query_range ACL for that field and grant it to the role, rather than loosening the read ACL.

Note: If your instance is on Australia or later: this enforcement now runs as the platform's default behavior, not the single instance-wide query_range rule the May 2025 update applied. Roles with unconditional read access to a table and field (full access, with no row-based conditions or scripts) receive range query access by default. You define a query_range ACL manually only where a role's read access is conditional or on custom tables. What the user reports stays the same: filtered and range-based queries remain restricted for anyone without full read access.

A rule that passes in non-prod can still fail in production

It's usually the context, not the rule. A rule that works in a non-production instance and fails in production usually isn't the rule itself. It's what surrounds it: different data and domains, different roles on the test user, or ACLs that exist in one instance and not the other.

Test like it's production. Choose a user whose roles match the real production account, not an admin or a shared convenience login. When results differ across instances, compare the role assignments and the ACL set before you suspect the rule.

Where to go from here

Most of these issues never surface if you catch them at design or review time. When one does reach production, Access Analyzer is the first stop—point it at a user and a table, and it shows what's deciding access before you touch a rule. To see the full model these behaviors build on—the order the checks run in, and why—start with How ServiceNow evaluates ACLs: why access doesn't always match the role. ServiceNow product documentation has the configuration details behind each layer.

None of these are bugs. Every one maps back to how ACL evaluation actually works, and once you can see that sequence, the behaviors stop being surprises and start being things you can plan for.