ACL scripting
Go beyond point-and-click security with scripted access-control conditions.
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
- 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.