Configuring ACLs the Right Way

[pratikbhatt]

Persona: Admins, architects, and developers who own access control configuration

Successful access control implementation requires strategic planning before configuration. Planning Your Access Control Strategy covers essential decision-making frameworks: choosing between Allow-If and Deny-Unless ACL types, applying the four-layer evaluation funnel (roles/security attributes → data conditions → reference controls → scripts), strategically placing ACLs within the table hierarchy to minimize complexity, and determining when to use Security Data Filters versus ACLs. The guide emphasizes starting with fast, broad security checks and narrowing to resource-intensive evaluations only when necessary—an approach that creates maintainable, auditable, and performant access control implementations aligned with organizational security requirements.

Overview

Effective ACL management leverages ServiceNow's table inheritance model to create a scalable, maintainable security architecture. By strategically placing common constraints on parent tables and specializing rules only where needed on child tables, administrators can minimize ACL proliferation while maintaining clear security boundaries. Understanding the performance and evaluation differences between table-level ACLs (evaluated once per record), wildcard ACLs (evaluated per field), and field-specific ACLs (for granular protection) is essential for balancing security requirements with system performance. Beyond basic placement, successful ACL management requires consolidating duplicate rules, planning for edge cases like administrator overrides and complete access denial, and ensuring comprehensive coverage across scoped applications, database views, and archive tables to prevent unintended backdoor access through the table hierarchy.

Start with the ACL form—from left to right

Think of the ACL form elements as dials you turn in a specific order. Configure the fastest, broadest checks first:

1. Required Roles – Use when any one of a set of roles is sufficient. If multiple ACLs differ only by roles, merge them.
2. Security Attributes – Ideal for user/env logic (e.g., UserIsAuthenticated, Role, RoleExplicit, group membership via attributes). Reusable across ACLs and Security Data Filters.
3. Data Condition – Scope to subsets of records; prefer indexed fields to avoid slow evaluations.
4. Controlled by Reference – Grant access to a record when the user has access to a referenced record (dot‑walkable). Great for “can see incidents for services I can work on.”
5. Script – Only if nothing else suffices. Keep it tiny and consistent (see script patterns below).

Managing ACLs in the table hierarchy

ServiceNow's table inheritance model means that ACLs placed on parent tables automatically apply to child tables. This hierarchy is a powerful tool for minimizing ACL count and maintaining a comprehensible security posture—but only if you plan your placement carefully.

Put common constraints higher (on parent tables). Then specialize deeper down. This minimizes ACL count and keeps your access posture comprehensible.

Understanding Table, Table.*, and Table.Field ACLs

Table ACLs (name = table):

Use table ACLs when the same requirements apply to all fields on a table. A table ACL is evaluated once for the entire table and applies to all fields unless more specific ACLs exist. This is the most efficient approach and should be your default choice.

Table.* ACLs:

The wildcard (table.*) ACL applies to all fields but is evaluated per field. Use this sparingly—only when you need to mask inherited permissions at the field level across the board. Because it runs per field, it's more resource-intensive than table ACLs. Rely on table level ACL if you want access to be applied to all fields however, we know there can be use case like overriding parent table.* ACL or enforcing access for parent fields on child table.

Table.Field ACLs:

Field-level ACLs (table.field_name) provide the most granular control. Use them for least-privilege field access that deviates from the table rule—for example, protecting PII columns, sensitive financial data, or fields containing credentials. Remember: a user must pass both the table ACL and any field ACL to access a specific field.

Consolidate ACLs that differ only by roles

If multiple ACLs have identical logic but different roles, combine them. Fewer ACLs = easier audits and fewer surprises.

Plan for admin and nobody scenarios

To prevent administrator access, plan to uncheck Admin Overrides and use a Security Attribute like RoleExplicit AND Impersonating=false so even elevated users must meet your explicit conditions.

To lock a resource to no one, the “Nobody” role can deny access to everyone (including sysadmins and maint), but use with extreme care.

Scope and Database View

If your app’s records live in another scope’s table, you’ll still need an ACL in your scope (unless both scopes are application administrator enabled). Plan ACL coverage across all relevant tables in the hierarchy to avoid backdoor access via parent tables.

Database views and archive tables can inherit ACLs from underlying tables or have their own; validate glide.security.enable_archive_table_acls=true for archive table specific ACLs.

Next Step:

Learn more about how to troubleshoot access control.

Additional Resources

Next Step: Learn more about troubleshooting access control.

For more information, consult the following ServiceNow documentation:

• ServiceNow University – Introduction to Access Controls
• Access Control List Rules Documentation
• Security Data Filters Documentation
• New Access Control Features (Xanadu/Yokohama/Zurich)
• Planning your access control strategy