ACL Evaluation Order in ServiceNow
Exhibit
Refer to the exhibit.
ACL Condition Script:
(function checkMembership() {
if (gs.hasRole('itil') && current.assignment_group.isMemberOf(gs.getUserID())) {
return true;
}
return false;
})();The exhibit shows an ACL condition script intended to allow read access to an incident only if the user has the 'itil' role and is a member of the incident's assignment group. However, users who are members of the assignment group but do not have the 'itil' role are still able to read the incident. What is the most likely problem?
Quick Answer
This answer is correct because it reflects a key fact about how ServiceNow evaluates security rules: when multiple ACLs exist on the same table and operation, access is granted if any one of them evaluates to true, not only if every ACL agrees. In this scenario, the developer built one ACL that correctly requires both the itil role and assignment group membership, but a second, less restrictive ACL on the same table and operation grants read access to anyone with the itil role alone. That second rule never checks group membership, so the moment it evaluates to true for a qualifying user, access is granted regardless of what the more specific ACL would have decided, and the carefully written condition script never even gets the chance to block anyone. This is a subtle but important behavior to internalize: writing a stricter ACL does not automatically override a looser one that already grants access, because ACL evaluation is additive rather than a strict override chain from most to least specific. Whenever a scenario describes an ACL that seems logically correct but users are still getting access it should be denying, the most likely explanation is that another ACL on the same table and operation is independently granting that access, so the fix is always to audit every ACL touching that table and operation, not just the one you wrote.
⚠ Common exam trap
Many exam-takers assume a single ACL's condition script is evaluated in isolation, when in fact ServiceNow evaluates all ACLs for the same table and operation, and a granting ACL elsewhere can override a denying one.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
There is another ACL on the incident table that grants read access to users with the 'itil' role without the group membership check.
ServiceNow ACLs are evaluated in a hierarchy: if any ACL on the same table and operation grants access, the user is allowed. Even if the intended ACL correctly denies access when the group membership check fails, another ACL that grants read access to users with the 'itil' role (without the group condition) will override the denial. The condition script in the intended ACL never gets a chance to block the user because the granting ACL is evaluated first and returns true.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The condition script must return true explicitly for the ACL to deny access.
Why it's wrong here
ACLs with condition scripts return true to grant, false to deny, which is correct.
- ✗
The ACL is set to condition type 'script' but the script is not structured correctly.
Why it's wrong here
The script structure is valid.
- ✗
The isMemberOf method requires a group sys_id, not a user ID.
Why it's wrong here
isMemberOf is a method on a GlideRecord field that checks if a user is a member of the group. The argument is the user ID, which is correct.
- ✓
There is another ACL on the incident table that grants read access to users with the 'itil' role without the group membership check.
Why this is correct
If another ACL grants access, it overrides the denial from this ACL.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every SNOW-CAD question from scratch — 481 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SNOW-CAD
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A developer implemented an ACL to restrict read access on the 'incident' table. The condition script checks if the user is a member of the 'incident_manager' group. However, users who are not in the group are still able to see incidents. What is the most likely reason?
hard- ✓ A.There is another ACL with a lower order that grants read access to all users, and the evaluation never reaches the scripted ACL.
- B.The ACL is cached and users need to log out and back in for changes to take effect.
- C.The condition script returns 'true' for users in the group but does not return 'false' for others, so the ACL defaults to 'no decision' and access is allowed.
- D.The ACL is set to 'Inactive' so it does not apply, leaving access open.
Why A: ACLs in ServiceNow are evaluated in order of their 'Order' field (lower numbers first). If a lower-order ACL grants read access to all users, the evaluation stops at that ACL and never reaches the scripted ACL that restricts access to the 'incident_manager' group. This is the most common reason for an ACL appearing to not work — a broader, higher-priority ACL is allowing access before the restrictive one is evaluated.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SNOW-CAD practice question is part of Courseiva's free ServiceNow certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SNOW-CAD exam.