Issue
Access Controls (ACLs) can be complex when securing your instance. This article clarifies how ACLs are evaluated — with table-level access (Gate 1) checked before field-level access (Gate 2) — and explains how to configure them effectively.
Symptoms
- Users unexpectedly denied or granted access to fields despite ACLs being present.
- Field-level ACLs seem to be ignored even when defined.
- Admin override behavior is inconsistent or fails entirely.
- Dot-walked fields not displaying correctly in list views.
Facts
- ACLs must pass all three checks: roles, condition, script.
- Table-level ACLs are required before field-level ACLs are evaluated.
- The Admin Overrides checkbox must be consistent across ACLs for it to work properly.
- List views do not load all columns by default; only visible fields are retrieved.
Release
Applicable to all releases supporting ACLs; confirmed behavior as of the Yokohama release.
Cause
Misunderstanding of the ACL evaluation order leads to incorrectly configured security rules, causing unexpected access issues or overly permissive behavior.
Resolution
ServiceNow uses a two-gate ACL evaluation system:
Gate 1 – Table-Level ACLs (evaluated first):
- ACL Name:
table
- Field:
--None--
- Type:
record
Checked to determine if the user can access the record at all.
If no ACL is found, the system checks the parent table(s), then falls back to a wildcard (*
) rule.
Gate 2 – Field-Level ACLs (evaluated after table access):
- ACL Name:
table.field
- Type:
record
- Used to control access to specific fields after the user passes the table-level check.
Field ACL evaluation order:
table.field
parent_table.field
table.*
parent_table.*
*.*
Admin Overrides:
If enabled on all relevant ACLs, users with the admin
role bypass ACL conditions. If any ACL in the chain lacks this setting, overrides will not apply.
List View Considerations:
Field ACLs referencing other fields (especially via dot-walk) require the referenced field to be visible in the list and placed before the evaluated field.