Skip to content
IT Canvass
Administration · Lesson

ACLs & security

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.

Want to learn this properly?

Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.

Check your understanding

  1. If no ACL matches a request, access is:

    • A. Granted
    • B. Denied
    • C. Cached
    Show answer

    B. Denied

    ServiceNow denies by default when no ACL grants access.

  2. To hide a single sensitive column you use a:

    • A. Field-level ACL
    • B. Business rule
    • C. Report
    Show answer

    A. Field-level ACL

    Field-level ACLs control individual fields.

  3. Which is NOT an ACL operation?

    • A. Read
    • B. Write
    • C. Compile
    Show answer

    C. Compile

    Operations are read, write, create and delete.

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.
CallWhatsAppEnquire