Table-level access control lets you restrict who can view or modify records on an entire table based on their assigned roles. You'll create access control rules that either grant or deny access to all records on the table.
Why tables need access restrictions
By default, ServiceNow tables are wide open — any authenticated user can read and modify any record unless you explicitly restrict access. This causes problems when you have sensitive tables like employee records, financial data, or configuration items that should only be accessed by specific teams. Platform admins discover this the hard way when business users start seeing data they shouldn't, or worse, when they accidentally modify records outside their department. Without table-level ACLs, you're relying on UI policies and client scripts to hide data, which is security theater — the data is still accessible through web services and other interfaces.
How table-level access control works
Table ACLs operate on the 'deny by default' principle once you create them. You create separate ACL records for read operations (viewing records) and write operations (creating, updating, deleting). Each ACL specifies which roles are required to perform that operation. ServiceNow evaluates these rules before any database operation — if a user doesn't have the required role, they get an access denied error. Role inheritance applies, so users with parent roles automatically inherit access from child roles. The key decision is whether you need table-level restrictions (all records) or record-level restrictions (specific records based on conditions).
Expanding beyond basic table restrictions
Most implementations start with simple role-based table access and evolve toward more sophisticated controls. Record-level ACLs with condition scripts let you restrict access based on field values — like showing users only records from their department or location. You can also create field-level ACLs to hide sensitive columns even when users can access the table. Advanced setups use ACL scripts for dynamic role checking, integrate with HR systems for org-chart-based access, or implement time-based restrictions where access expires automatically.
Before you start
- •security_admin role or higher
- •Target table already exists and has records to test with
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) in the Application Navigator. This opens the Access Control Rules list where you'll create new table-level restrictions. You'll see existing ACL records for other tables — each row represents one permission check that ServiceNow performs.
Filter the list by table name to see if any ACLs already exist for your target table.
Create the read access control
Click New to create a new ACL record. Set Type to 'record', Name to your target table name (not display name), and Operation to 'read'. Leave the Admin overrides field as true — this lets users with admin role bypass the restriction. Check the Active checkbox to enable the rule immediately.
Use the exact table name like 'incident' or 'change_request', not the display label.
Set the required role for reading
In the Requires role field, select the role users need to view records on this table. ServiceNow will deny read access to anyone without this role or a parent role. Click Save to create the read ACL.
Choose specific functional roles like 'hr_admin' rather than generic roles like 'user' for better security.
Create the write access control
Click New again to create a second ACL for write operations. Set the same table name but change Operation to 'write'. This controls who can create, update, or delete records on the table. Set the same or more restrictive role in the Requires role field and save the record.
Write access typically requires the same role as read access or higher — users can't modify what they can't see.
Test the access restriction
Log in as a user without the required role and try to access the restricted table. Navigate to the table's list view — you should see an 'Access Denied' message or no records. Users with the correct role should see records normally. Test both read access (viewing records) and write access (creating or updating records).
Use an incognito browser window or impersonate a user to avoid role conflicts with your admin session.
Best practices
Always create both read and write ACLs for complete table protection — having only a read ACL still allows unauthorized users to create records.
Keep Admin overrides set to true unless you specifically need to restrict admin users — you'll lock yourself out of troubleshooting otherwise.
Use the most specific role possible rather than broad roles like 'itil' — this follows the principle of least privilege and makes access management clearer.
Test ACL changes immediately after creation using impersonation or a test user account — ACL bugs are difficult to debug once users start reporting access issues.
Document why each table restriction exists in the ACL record's Description field — future admins need to understand the business justification before making changes.
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