How to Fix "ACL is Preventing Access" Errors in ServiceNow

Getting a 'Number of rows removed from this list by Security constraints' or ACL error in ServiceNow? Here's how to diagnose and fix access control problems step by step.

July 8, 2026 5 min read

Want this done for you? Hire a ServiceNow specialist on NovusAI →

If you've ever seen "Number of rows removed from this list by Security constraints" or a red "Security prevented access" banner in ServiceNow, you've hit an ACL (Access Control List) problem. It's one of the most common — and most confusing — issues for admins and developers, because ACLs evaluate in a specific order and a single failing rule blocks the whole operation.

This guide walks through exactly how to diagnose and fix it.

What an ACL actually does

An ACL controls whether a user can read, write, create, or delete a record or field. For access to be granted, ServiceNow evaluates matching ACLs and the user must pass:

The table-level ACL, and
The field-level ACL (if one exists)

Access requires passing all of: the required roles, the condition, and the script (if present). If any part fails, access is denied — and ServiceNow silently strips the row or field rather than throwing a loud error.

Step 1: Turn on debugging

The fastest way to see which ACL is failing:

Elevate to the security_admin role (gear menu → Elevate role).
Go to System Security → Debug Security Rules (or type debug.security in the filter).
Reload the record or list that's failing.

You'll now see inline debug output showing every ACL that was evaluated, whether it passed or failed, and why.

Tip: Also enable System Diagnostics → Session Debug → Debug Log to catch script-based ACL failures in the logs.

Step 2: Read the evaluation order

ServiceNow matches ACLs from most specific to least specific:

table.field → table.* → parent_table.field → parent_table.* → *.field → *.*

Only the most specific matching ACL for each operation is evaluated. This trips people up constantly: if a very specific incident.short_description read ACL exists and fails, ServiceNow does not fall back to the broader incident.* ACL. Fix the specific one.

Step 3: Check the three things that grant access

For the failing ACL, verify each part:

Part	What to check
Roles	Does the user actually have the role listed on the ACL? Check User Administration → Users → Roles. Remember roles can be inherited via groups.
Condition	Does the record meet the condition builder criteria? A condition like `Assigned to = (current user)` fails for everyone else.
Script	If the ACL has a script, it must set `answer = true`. A script that doesn't set `answer` defaults to false.

Step 4: The most common root causes

Missing role — the user simply lacks the role the ACL requires. Grant it (or adjust the ACL).
Field ACL overriding table ACL — a restrictive table.field ACL blocks a field even though the table ACL passes.
A script ACL that returns false — often because a referenced variable is null. Add null-safety: answer = (gs.hasRole('itil') && current.caller_id == gs.getUserID());
Empty ACL = deny — an ACL with no roles, no condition, and no script grants access to no one. If someone created a blank ACL on your table, it locks everyone out.
ACLs on the wrong table — extended tables (like incident extending task) inherit task ACLs. Check the parent.

Step 5: Fix, then re-test as the affected user

Make your change, then impersonate the affected user (gear → Impersonate user) and reproduce the exact action. Don't test as admin — admins bypass most ACLs and everything looks fine.

Quick checklist

Enabled Debug Security Rules and identified the failing ACL
Confirmed the operation (read / write / create / delete)
Verified the user's roles, the condition, and the script all pass
Checked for a blank/empty ACL locking the table
Re-tested by impersonating the real user, not as admin

Still stuck?

ACL debugging can spiral fast on a customized instance — especially when scripted ACLs, ACL inheritance across extended tables, and delegated development are all in play. If you're on a deadline and can't afford to break production security, it's often faster to have an experienced ServiceNow developer look over your shoulder for 30 minutes than to trial-and-error it for hours.

Let the ServiceNow Agent find the blocking ACL

ACL debugging is a maze of table, field, and row rules with roles and script conditions. The NovusAI ServiceNow Agent can untangle it on your instance: ask "Which ACL is blocking read access to this table for this role?" and it enumerates the relevant ACLs, checks their roles, conditions, and scripts, and pinpoints the one denying access — then explains exactly why. With your approval it can adjust or add the right ACL and confirm access is restored. Read-only until you enable writes. See how it works.

How the NovusAI agent does this

ACL problems are hard because the answer is spread across several records and an evaluation order you have to hold in your head. The agent reads all of it at once:

Find the ACLs on the table and field, in evaluation order, and show which ones the failing user actually matches.
List that user's roles — including inherited ones, which is where "but they have itil" usually unravels.
Point at the specific rule that fails, rather than telling you ACLs are complicated. Table-level before field-level, and a single failing rule blocks the whole operation.
Create or amend the ACL once you have decided what access is correct, showing you the record before it writes.

Ask it: "User abel.tuter gets 'Security constraints' on the incident list — which ACL is blocking them?" It will check the real roles and the real rules on your instance.

The agent is deliberately conservative here. Security records are the easiest place to do quiet damage, so every write is shown in full and applied only on your approval.

ServiceNow ACLACL preventing accessSecurity constraintsServiceNow access controlrow level security

Back to all articles