acl-security

ACL Security Patterns for ServiceNow

Access Control Lists (ACLs) are the foundation of ServiceNow security. They control who can read, write, create, and delete records.

Which ACLs can apply

An ACL applies by name, and the name is literal — sys_security_acl.name holds incident.priority or *, never a glob pattern. For one field on a table that extends another, six names can each carry a rule:

Name	Carries the rule for
incident.priority	this field on this table
task.priority	this field on a parent table
*.priority	a field of this name on any table
incident.*	any field on this table
task.*	any field on a parent table
*.*	any field on any table

Alongside them are the record-level names: incident, then each parent table in the sys_db_object.super_class chain, then *.

Two of those forms are confirmed against live instances: the record-level * (the ACL probe behind sn-roles.manifest.json resolved 189 tool primitives through it) and table.field (snow_analyze_form reads field ACLs with nameSTARTSWITH<table>.). The readings above for *.priority, incident.* and *.* follow the same naming scheme but are not sourced to ServiceNow's own documentation — treat them as names worth checking, not as documented behaviour. snow_acl_explain checks all of them either way, and a name nobody uses simply returns nothing.

Look at all of them. Stopping at incident.priority names the wrong blocker in exactly the case you are debugging — when the rule carrying the roles sits on task or on a wildcard.

snow_acl_explain collects the whole set in one call: it walks sys_db_object.super_class for the parent names, reads each matching rule's required roles out of the sys_security_acl_role m2m (there is no roles column on sys_security_acl, so anything reading one reports no roles at all), and diffs those against the roles a user holds in sys_user_has_role — which already includes inherited roles, so there is no need to expand sys_user_role_contains yourself.