How-to Guides · LessonBy Neelima, ServiceNow Architect · Published · ServiceNow · all levels
Write an ACL
Build a record ACL step by step, test it with impersonation, and debug it with the security debugger.
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
Practice challenge
+0 XPStreak ×0
Question 1 of 2
Which role is required to edit ACLs?
Frequently asked questions
Why can a user still see a field I locked?
A less specific ACL is granting access, often a wildcard field ACL on the parent table. The debugger names it.
Should ACL scripts query other tables?
Sparingly. ACL scripts run for every row rendered, so heavy queries there are a direct performance problem.