ServiceNow ACL Security Rules

Access Control Lists (ACLs) are the security rules that decide exactly who can read, write, create, or delete records and fields in ServiceNow. Every data access attempt on the platform passes through the ACL engine. If no ACL permits an action, ServiceNow blocks it. Understanding ACLs is essential for any administrator who needs to control data visibility and edit permissions precisely.

What Is an ACL?

An ACL is a single rule that answers one question: "Should this user be allowed to perform this operation on this data?" Each ACL rule targets a specific combination of table, field, and operation type.

ACL Rule Components:
──────────────────────────────────────────────────────────
Component      │ Example
──────────────────────────────────────────────────────────
Object         │ incident (the table this rule applies to)
Operation      │ write (read / write / create / delete)
Admin override │ true/false (admin bypasses this rule or not)
Requires Role  │ itil (user must have this role)
Condition      │ current.state != 7 (additional script check)
──────────────────────────────────────────────────────────

ACL Operations

ServiceNow enforces four basic operations through ACLs:

• Read: Can the user see this record or field?
• Write: Can the user edit the value of this field or record?
• Create: Can the user create a new record in this table?
• Delete: Can the user delete this record from the table?

Table-Level vs. Field-Level ACLs

Table-Level ACL

A table-level ACL controls access to all records in the table. An ACL on the incident table with operation read and role requirement itil means: "Only users with the ITIL role can see incidents."

Field-Level ACL

A field-level ACL controls access to one specific field within a table. An ACL on incident.salary_impact with operation read and role requirement incident_manager means: "Only incident managers can see the salary impact field on an incident."

Field-Level ACL Example:
─────────────────────────────────────────────────────────
Incident Table: "Work Notes" field
ACL: incident.work_notes / Read / Requires: itil role

Result:
  Agent with ITIL role: SEES the Work Notes field ✓
  Regular employee:     CANNOT see Work Notes ✗
  (They see Additional Comments instead, which has no role restriction)
─────────────────────────────────────────────────────────

How the ACL Engine Evaluates a Request

When a user tries to read or write data, ServiceNow runs through this evaluation sequence:

User opens an Incident record and tries to read it:
         │
         ▼
1. Does the admin flag apply?
   (Admins bypass ACLs by default unless "admin overrides" is turned off)
         │
         ▼
2. Find all matching ACL rules for:
   Table = incident, Operation = read
         │
         ▼
3. Evaluate each matching ACL:
   - Does the user have the required role?
   - Does the condition script return true?
         │
         ▼
4. If ANY ACL passes → Access GRANTED
   If NO ACL passes → Access DENIED

ACL Conditions

ACLs support three types of conditions that must all pass for access to be granted:

Role Requirement

The user must have one of the listed roles. This is the most common ACL condition. No script needed — just select the required roles.

Condition Builder

A no-code condition that evaluates field values. For example, only allow write access when state is not equal to Closed. Once a record is closed, no one can edit it — regardless of role.

Script

A JavaScript function that returns true or false. Scripts handle complex logic that the condition builder cannot express. For example, a script checks whether the logged-in user is the same person as the record's caller — allowing callers to read only their own records.

ACL Script Example: Allow only the record's caller to read it
─────────────────────────────────────────────────────────────
(function() {
    return gs.getUserID() == current.caller_id;
})();
─────────────────────────────────────────────────────────────
This returns true only if the logged-in user IS the caller.
Anyone else gets denied.

The Security Admin Role

Only users with the security_admin role can create or modify ACL rules. This separation of duties prevents regular administrators from accidentally weakening security. Even the standard admin role cannot change ACLs without security_admin — a deliberate design that forces deliberate security decisions.

Elevated Privileges

To make ACL changes, a security admin must explicitly elevate their privileges using the Elevate Roles option in their profile menu. Elevated access lasts for one session only. This requirement adds a deliberate friction point — preventing accidental ACL changes and creating a clear audit trail of when elevated access was used.

Debugging ACL Issues

When a user reports that they cannot see or edit data they should have access to, administrators use the Access Control debug tool. Navigate to System Diagnostics > Session Debug > Debug Security. With debug enabled, every page load shows which ACL rules were evaluated, which passed, and which blocked access — making troubleshooting precise and fast.