An access control list decides whether a user may read or write a field or record. ACLs layer with roles and table rules, and they can include a script condition for logic that the basic rules cannot express. Getting them right is central to security in the platform.
Before you start
You should be comfortable with roles and tables. This article covers ACL evaluation and scripted conditions.
Step-by-step walkthrough
Step 1: Understand what an ACL protects
An ACL is defined on an operation (read, write, create, delete) for a field or table, and it requires certain roles or a condition. Field-level ACLs can be stricter than table-level ones, so access is checked at both levels.
Step 2: Use scripted conditions sparingly
An ACL script runs a condition that can reference the current user and the record, which handles cases the role rules cannot, such as “own records only”. Keep the script cheap, because it runs on every access check, and return a clear boolean.
Step 3: Test as the actual user
ACLs are easy to misjudge; testing as an admin bypasses them, so verify by impersonating the target user. Debugging access requires checking each applicable ACL, which the platform’s tools help with.
Worked scenario
A scripted ACL allows access to a user’s own records.
// ACL condition: user can read only their own records
answer = current.opened_by == gs.getUserID();Walk through the example
The script returns true only when the record was opened by the current user, which a role alone cannot express. Because it runs on every read, it must be cheap, so it uses a direct field comparison. Testing as the user confirms it behaves as intended.
Common mistake
Relying on roles alone for row-level rules, or writing a heavy ACL script that runs on every access and slows the platform. Another is testing with an admin account, which bypasses the ACL and hides the problem.
Verify the behavior
Impersonate a regular user and confirm they see only their records, then impersonate another user and confirm they see theirs. Check that an admin bypasses the restriction (expected) and that the script does not error on null fields.
Interview exercise
Why is testing ACLs as an admin misleading?
Answer and reasoning
Because admins typically bypass ACLs, so the restriction never applies and the test passes regardless of whether the ACL is correct. Access must be tested as a user with the actual roles, which is the only way to see whether the rule allows and denies as intended.
Continue learning
Compare field rules in ACL evaluation and role design in Scoped applications. Read the ServiceNow ACL documentation and try the ServiceNow interview questions.