How ServiceNow evaluates ACLs: why access doesn't always match the role

Claire_Conant · 3 hours ago

You assigned the role, but the record still won't open. You removed a role and the user kept access anyway. You cleared Admin Overrides, and admins are still getting in. In ServiceNow, access is rarely controlled by one rule. A request passes through several access control list (ACL) checks in a fixed order, and any one of them can be the gate that decides. Once you can read that order, the outcome stops looking random.

When does the role alone control access?

For most tables, access tracks the role exactly the way the ACL form implies. Add the role and the user sees the records. Take it away and they don't. That clean relationship covers the majority of what you configure, which is why the exceptions are so disorienting when they land. They aren't random, though. They come from something the form doesn't show you: a single read request gets checked more than once, by separate rules, in a set sequence.

How does ServiceNow actually evaluate an ACL request?

When a user requests a record, the platform doesn't consult one ACL and hand back a verdict. It works through a series of checks, and the order carries as much weight as the rules themselves.

Table access is settled before any field rule is read. The table-level check runs first. If it fails, evaluation stops there, and the field-level ACLs never run, not even the one written to grant exactly what the user is missing. So, when a field ACL looks like it's being ignored, the likelier story is that a table rule denied the request before the field rule ever got a turn.

An admin clears the role check on inheritance alone. The admin role inherits most other roles. An admin usually passes a role-based ACL legitimately by holding the role through inheritance rather than overriding anything. That is the part the Admin Overrides flag never touches. The flag decides whether the admin role skips ACL evaluation altogether. It says nothing about an admin who already satisfies the check, so you can clear it and the admin still gets in.

Reports answer to their own ACLs. A report or dashboard is gated by report_view ACLs, which run only when the report runs and sit apart from the read ACLs on the underlying table. Full read access to the table buys nothing here. The two layers are evaluated independently, and the denial says as much: "Access to this content denied based on report_view field ACL."

A filtered query is checked separately from a record you can open. Reading a record and running a filtered or range-based query over a table are two different operations, and each has its own ACL. A user with full read access can still be stopped the moment they filter a list, sort across a range, or run a report that does because the query_range operation is evaluated on its own. The results come back partial or empty, with a note that part of the query was ignored, rather than a record-level denial.

Why does the evaluation run in this order?

Each of these is a design decision, not a quirk. Checking the table first keeps the platform from grinding through field rules for someone who can't see the table at all. That's a performance choice as much as a security one.

Report access sits on its own layer for a reason. A report can reveal patterns across thousands of records that no single record would expose, so it gets its own gate. The admin role inherits broadly because admins have to run the instance, and locking one out of a single table was never meant to be a checkbox.

The query_range operation stands apart for a related reason. A filtered query can expose a value you can't read directly: narrow the filter far enough and a sensitive field gives itself away. So filtered queries are gated on their own, independent of whether you can open any single record.

Read this way, the result reflects the evaluation order working as designed.

What should you check when access doesn't match the role?

Once you know the order these checks run in, the mismatch becomes clear. A field ACL that looks ignored, a report that blocks a user who can read the table, an upgrade that didn't touch your configuration, a query that comes back partial—each one points to a different layer, not a broken system. Access Analyzer applies this same model automatically: it evaluates a specific user's access, compares two users side by side, or simulates a role change before you commit it, without asking you to trace the layers by hand. For step-by-step routing to the right resource for your specific symptom, see

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

Where to go from here

The shift that makes ACLs easier to manage is small but durable. Think of access as a set of ordered gates rather than one verdict, and the denials you couldn't account for resolve into a sequence you can follow. When you need certainty about what a specific user can reach, Access Analyzer gives it to you before you touch a rule.