Access Control Lists (ACLs) let you restrict who can read, write, create, or delete records on specific tables or fields. This guide walks you through creating an ACL rule that controls user access based on roles and custom conditions.
The problem with default permissions
ServiceNow's default security model gives users broad access based on their role assignments — if you can read one Incident, you can usually read them all. This breaks down fast when you need granular control: HR records that only HR can see, incidents assigned to specific teams, or financial data restricted by department. Without ACLs, you're either locking down too much (breaking workflows) or leaving sensitive data exposed. Platform admins and security teams inherit this mess when compliance audits reveal users accessing records they shouldn't touch.
How ACL rules layer on security
ACL rules work by denying access first, then checking if the user passes your conditions. Each rule targets a specific table.field combination (like incident.description) or an entire table (incident.*) and specifies an operation (read, write, create, delete, execute). ServiceNow evaluates all matching ACL rules — if any one passes, access is granted. Start with role-based rules for broad permissions, then add script-based conditions for complex logic like 'assigned user can always read' or 'managers can read their team's records'. The Name field format matters: use table.* for table-level access or table.field for field-specific control.
Building production-ready access control
Basic ACL rules check roles and maybe one condition. Production ACL implementations layer multiple rules strategically: restrictive base rules that deny most access, role-based rules for standard permissions, and condition-based rules for business logic exceptions. Add debugging conditions that log access attempts during testing. Performance matters — ACL script conditions run on every query, so avoid expensive database lookups. The best ACL designs document the security model clearly because debugging access issues six months later is painful without understanding the original intent.
Before you start
- •security_admin role or admin role
- •Elevated privileges (you'll be prompted to provide credentials)
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Access Control
Go to System Security > Access Control (ACL). ServiceNow will prompt for credential verification because you're accessing security settings. Enter your credentials to elevate to security admin. You'll see the Access Control list showing existing ACL rules organized by table and operation.
Filter by Table to see existing rules for the table you're about to secure — understanding the current rule set prevents conflicts.
Create the new ACL rule
Click New to create an ACL rule. In the Name field, enter the target using the format table.field (like incident.description) for field-level control or table.* (like incident.*) for table-level control. Select the Operation from the dropdown: read (view records), write (update existing), create (insert new), delete (remove records), or execute (for processors or script actions).
Use table.* operations sparingly — they're powerful but can accidentally block legitimate access to related functionality.
Set the access type
Choose the Type: select 'record' for most use cases (controls access to data records) or 'ui' for interface elements like forms and lists. Set Active to true. The Description field helps future admins understand the rule's purpose — write something like 'Restrict incident updates to assigned user and IT staff'.
Configure role requirements
Click the Roles tab and add any roles that should automatically pass this ACL rule. Use the slushbucket to move roles from Available to Selected. Users with these roles will have access regardless of other conditions. Leave empty if you want the rule to depend entirely on script conditions or if this is a restrictive rule meant to deny access.
Add condition logic
In the Condition field, enter filter conditions using the query builder if you need simple field-based logic. For complex business rules, leave Condition empty and use the Script field instead. The Script field accepts JavaScript and has access to 'current' (the record being accessed) and 'gs' (global system functions). Return true to grant access, false to deny.
Test and save the rule
Click Submit to save the ACL rule. Test immediately by impersonating a user who should be affected by this rule, then try to access the restricted table or field. ACL changes take effect immediately — no cache clearing required. Check the System Log if access behaves unexpectedly.
Best practices
Never put expensive database queries in ACL scripts — they run on every record access and will crater performance.
Document your ACL strategy in a central location because debugging complex access issues requires understanding the full rule hierarchy.
Test ACL rules with impersonation immediately after creation — access bugs are much easier to fix before users report them.
Use specific table.field ACLs instead of broad table.* rules when you only need to restrict certain fields — overly restrictive rules break related functionality.
Layer ACL rules from most restrictive to most permissive — start with rules that deny access, then add exceptions for specific roles and conditions.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue