5.2 Access Control (ACLs) & Security

Why ACLs Dominate This Domain

If you only deeply learn one topic for the Database Management and Platform Security domain, make it Access Control Lists (ACLs). ACLs are the heart of ServiceNow data security, and the CSA exam reliably includes scenario questions about why a user can or cannot see or edit a field.

ServiceNow security is deny-by-default (also called secure by default). A user has no access to an object unless an ACL rule explicitly grants it and that rule evaluates to true. If no ACL matches at all for an operation, access is denied.

What an ACL Rule Contains

Each ACL rule (stored in the sys_security_acl table) specifies:

• Type — record (table/field data), client_callable, processor, REST_Endpoint, etc. Most CSA questions concern the record type.
• Operation — read, write, create, delete, plus list/report operations.
• Name — the object, written as table.field. A field name of * or None means the rule applies at the record (row) level; a specific field name makes it a field-level rule.
• Required Roles — zero or more roles the user must hold.
• Condition — a condition builder expression that must be true.
• Script — an optional server-side script that must return/answer true.

ACL Evaluation Order (Memorize This)

ServiceNow evaluates ACLs from most specific to least specific. For a given operation on a given field, the platform checks rules in this order:

Within that order, the rule is split into the field-level check and the record-level check. To gain access to a field, the user must pass both the matching field ACL and the matching record ACL for that operation. If no field-level ACL exists for that exact field, ServiceNow falls back to the more general (parent or wildcard) ACL — it does not automatically grant access.

How a Single ACL Decides (AND Logic)

When the platform evaluates one matching ACL rule, the user is granted access through that rule only if every of the following passes:

1. Roles — the user has at least one of the Required Roles (or the rule lists no role).
2. Condition — the condition builder expression evaluates to true.
3. Script — the ACL script (if present) sets answer = true.

All three must be satisfied. This is AND logic within a rule. Across multiple matching rules at the same specificity level, if any one of them grants access, access is granted (OR logic across rules of equal specificity). Remember the distinction: within a rule it is AND; across same-level rules it is OR.

Roles, Conditions, and Scripts

• Role requirement is the simplest gate. Common roles include admin (full access), itil (fulfiller), security_admin (security configuration), and application-specific roles. The admin role generally satisfies most ACLs but does not bypass scripted ACLs that explicitly deny access.
• Conditions are declarative filters built in the condition builder (for example, Assigned to is the current user). Prefer conditions over scripts when the logic is simple — they are easier to maintain and read.
• Scripts handle logic conditions cannot express. An ACL script sets the variable answer to true or false. Use scripts only when necessary; over-scripting ACLs hurts performance and maintainability.

Contextual / Row-Level Security

Contextual security means access depends on the data in the record and the current user, not just on a static role. For example, "a user can read an HR case only if they are the subject, the assigned agent, or a member of the HR group." This is implemented by adding conditions or scripts to record-level ACLs (for example, current.assigned_to == gs.getUserID()). Role checks alone are coarse; conditions and scripts deliver true row-level security.

High Security Settings and Security Admin Elevation

ServiceNow ships with a High Security Settings plugin and a base system default deny property (glide.sm.default_mode) so that unmatched objects are denied rather than allowed. Editing ACLs and other high-security configuration is itself protected.

To modify ACL rules or high-security settings, an administrator must elevate to the security_admin role. Even a user with the admin role does not automatically have security_admin; they hold it as an elevatable role and must explicitly elevate (via the user menu Elevate Role) for the current session. This separation prevents accidental or unauthorized changes to the security model and creates an audit trail of who changed access control.

Common Exam Trap

A user reports they cannot edit a field even though they have the right role. The usual cause is that a more specific field-level ACL is failing its condition or script, even though the record-level ACL passes. Always check the most specific matching ACL first, because evaluation goes from specific to general.