Write an ACL
Quick answer
Build a record ACL step by step, test it with impersonation, and debug it with the security debugger.
Key takeaways
- Table and field ACLs both apply, and both must pass
- Elevate to security_admin before editing ACLs
- The security debugger shows the deciding rule
- Test with impersonation every time
Understand the evaluation
Access is granted when the table level ACL passes and the field level ACL passes. Each ACL has three gates: the role list, the condition and the script. All three must pass, and the most specific matching ACL wins.
Create the rule
Elevate to security_admin, then create the ACL on the table and operation you need.
// Record ACL: incident.write, roles: itil
// Condition: state != 7
// Script:
answer = gs.hasRole('itil_admin') || current.assignment_group.getRefRecord().isMember(gs.getUserID());Test and debug
Never assume an ACL works because it saved.
- Impersonate a user with the role and one without it
- Turn on the security debugger to see which ACL granted or denied
- Check both table and field ACLs, a wildcard field ACL often overrides your intent
- Document the business rule behind the ACL in its description
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
Which role is required to edit ACLs?
- A. admin
- B. security_admin elevated
- C. itil_admin
- D. impersonator
Show answer
B. security_admin elevated
Editing ACLs requires elevating to security_admin.
What must pass for access to be granted?
- A. Role only
- B. Condition only
- C. Roles, condition and script
- D. Any one of the three
Show answer
C. Roles, condition and script
All three gates on the matching ACL must pass.