ServiceNow Access Control List (ACL) Explained

What Is an Access Control List in ServiceNow

An Access Control List (ACL) is a rule that defines who can do what with what data in ServiceNow. ACLs are the foundation of security—they prevent users from seeing data they shouldn’t see, creating records they shouldn’t create, or modifying records they shouldn’t touch. Without ACLs, any authenticated user could read any data and modify anything. ACLs make ServiceNow multi-tenant safe—different departments can use the same ServiceNow instance without seeing each other’s confidential information. At their simplest, ACLs answer three questions: who (which user or role), what (which operation—read, create, update, delete), and on what (which table or record).

How ACLs Work

ServiceNow evaluates ACLs whenever a user attempts an action. When you open an Incident record, ServiceNow checks whether your role or user account has read permission for the incident table. If yes, the page loads. If no, you see an error. When you try to update a field, ServiceNow checks whether you have update permission for that table. If you don’t, the field is read-only or you get an error. When you search for incidents, ServiceNow applies ACLs to filter results—you only see incidents you’re allowed to see. This happens silently in the background; you don’t see an ACL rule execute. You just notice that your search results show fewer records than expected (because you don’t have access to all of them) or that certain fields are read-only.

Role-Based and Record-Based ACLs

ACLs can be role-based: “anyone with the incident_manager role can update any incident”. Or they can be record-based (conditional): “you can only update an incident if you’re on the assignment group”. Role-based ACLs are simpler to configure and understand. Everyone with a role gets the same permissions everywhere. Record-based ACLs are more granular but require more configuration. They let you implement rules like “employees can update their own service requests but not others’ requests” or “incident managers can update any incident except those assigned to other teams”. Most implementations mix both—a base set of permissions by role, with exceptions for sensitive data or special cases.

Common ACL Patterns

A typical service desk implementation has these ACLs: users can create and update their own service requests but not others’. Support analysts can read all service requests and update those assigned to their group. Managers can read all service requests and reassign them between teams. Restricted data (like passwords in knowledge articles) has tighter ACLs—only specific groups can access it. Financial data (cost of assets, service pricing) might be visible to IT staff but hidden from customers. These patterns protect sensitive information while allowing work to flow efficiently. Without clear ACL design, you end up either too restrictive (staff can’t do their jobs) or too permissive (security risk).

ACL Configuration and Governance

ACLs are configured by administrators during implementation and updated as roles and responsibilities change. Configuration requires careful thought about what each role needs to see and do. It’s tempting to grant broad permissions to “just in case” people need them, but this creates security risk. Better approach: grant minimum necessary permissions, then add more permissions when users explicitly need them. Document your ACLs so it’s clear why each rule exists and what it protects. Review ACLs periodically to ensure they still match your operating model—as your organisation changes, some ACLs become outdated and others are no longer needed.

Troubleshooting ACL Problems

When users report they can’t see data or modify records, ACLs are often the cause. To debug, you need to know which user, which table, which operation (read, create, update, delete), and which record. Then search for ACLs that might apply. Does the user’s role match the role in the ACL? If the ACL is conditional, does the record match the condition? You might discover you have conflicting rules—one ACL allows access and another denies it. When several ACL rules match the same operation, the platform evaluates each rule’s roles, conditions and scripts, so an assumption that the first match decides the outcome can give a wrong answer. If rules are misunderstand, access can be denied unexpectedly. Documentation and clear rule ordering prevents this confusion. Many organisations have an ACL that denies access to sensitive tables for all users except a specific group; this rule is listed first so it takes precedence over more general allow rules.

Performance Implications

Complex ACLs can affect performance, especially record-based ACLs that require evaluation of conditions for every record. If you query a table with thousands of records and apply conditional ACLs that evaluate user group membership for each record, the query takes longer because of the ACL evaluation overhead. This is usually acceptable, but it’s worth monitoring if performance seems slow. Sometimes you can improve performance by using role-based ACLs (which are evaluated once per user) instead of record-based ACLs (which are evaluated per record).

ACLs and Custom Development

Custom scripts and integrations must also respect ACLs. If you write a script that queries the incident table, it only returns incidents the script’s service account is allowed to see according to ACLs. If your service account doesn’t have permission to access a field, the script can’t read that field. This is usually good—it means your scripts automatically respect security rules. But it can surprise developers who expect scripts to have full access. If you need a script to access data that normal users can’t, you may need to create a service account with special ACL permissions, or modify the script to run with elevated privileges through a workflow API rather than directly querying the table.

A diagnostic order for a read that is denied

When a user says they cannot see a record, the instinct is to open the access rules and start reading. That is slow and often misleading, because the denial may come from a role, a field, a script or a view rather than from the rule the administrator has in mind. A fixed order of checks finds the cause faster. Start with the user’s roles and the record’s own values, then move to the table rules, then to the field rules, and only then to scripts and integrations. Each step either explains the denial or rules out a layer.

This section is for platform administrators and service desk leads who receive access complaints and need to answer them without guessing. It assumes the instance has a rule set that has grown over time and that more than one team has edited it.

1. Confirm the user, the table, the operation (read, create, write or delete) and the specific record or field.
2. Check whether the user’s roles include the role the rule names, including roles inherited through a group.
3. Check the record’s own values against any condition in the rule, such as assignment group or company.
4. Check the table-level rule, then any field-level rule on the field the user cannot see or change.
5. Check the access settings on the view or list the user is working from, since a view can hide a field a rule would allow.
6. If the user is in an integration or a scheduled job, check which identity the job runs as and whether the script uses the secure record class.

Rules that look correct and still fail

Some of the most confusing denials come from rules that are right on paper. A condition that tests the assignment group can deny a manager who reads the record through a parent relationship, because the group on the parent is not the one the rule checks. A field rule that protects a sensitive value can also block a report that counts records by that value, so the report returns zero rather than an error. When a denial appears to contradict the rule, test the condition against the actual record values rather than against what the rule’s description says.

Reviewing access rules without breaking the service desk

A rule review is a control that helps prevent many long-term access problems. Its aim is to find rules that no longer match the roles people hold, and to remove the ones that grant more than they should. For a fuller checklist, see the access controls review guide. Run the review on a schedule with the service owner present, and start with the tables that hold the most sensitive data or the most users. Remove rules in a test copy first, then in production with a rollback plan, because a removed rule that a process depends on will fail quietly until someone notices.

1. Export the rule list for each sensitive table and mark rules with no recorded owner.
2. Ask the owner of each rule to state the role or condition it protects, and whether it still applies.
3. Remove or narrow rules that grant broad access without a stated purpose.
4. Test the affected processes with a user from each role before the change goes live.
5. Record the change, the reviewer and the date against the rule.

Performance and the cost of conditions

Record-level conditions cost more to evaluate as tables grow, particularly when a condition calls a script or walks a relationship for every row. A list view on a large table can slow down noticeably after a condition is added, and the slowdown is often blamed on the report rather than the rule. Where a condition is needed, keep it simple, test it on a table of realistic size and remove any condition that duplicates a role-based grant. For automation that depends on the same data, see the business rule guide.

Questions administrators ask about access rules

Is an admin role exempt from access rules?

Administrator roles can bypass many access checks, which is why they should be held by few people and reviewed often. Where data must also be split by organization, the domain separation guide applies. An admin account used for routine work hides the effect of the rules from the person who wrote them, so testing should be done with ordinary roles.

Why does a script see records that a user cannot?

Because the script runs under an identity with broader access, or because it uses the standard record class, which does not apply the same checks as a user session. Confirm the identity and the record class before assuming the rule is wrong.

Should every field have its own rule?

No. Field rules are for fields with a real reason to be restricted, such as pay, health or investigation data. A rule on every field adds evaluation cost and makes the access model very hard to read.

How do we test a rule change safely?

Use a test copy with users in each role, record the expected result for each action, and repeat the check after the change. A change that passes for the administrator alone has not been tested.

If access complaints keep reaching the platform team, reviewing the rule set can separate the rules that protect data from the ones that only add confusion.