ACL types
- Record (table) — controls access to an entire table or specific records
- Field — controls access to a specific field on a table
- UI Action — controls visibility of buttons and menu items
- Business Rule — rarely used directly for access control
ACL operations
Each ACL is associated with an operation:
- read — can the user see this record/field?
- write — can the user modify this field?
- create — can the user create records on this table?
- delete — can the user delete records on this table?
How ACLs are evaluated
When a user tries to access a record, ServiceNow evaluates all applicable ACLs in order of specificity. More specific ACLs (table.field) override less specific ones (table.*).
An ACL passes if: the user has the required role AND the condition script returns true. If no ACL matches, access is denied by default.
Script ACLs
For dynamic access control, use the Script field on the ACL. Return true to grant access, false to deny:
// Grant access only if assigned to current user
answer = (current.assigned_to == gs.getUserID());
// Grant access if user has role OR is the caller
answer = gs.hasRole('itil') || (current.caller_id == gs.getUserID());Elevated privilege ACLs
Roles with "Elevated privilege" require the user to explicitly elevate (re-authenticate) before the role grants access. Used for admin-level operations that require conscious intent.
Debugging ACL issues
Navigate to System Security > Access Control (ACL) and use the Security Policy Check page to test whether a specific user can access a specific table/field. Always check here before assuming a display issue is a UI problem.
Common mistakes
Mistake: Creating an ACL on a table with a script that queries another table — this can cause circular queries and performance issues. Keep ACL scripts lightweight.
Mistake: Forgetting that field-level ACLs stack with table-level ACLs. A user needs to pass both the table read ACL and the field read ACL to see a field's value.