ACL Evaluation Order

ACL Evaluation Order in ServiceNow – Complete Guide for CAD Exam

Why ACL Evaluation Order Matters

Access Control Lists (ACLs) are the backbone of security in ServiceNow. They determine who can read, write, create, or delete records and fields. However, when multiple ACLs exist for the same resource, ServiceNow must decide which ACL to evaluate first and how they interact. Understanding ACL evaluation order is critical because:

• A misconfigured or misunderstood evaluation order can lead to unauthorized access or overly restrictive permissions.
• It is a frequently tested topic on the ServiceNow Certified Application Developer (CAD) exam.
• It directly impacts how you design and troubleshoot security rules in real-world implementations.

What Is ACL Evaluation Order?

ACL evaluation order refers to the specific sequence in which ServiceNow processes Access Control Rules when a user attempts to access a resource (such as a table, record, or field). ServiceNow evaluates ACLs from the most specific to the most general, and the user must pass all matching ACLs to gain access.

How ACL Evaluation Works – Step by Step

When a user tries to access a resource, ServiceNow follows this evaluation process:

1. Determine the Operation
ServiceNow identifies the operation being attempted: read, write, create, or delete.

2. Match ACLs from Most Specific to Most General
ServiceNow looks for ACLs that match the requested resource in the following order of specificity:

   a. Field-level on a specific table (e.g., incident.caller_id) – Most Specific
   b. Table-level on a specific table (e.g., incident)
   c. Field-level on wildcard table (e.g., *.caller_id)
   d. Table-level wildcard (e.g., *) – Most General (the default ACL)

This is commonly represented as:

   table.field → table → *.field → *

3. All Matching ACLs Must Pass
This is the most important concept: ServiceNow does not stop at the first matching ACL. Instead, it collects all matching ACLs at every level of specificity and the user must pass every single one of them. For example, if a user wants to read the caller_id field on the incident table, ServiceNow will check:

   • Any ACL on incident.caller_id (read)
   • Any ACL on incident (read)
   • Any ACL on *.caller_id (read) — if it exists
   • The default * (read) ACL

The user must satisfy all of these to gain access.

4. Within a Single ACL Rule – Evaluation of Conditions
Each individual ACL rule can have up to three components, which are evaluated in this order:

   a. Condition (filter condition) – A declarative condition on the record
   b. Script – A server-side script that returns true or false
   c. Roles – One or more roles the user must possess

Within a single ACL rule, these conditions are evaluated with an AND logic if the rule requires all to pass, but roles within the Requires Role section are evaluated with OR logic. This means:

   • If multiple roles are listed, the user needs at least one of them (OR).
   • The condition, script, and role requirement must all be satisfied (AND).

5. Table Hierarchy (Inheritance)
If a table extends another table (e.g., incident extends task), ACLs defined on the parent table (task) are inherited by the child table (incident) unless overridden. The child table's ACL takes precedence over the parent table's ACL for the same object and operation.

6. The Default Deny Principle
If no ACL rule matches the requested object and operation, access is denied by default (assuming the property glide.sm.default_mode is not set to allow — which it should never be in production). This is a secure-by-default approach.

Key Concepts Summary Table

Concept → Behavior
• Multiple matching ACLs → User must pass ALL of them (AND logic across ACL rules)
• Multiple roles in one ACL → User needs at least ONE role (OR logic within roles)
• Specificity order → table.field → table → *.field → *
• Table inheritance → Child table ACLs override parent table ACLs
• No matching ACL → Access denied (default deny)
• Admin role → Bypasses all ACL checks (unless high security is enabled)

Common Pitfalls

• Assuming the first match wins: Unlike firewall rules, ServiceNow evaluates ALL matching ACLs, not just the first one.
• Forgetting table-level ACLs: Even if a field-level ACL passes, the table-level ACL must also pass.
• Ignoring wildcard ACLs: The * ACL applies to all tables and can block access even when specific ACLs allow it.
• Confusing role logic: Roles within a single ACL use OR; multiple ACLs use AND across them.

Exam Tips: Answering Questions on ACL Evaluation Order

Tip 1: Memorize the Specificity Order
Always remember: table.field → table → *.field → *. Questions often ask which ACL is evaluated first. The answer is always the most specific match.

Tip 2: Remember "ALL Must Pass"
The most commonly tested concept is that all matching ACLs must pass. If a question describes a scenario where a table-level ACL denies access but a field-level ACL allows it, the answer is that access is denied.

Tip 3: Roles Are OR, ACLs Are AND
If a question asks about a single ACL with multiple roles (e.g., itil and admin listed in Requires Role), the user needs only one of those roles. But if two separate ACL rules both match, the user must pass both rules.

Tip 4: Watch for Admin Role Exceptions
The admin role bypasses ACL evaluation entirely (unless the high security plugin is enabled). If a question mentions an admin user, the ACL rules are irrelevant unless high security is specified.

Tip 5: Pay Attention to Table Hierarchy
If a question mentions extended tables (like incident extending task), remember that child-level ACLs override parent-level ACLs. If no child ACL exists, the parent ACL is inherited.

Tip 6: Understand the Three Components
If asked about what happens within a single ACL rule, remember the evaluation of condition + script + roles. All three must be satisfied (with roles being OR among themselves).

Tip 7: Default Deny
If a question states that no ACL exists for a particular object, the correct answer is that access is denied (assuming default security settings).

Tip 8: Debug ACLs
You may see questions about how to troubleshoot ACLs. The answer is the Security Diagnostics page (accessible via System Diagnostics → Session Debug → Debug Security) or enabling the session debug for security (glide.security.debug).

Practice Scenario

A user with the itil role tries to read the assignment_group field on the incident table. The following ACLs exist:

   1. incident.assignment_group (read) – Requires role: itil → PASS
   2. incident (read) – Requires role: itil → PASS
   3. * (read) – Requires role: any authenticated user → PASS

Result: Access is GRANTED because all three matching ACLs pass.

Now change ACL #2 to require the admin role:

   2. incident (read) – Requires role: admin → FAIL

Result: Access is DENIED because even though the field-level ACL passes, the table-level ACL fails, and all must pass.

Final Takeaway

ACL evaluation order in ServiceNow follows a most-specific-to-most-general pattern, and all matching ACLs must be satisfied for access to be granted. This cumulative AND logic across matching rules, combined with OR logic for roles within a single rule, is the cornerstone of ServiceNow security and one of the most important topics for the CAD exam.