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

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:

1. The table-level ACL, and
2. 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:

1. Elevate to the security_admin role (gear menu → Elevate role).
2. Go to System Security → Debug Security Rules (or type debug.security in the filter).
3. 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:

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.