Does the ACL doc state that the user must fail all table ACL's in order to be denied access?

[David Dietrich1]

ServiceNow ACL documentation describes behavior that differs from what I'm seeing in my environment. ACL documentation states: "If a user fails all table ACL rules, the user cannot access any fields in the table. If a user passes a table ACL rule, the system then evaluates the field ACL rules." (ACL rule types (servicenow.com)).

However, the behavior I am seeing is that if:

1. There is a table ACL that matches the table name
2. There is a wildcard ACL that matches any table name (*)
3. The table ACL denies access.
4. The wildcard ACL allows access.

...then ServiceNow stops evaluating ACL rules when it matches the table ACL and denies access. Based on the above documentation, I expected ServiceNow to continue searching for an ACL that would allow access. Why does the ACL doc state that the user must fail all table ACL's in order to be denied access, when in reality, the user only needs to fail one table ACL to be denied access?

[sushantmalsure · Accepted solution]

Suppose you have 3 table level ACLs on incident table:

scenario 1: If 1 ACL denies access and 2 ACLs allows the access: then user gets the access of said operation

scenario 2: if all ACLs denies access for said operation then user will be denied the access.

Now here comes the Scenario of widcard table (*)

If there is no table level ACL is present for incident table then ServiceNow will evaluate * ACL

if that ACL is denied access then user will not get access or wise versa.

So if you have overridden * ACLs by creating table specific ACL then * ACL will not be evaluated.

This is what I have learned , may be useful to understand ..

[David Dietrich1]

It seems that although the behavior your describe is not explained anywhere in the text of the ACL documentation, it is implied by the acl-matching diagram on the ACL Rule Types doc.