How to Fix ServiceNow ACL Blocking Record Updates
Step-by-step fix guide with AI-powered diagnosis from BuildForce.
ServiceNow ACLs block updates when no matching ACL grants the user write access on the table and field combination. ACL evaluation runs from most-specific to least-specific (field-level → table-level → table.* fallback) and requires all conditions in an ACL rule (role, condition, script) to evaluate true. The fix workflow: enable Security Debug to see exactly which ACL failed, check the user's effective roles via sys_user_has_role, ensure the table's parent ACL exists for scoped tables, and add a write ACL with the required role at the appropriate granularity (table or field).
Symptoms
REST API PATCH returning 403 with 'Operation against file 'x_table' is not allowed'
UI showing 'Number of rows removed by security: N' in lists or related lists
Updates working in admin elevated mode but failing for the same user without elevated privileges
Some fields updating successfully while others on the same record are blocked
Scoped application ACL blocking even though the user has admin role in the global scope
Integration user receiving HTTP 200 but the field values not persisting
Root Causes
Missing write ACL on the field or table
ServiceNow's default is to deny — if no ACL grants write, write is denied. For custom tables created without inheriting from a parent, you must explicitly create write ACLs or no user can update them outside of admin.
ACL condition or script returning false
An ACL with a condition (e.g., 'current.state != 6') or script (returns answer = false) silently denies even when the user has the right role. The Security Debug shows the ACL evaluation but the failure reason is often the condition, not the role.
Scoped application ACL not granting cross-scope
A scoped app's ACLs only apply within that scope by default. A global-scope user (even admin) updating a record in a scoped app needs an ACL that explicitly accepts cross-scope access, or the scoped app's Restrict Access settings need to allow read/write from other scopes.
ACL role check using direct role, not inherited
If an ACL requires role 'itil_admin' and the user has 'admin' (which contains itil_admin), the check passes only if 'Includes' is checked on the ACL role join. Otherwise the inherited role doesn't qualify.
Field-level ACL overriding table-level grant
Field-level ACLs evaluate before table-level. A user with table-level write but no field-level write on the specific field is denied for that field while other field updates on the same record succeed.
How to Fix It — Step by Step
Enable Security Debug to see ACL evaluation
Navigate to System Diagnostics → Session Debug → Security. In the user's next request, every ACL evaluation is logged with the result. This is the single most efficient diagnostic tool — it tells you exactly which ACL denied the operation.
Verify the user's effective roles
Query sys_user_has_role for the user. ServiceNow stores both directly-assigned and inherited roles. If the role required by your ACL isn't in the list (even via 'contains'), the ACL won't pass.
// sys_user_has_role.list?sysparm_query=user=user_sys_id
GET /api/now/table/sys_user_has_role?sysparm_query=user.user_name=integration.user&sysparm_fields=role.nameCheck ACL evaluation order in the debug output
ACLs evaluate field-level first (operation=write, name='table.field'), then table-level (name='table.*'), then table base (name='table'). The first denying ACL stops evaluation. Identify which level is rejecting and add or amend the ACL at that level.
Add a write ACL at the appropriate granularity
In System Security → Access Control (ACL), create a new ACL with: Type=record, Operation=write, Name=table.field (or table.* for table-wide). Add the required role. Set Condition or Script if state-based restriction is needed.
Configure scoped application access for cross-scope updates
In the scoped application's record (System Applications → Studio → [App] → Application file), check the Restrict Access settings. Enable 'Allow runtime access from other application scopes' for write operations the integration user needs.
Test with impersonation in non-production
Use the 'Impersonate User' admin function to test as the integration user without re-authenticating. Attempt the failing update — you'll see the exact ACL denial message and Session Debug fires for the impersonated session.
Audit ACL counts and gaps across tables
Query sys_security_acl for tables with no write ACLs. Custom tables with zero ACLs are completely locked except to admin. BuildForce's ServiceNow health check surfaces these gaps and recommends the minimum ACL set for each table.
GET /api/now/table/sys_security_acl?sysparm_query=operation=write&sysparm_fields=name,rolesLet BuildForce diagnose and fix this automatically
Instead of following manual steps, connect your org and let our AI identify exactly what's broken and how to fix it — in minutes.
Book a DemoCommon Questions
More answers about this issue and how to resolve it.
Stop debugging manually. Let AI do it.
BuildForce runs 200+ automated checks across your Salesforce org and tells you exactly what's broken and how to fix it.