Field-level ACLs let you hide sensitive data from certain users or make specific fields read-only for some groups while keeping them editable for others. You'll create a targeted access control that applies to just one field instead of entire records.
Why field-level access controls exist
Before field-level ACLs, you controlled access at the table level — users could see all fields or none. That meant creating separate forms, hiding fields with client scripts, or building custom applications just to keep salary data away from non-HR staff or prevent junior technicians from editing priority fields. Platform admins ended up maintaining complex UI policies and business rules to simulate field-level security, which was fragile and didn't work consistently across all interfaces.
How field-level ACLs work
A field-level ACL is a security rule that targets one field using the format table.field_name. The operation determines what happens: 'read' controls visibility (pass = user sees the value, fail = field appears empty), 'write' controls editability (pass = user can modify, fail = field becomes read-only). ServiceNow evaluates these ACLs before rendering forms, lists, and API responses. The script you write returns true or false, and that boolean drives whether the user gets access. Unlike table ACLs, you can stack multiple field ACLs on the same field with different conditions.
Building production-quality field security
Start with simple role-based conditions, then layer on more sophisticated logic like checking group membership, field values on the current record, or related records. Add logging to your ACL scripts so you can troubleshoot access issues later. Most importantly, remember that ACLs only control UI and API access — server-side scripts (Business Rules, Script Includes) can still read and write ACL-protected fields. For truly sensitive data, you need both ACLs for user access and careful coding practices for server-side operations.
Before you start
- •security_admin role or admin role
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 Controls
Go to System Security > Access Control (ACL) > Access Control. This opens the list of all ACL records. You'll create a new one that targets your specific field rather than an entire table.
Create the ACL record
Click New to create a new Access Control record. Set the Type to 'record' (not 'operation'). In the Name field, enter the exact format: table.field_name, like 'incident.u_salary' or 'sc_request.approval_history'. This naming convention tells ServiceNow which field this ACL protects.
Use the actual table name from the dictionary, not the display label — 'sc_request' not 'Service Catalog Request'.
Set the operation type
Choose the Operation: 'read' to control visibility (users who fail this ACL see an empty field), or 'write' to control editing (users who fail see the value but can't change it). You can create separate ACL records for read and write on the same field if you need different logic for each.
Most field ACLs use 'read' — if users can't see the field, they can't edit it either.
Configure basic access conditions
Check 'Active' to enable the ACL. Set 'Requires role' to a role that should have access, or leave it empty if you're handling all logic in the script. The 'Requires role' field acts as a quick filter before your script runs — if the user lacks this role, they automatically fail without running your code.
Write the access script
In the Script field, write JavaScript that returns true (grant access) or false (deny access). You have access to 'current' (the record being viewed) and 'gs' (GlideSystem). Common patterns: check roles with 'gs.hasRole("role_name")', verify group membership, or evaluate field values on the current record. Keep the logic simple and fast.
Test your script logic in a background script first — ACL debugging is harder once the rule is active.
Test the ACL behavior
Save the ACL record and impersonate a user who should be affected by this rule. Navigate to a record that contains your protected field and verify the behavior: for read ACLs, the field should be empty for denied users; for write ACLs, the field should be read-only (grayed out). Test both positive and negative cases to confirm your logic works.
Verify cross-interface consistency
Check that your ACL works consistently across forms, lists, and reports. Open the affected table's list view and verify that denied users don't see values in that column. Run a report that includes the field to confirm it's filtered there too. Field ACLs should behave the same everywhere, but it's worth confirming.
Mobile interfaces sometimes cache field values — test there too if your users access ServiceNow via mobile.
Best practices
Always test field ACLs by impersonating affected users — what looks hidden to you as admin might still be visible to others due to role inheritance.
Keep ACL scripts lightweight since they run on every record access — avoid GlideRecord queries inside the script unless absolutely necessary.
Document field ACLs in the ACL's description because they're not obvious from looking at the form — future admins need to know why the field is restricted.
Remember that server-side scripts bypass ACL restrictions — Business Rules can still read and write ACL-protected fields, which may not be what you want for sensitive data.
Use specific roles rather than generic ones like 'admin' in your ACL conditions — you want granular control over who sees sensitive fields.
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