ServiceNow ACL scripting
Go beyond point-and-click security with scripted access-control conditions.
An ACL in ServiceNow decides who can read, write, create or delete a table, record or field. An operation passes only when the condition, the role requirement and the script all allow it, and no matching ACL means deny. The script returns answer as true or false for logic the form cannot express. Debug Security Rules shows which ACL decided.
- How an ACL evaluates
- Debugging access
- Good habits
- Try it Yourself
Access Control Rules (ACLs) decide who can read, write, create or delete a record or field. Most are configured with roles and conditions, but the real power comes from the script field: a snippet that returns answer = true/false for logic the UI can't express.
How an ACL evaluates
An operation is allowed only if all three gates pass: the condition, the role requirement, and the script. Any one returning false denies access. ACLs also cascade from field → record → table.
answer (not return). Keep scripts fast and side-effect-free, they run on every record the user touches, so a slow ACL script is a platform-wide performance problem.Debugging access
Use Debug Security Rules to see exactly which ACL granted or denied an operation, the fastest way to resolve 'Security constraints' errors. Remember: no matching ACL at all means deny by default.
Good habits
- Prefer roles and conditions; reach for script only when necessary.
- Never run heavy GlideRecord queries inside an ACL.
- Test as a non-admin, admins bypass most ACLs.
▸ Press Run to execute.
Runs in a sandbox in your browser. Mock gs and GlideRecord and sample data are provided.