Access Control Rules (ACLs)

ACL Overview

Access Control Lists (ACLs) are ServiceNow's primary database-layer security mechanism. Every read, write, create, delete, or execute operation against platform data passes through ACL evaluation before being permitted or denied.

What ACLs Protect

ACLs are stored in the sys_security_acl table. Navigate to them via Security > Access Control (ACL) or type sys_security_acl.list in the filter navigator. Each ACL record defines one permission rule combining a target object, an operation, and a set of requirements the user must satisfy.

The Four Primary Operations

Additional Operations

The Three Object Types

ACL Anatomy — All Fields Explained

Every ACL record in sys_security_acl contains the following fields. Understanding each field's purpose is essential for both the exam and real-world ACL authoring.

ACL Name Patterns

The Name field determines what object the ACL protects. It follows a table.field convention with wildcards supported at both levels.

ACL Evaluation Order (CRITICAL — Most Tested)

ServiceNow evaluates ACLs from most-specific to least-specific. The moment a matching ACL is found, its result (allow or deny) is applied and evaluation stops. No further ACLs are checked.

Specificity Priority Order

Same-Specificity Rules: ALL Must Pass

When multiple ACLs exist at the same specificity level for the same table/field/operation combination, the user must pass all of them. There is no short-circuit allow at the same level — each ACL is an independent gate.

The Three-Gate Check

Once the most-specific matching ACL is found, the user must pass all three internal checks. These run in sequence:

Fail-Closed Behavior

Admin Bypass

Role Matching Logic

The role check is the first gate in ACL evaluation. Understanding exactly how role matching works prevents common exam mistakes.

OR Logic Across Roles

When multiple roles are listed in an ACL's Requires role(s) list, the check uses OR logic — the user needs to have at least one of the listed roles. Possessing any single matching role is sufficient to pass the role check.

Role Hierarchy and Inheritance

ServiceNow roles support a parent-child hierarchy. A parent role includes all permissions of its child roles. If an ACL requires role itil and a user has a role that contains itil as a child, the role check passes.

Empty Roles List — Important Behavior

The security_admin Role

Creating, editing, or deleting ACL records requires the security_admin role. This is a separate, elevated role that is not granted automatically with admin.

Condition Evaluation

The Condition field on an ACL provides record-level (row-level) filtering. It is a standard ServiceNow filter expression that is evaluated against the current record being accessed.

How Conditions Work

• Conditions run after the role check — if the role check fails, the condition is never evaluated
• Both the role check AND the condition must pass for the ACL to allow access
• If no condition is specified, that check passes automatically
• The condition has access to the current object (the record being evaluated)
• JavaScript expressions can be embedded using the javascript: prefix

Common Condition Patterns

// Show only records assigned to the current user
assigned_to=javascript:gs.getUserID()

// Show records belonging to any group the user is a member of
assignment_group=javascript:gs.getMyGroups()

// Records where caller is the current user
caller_id=javascript:gs.getUserID()

// Records where active flag is true
active=true

// Records in open state (1 = open in ITSM)
state=1

GlideSystem Methods Used in Conditions

ACL Scripts

The Script field enables advanced, programmatic access control logic that goes beyond what filter conditions can express. ACL scripts run server-side and have full access to the ServiceNow scripting API.

Script Requirements

• The Advanced checkbox must be checked on the ACL to enable the Script field
• The script must explicitly return true to allow access or return false to deny
• Script runs after both the role check and the condition check
• If the script does not return anything, the behavior is undefined — always return explicitly
• The current object provides access to the record being evaluated

Available Script Objects

ACL Script Examples

// Allow access only to manager or above
answer = gs.hasRole('itil_manager') || gs.hasRole('admin');

// Allow if current user is the caller or assigned agent
answer = (current.caller_id == gs.getUserID() ||
          current.assigned_to == gs.getUserID());

// Allow if the record is in a specific state
answer = (current.state == 1 || current.state == 2);

// Check a related (referenced) record's field value
var grp = new GlideRecord('sys_user_group');
grp.get(current.assignment_group);
answer = (grp.manager == gs.getUserID());

// Combine role and field value check
if (gs.hasRole('itil')) {
  answer = (current.priority == 1 || current.priority == 2);
} else {
  answer = false;
}

Record ACLs vs. Field ACLs

Understanding the relationship between record-level and field-level ACLs is one of the most commonly tested topics in the security section of the CSA exam.

Record ACLs

A record ACL controls whether a user can access the entire row. It is the outer gate — if the record ACL denies access, the user cannot see the record in any form: not in list views, not via form, not via API.

Field ACLs

A field ACL controls access to a specific column within a table. Field ACLs are evaluated in addition to the record ACL — both must pass for the user to interact with a specific field.

The Cumulative Rule

Visual Flow: Record + Field ACL Evaluation

Table Wildcards and Fallback Behavior

Wildcard ACLs provide broad coverage when no specific rule exists. Understanding when wildcards are applied and which wildcards take precedence is essential for predicting ACL behavior.

Wildcard Reference

The *.* Global Catch-All

The *.* ACL is the fallback of last resort. When no more specific ACL matches for a given table/field/operation combination, ServiceNow falls through to the *.* ACL if one exists. If no *.* ACL exists either, the fail-closed rule applies and access is denied.

Table Extension and Wildcard Inheritance

The task.* wildcard demonstrates an important behavior: because incident, problem, and change_request all extend task, an ACL on task.* automatically applies to all those extended tables unless a more specific ACL exists for the extended table.

High Security Plugin

The High Security Settings plugin (com.glide.security.high_security) enables strict security enforcement at the platform level. It is a critical topic for the CSA exam's security section.

What the Plugin Does

Standard vs. High Security Mode

Key Exam Facts & Debugging

This section consolidates the highest-frequency exam facts for ACLs, including common trap questions and the debugging tools available on the platform.

Master Fact List

Debugging ACL Issues

When a user reports unexpected access problems, ServiceNow provides built-in tools to diagnose ACL evaluation without requiring code changes.

Quick Reference: ACL Decision Matrix