ACLs & security in ServiceNow Administration

ACLs & security

Control who can see and do what, right down to the field.

Quick answer

Access Control Rules, ACLs, are the platform's row- and field-level security. Every read, write, create and delete a user attempts is checked against them. They are powerful and, at first, genuinely confusing; this lesson makes the evaluation model concrete so you can debug "why can't this user see this field?" with confidence.

Key takeaways

Anatomy of an ACL
How evaluation actually works
Debugging with Security Debug
The high-security posture
ACLs vs the other layers

Access Control Rules, ACLs, are the platform's row- and field-level security. Every read, write, create and delete a user attempts is checked against them. They are powerful and, at first, genuinely confusing; this lesson makes the evaluation model concrete so you can debug "why can't this user see this field?" with confidence.

Anatomy of an ACL

An ACL protects an object (a table, a specific field, or a wildcard) for one operation (read / write / create / delete). It grants access only if all three of its checks pass:

Condition

A field condition that must evaluate true.

Roles

The user must hold at least one of the listed roles (empty = no role needed).

Script

Optional; must set answer = true.

// Field ACL script: incident.number [read]
answer = false;
if (current.caller_id == gs.getUserID() || gs.hasRole('itil')) {
  answer = true;   // callers see their own; itil sees all
}

How evaluation actually works

Two things trip everyone up:

Two levels must both pass. A read of a field is checked against the table/row ACL and the field ACL. Fail either and access is denied.
Most specific wins. ServiceNow evaluates from most specific to most general, and stops at the most specific matching set:

incident.number     (1) field-specific
incident.*          (2) table + field wildcard
*.number            (3) any-table, this field
*.*                 (4) global fallback

If a specific matching ACL exists and denies, more general ones do not rescue it. Within the matching level, if any ACL grants (roles + condition + script all pass), access is granted.

Debugging with Security Debug

Turn on Debug Security Rules (or Session Debug › Security). Every field then annotates which ACL granted or denied it and why, the single fastest way to resolve an access question. Combine with impersonation to test as the affected user.

The high-security posture

Default deny. With the high-security plugin, if no ACL grants access, access is denied. Editing high-security ACLs requires elevating to the security_admin role for the session. Keep ACL scripts to a boolean access decision, never business logic.

ACLs vs the other layers

ACLs are the ultimate authority on access. A data/UI policy can make a field mandatory or read-only, but no policy can grant write access the user's ACL denies. Query business rules can also filter what a user sees, but they operate before ACLs and for different reasons, don't confuse the two.

Common mistakes

Editing a table ACL when the block is actually a field ACL (or vice versa).
Putting business logic in an ACL script instead of a simple boolean decision.
Forgetting a user must pass both the row and the field rule.
Expecting a general ACL to override a denying specific one.

Practice challenge

+0 XPStreak ×0

Question 1 of 3

If no ACL matches a request, access is:

Frequently asked questions

What else is worth knowing about ACLs & security?

An ACL protects an object (a table, a specific field, or a wildcard) for one operation (read / write / create / delete).

What is the practical takeaway on ACLs & security?

If a specific matching ACL exists and denies, more general ones do not rescue it.

What tends to go wrong with ACLs & security?

Editing a table ACL when the block is actually a field ACL (or vice versa). Putting business logic in an ACL script instead of a simple boolean decision. Forgetting a user must pass both the row and the field rule.