SNOW-CSA Application Rules, ACL and Notifications Practice Test 3 — 15 Questions

Question 1

An administrator is troubleshooting an ACL that grants 'write' access to the 'incident' table for the 'itil' role. Despite the ACL being active, users with the 'itil' role cannot update incidents. The administrator confirms that no other write ACLs exist. What is the most likely reason?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The 'Required roles' field on the 'incident' table form layout requires a different role to update.. The most likely reason is that the 'Required roles' field on the 'incident' table form layout restricts update operations to a specific role that the 'itil' users do not have. Even though the ACL grants 'write' access to the 'itil' role, the form layout's 'Required roles' setting overrides ACL permissions by preventing the form from being submitted or updated by users without the specified role. This is a common misconfiguration where form-level restrictions are overlooked during ACL troubleshooting.

Answer

The ACL is defined on a different table that extends 'incident'.

Answer

There is a read ACL that denies read access, which prevents any write operations.

Answer

The table is set to 'High Security' in the application properties.

Question 2

A business rule runs on 'before update' of the 'incident' table and sets the 'assigned_to' field to the current user if the assignment group is empty. The rule is in the global scope. However, when a user from another application scope updates an incident via a web service, the field is not being set. What is the most likely cause?

Accepted Answer

The business rule is not configured to run in the 'System' (global) scope across all applications.. The business rule is in the global scope, but by default, business rules in the global scope only run for updates made within the global scope itself. When a user from another application scope updates an incident via a web service, the update originates from that other scope, and the global-scope business rule does not execute unless it is explicitly configured to run in the 'System' (global) scope across all applications. This is controlled by the 'Run in all scopes' checkbox on the business rule record.

Answer

The user making the web service call does not have the 'itil' role.

Answer

The business rule runs after the web service update and the field is already committed.

Answer

The business rule condition is incorrect for web service updates.

Question 3

An administrator needs to send an email notification to the manager of the caller when an incident is assigned to a specific group. Which combination of notification configuration is correct?

Accepted Answer

Condition: 'Assignment group changes to '; Recipient: Caller's manager.. The requirement is to notify the caller's manager when an incident is assigned to a specific group. The condition 'Assignment group changes to ' triggers the notification precisely when the assignment group changes to the target group, and the recipient 'Caller's manager' ensures the email goes to the manager of the person who reported the incident. This matches the exact business need without extraneous conditions or incorrect recipients.

Answer

Condition: 'Record is inserted'; Recipient: Manager of the assignment group.

Answer

Condition: 'Assigned to changes to Caller's manager'; Recipient: Caller.

Answer

Condition: 'State changes'; Recipient: Caller via email client.

Question 4

An ACL has a condition script that returns true if the user is a member of the 'service_desk' group and the record's 'state' is 'New'. The ACL type is 'read'. A user in the 'service_desk' group reports that they cannot see a record with state 'New'. What is the most likely cause?

Accepted Answer

The condition script does not have a default return false statement, so it returns undefined.. In ServiceNow, ACL condition scripts that lack an explicit return statement will return undefined, which is a falsy value. When the condition script returns undefined, the ACL does not grant read access, effectively denying the user from seeing the record even though they meet the intended group and state criteria. This is a common pitfall where developers forget to add a default return true or return false at the end of the script.

Answer

The ACL is defined on a different table that extends 'incident'.

Answer

The script uses gs.hasRole('service_desk') which checks role, not group membership.

Answer

Another read ACL exists that explicitly denies read access to the 'service_desk' group.

Question 5

An administrator wants to create a notification that sends an email to the 'Assignment group' members whenever an incident is assigned to that group. Which of the following should the administrator configure in the notification's 'Who will receive' list?

Accepted Answer

Assignment group members. The 'Assignment group members' option in the notification's 'Who will receive' list dynamically resolves to all users who are members of the group currently populated in the 'Assignment group' field on the incident record. This ensures that when an incident is assigned to a specific group, every member of that group receives the email notification, which matches the administrator's requirement exactly.

Answer

Group members (on the record)

Answer

Caller

Answer

Assigned user

Question 6

Which TWO of the following are valid ways to define who receives a notification in ServiceNow? (Choose two.)

Accepted Answer

Users in a role. Option B (Users in a role) is correct because ServiceNow notification recipients can be defined by selecting a role, which dynamically resolves to all users assigned that role at send time, making it ideal for role-based alerting. Option E (Email address from a field) is correct because notifications support referencing a field on the record (e.g., the caller's email or an assignment group manager's address) so the recipient is resolved dynamically from record data. Option A (Email address) is not a valid recipient definition on its own in the notification Recipients configuration, since ServiceNow expects a user, group, role, or field reference rather than a hard-coded literal address. Option C (Dynamic recipient) is not an actual recipient type in the notification form; dynamic behavior is achieved through field references and role/group resolution, not a separate 'dynamic recipient' option. Option D (Group) is not one of the two marked correct answers here, as the question's intended correct pair is role-based users and field-sourced email addresses.

Answer

Email address

Answer

Dynamic recipient

Answer

Group

Question 7

Which THREE of the following statements about ACL evaluation are true? (Choose three.)

Accepted Answer

An ACL's 'Requires role' field can have multiple roles separated by commas.. Option C is correct because in ServiceNow ACLs, the 'Requires role' field accepts a comma-separated list of roles, and the user must have at least one of the listed roles for the ACL condition to be satisfied. Option D is correct because when multiple ACLs grant access to the same operation, their results are ORed together, meaning satisfying any one granting ACL allows the operation. Option E is correct because ServiceNow uses a default-deny security model: if no ACL exists for a given operation, access is denied by default. Option A is incorrect because a 'deny' ACL does not globally override all other ACLs; ACL evaluation follows a specific order and deny ACLs apply within that evaluation logic, not as an absolute override. Option B is incorrect because ACLs are not evaluated in alphabetical order by name; they are evaluated based on ACL type, operation, and specificity rules.

Answer

An ACL with type 'deny' will override all other ACLs.

Answer

ACLs are evaluated in alphabetical order by name.

Question 8

Your company uses ServiceNow for IT Service Management. The 'incident' table has a custom 'create' ACL that restricts creation of incidents to users with the 'snc_internal' role. However, external users with the 'snc_external' role should also be able to create incidents via a portal. The portal uses a REST message that authenticates as a specific integration user. The integration user has the 'snc_internal' role. Despite the REST API call being successful, external users report that they cannot submit incidents through the portal. The system logs show that the REST API call returns a success, but the incident record is not created. What is the most likely cause?

Accepted Answer

The ACL is evaluated against the portal user, who lacks the 'snc_internal' role.. ServiceNow ACLs are evaluated against the user who initiated the request, not the integration user making the REST API call. In this scenario, the portal widget executes under the context of the portal user (who lacks 'snc_internal'), so the 'create' ACL on the 'incident' table checks that user's roles, not the integration user's roles. Even though the REST message authenticates as an integration user with 'snc_internal', the system logs a success for the API call itself, but the ACL evaluation fails silently when the record creation is attempted, resulting in no incident record being created.

Answer

The integration user's session has expired during the request.

Answer

The portal widget is using a different table name in the API call.

Answer

The REST API endpoint is mapped to the wrong table.

Question 9

Your organization has implemented a notification on the 'incident' table to send an email when an incident's priority is changed. The notification is configured with a condition: 'Priority changes to 1 - Critical' and uses the 'Send email' action. Recently, administrators noticed that for a single incident that was updated multiple times, duplicate emails were sent. The incident record's audit history shows that the priority was only changed once. What is the most likely cause?

Accepted Answer

The notification condition has a script that incorrectly evaluates to true multiple times.. The notification condition uses a script that evaluates to true multiple times during a single update, causing the 'Send email' action to fire repeatedly. Even though the audit history shows the priority changed only once, a flawed script can return true for other field changes or on subsequent database operations, leading to duplicate emails. This is a common issue when conditions are not properly scoped to detect only the specific field change.

Answer

The email notification is configured with 'Send when record is updated' and the update triggers multiple business rules that each fire the notification.

Answer

The 'Send email' action is set to 'Send to all users in the role' and multiple users have the same role.

Answer

The notification is also triggered by the 'cmdb_ci' field update.

Question 10

A system administrator is configuring ACLs for a custom table 'u_employee_info' that should be visible to all employees but editable only by HR managers. The administrator creates two ACLs: one read ACL for the 'employee' role with type 'read', and one write ACL for the 'hr_manager' role with type 'write'. However, employees with the 'employee' role report that they cannot see any records in the table. The administrator verifies that the ACLs are active. What is the most likely issue?

Accepted Answer

The read ACL is set to require a role 'snc_employee' instead of 'employee'.. ServiceNow ACLs are role-based, and the read ACL must specify the exact role name as it exists in the system. If the role is named 'snc_employee' but the ACL references 'employee', the ACL will not match, and the system will deny read access by default. The administrator likely misconfigured the role name in the ACL condition.

Answer

The read ACL is set to type 'record' instead of 'table'.

Answer

The table 'u_employee_info' has no 'read' ACL defined by default, so access is denied.

Answer

The write ACL is overriding the read ACL because it has a higher priority.

Question 11

A ServiceNow administrator deployed an Access Control Rule (ACL) to restrict access to the 'u_employee_salary' field on the 'u_employee' table. The ACL is defined as type 'field', with condition 'current.roles.contains("admin")', and 'read' and 'write' operations set to 'requires role'. After activating the ACL, non-admin users with the 'employee' role can still see the 'u_employee_salary' field on forms and lists. The administrator has verified that the 'employee' role does not have any other ACLs granting access to this field. Which of the following is the most likely cause of the issue?

Accepted Answer

The ACL is applied to the wrong table or the field name is misspelled.. The most likely cause is that the ACL is applied to the wrong table or the field name is misspelled. If the ACL's table or field name does not exactly match the target field, the ACL will not enforce on that field, allowing non-admin users to see it. The administrator verified no other ACLs grant access, so a mismatch in the ACL definition is the primary suspect.

Answer

A higher-priority ACL with the same name is overriding this ACL.

Answer

The ACL is missing a script condition that returns false for non-admin users.

Answer

The ACL is of type 'record' instead of 'field'.

Question 12

An organization has a notification configured to send an email to the caller's manager when an incident is resolved. The notification is active, uses the 'Email - Incident' template, and has a condition script: 'current.state.changesTo(6)'. The email properties (SMTP, etc.) are working correctly for other notifications. Recently, managers are not receiving these resolved-incident emails. The administrator checks that the 'Manager' field on the caller's user record is populated for all callers. The notification's 'Who will receive' list is set to 'Caller and caller's manager' and the 'Operation' is 'record updated'. The 'Advanced' view shows that the 'Recipients' tab includes the email field 'mail' for the caller and the manager. What should the administrator investigate next?

Accepted Answer

Check the notification template for the correct email field reference for the manager.. The notification is configured correctly to send to the caller and caller's manager, and the condition script triggers on state change to 6 (Resolved). Since other notifications work, SMTP is fine. The issue likely lies in the notification template: if the template references an incorrect email field for the manager (e.g., 'email' instead of 'mail'), the system cannot resolve the manager's email address, causing the email not to be sent. Option B directly addresses this by checking the template's field reference.

Answer

Add a condition script to verify that the manager exists before sending.

Answer

Change the notification to 'event-based' using a business rule.

Answer

Verify that the 'Manager' field on the user record has a read ACL that allows the system user to access it.

Question 13

Refer to the exhibit. A user without the admin role attempts to update an incident record where the caller's department is 'Finance'. The user's department is 'IT'. What will happen?

Accepted Answer

The update is denied because the condition evaluates to false.. The update is denied because the ACL condition evaluates to false. In ServiceNow, ACLs (Access Control Lists) control record-level access by evaluating conditions against the current user and the target record. If the ACL requires that the user's department matches the caller's department (a common condition for non-admin users), and the user is in 'IT' while the caller is in 'Finance', the condition fails and access is denied. The user lacks the admin role, so no admin override applies.

Answer

The update is allowed because the user has the admin role.

Answer

The update is allowed because the user's department matches the caller's department.

Answer

The update is denied because the ACL is misconfigured.

Question 14

Refer to the exhibit. An incident is created with state 'New' and assigned_to is empty. Later, the state is changed to 'In Progress' and assigned_to is set to 'user1'. The notification does not fire. Which is the most likely reason?

Accepted Answer

The notification's condition includes 'state changes' which is evaluated at the time the trigger runs, not at the time of the update. The trigger may be waiting for a future time, but the condition is re-evaluated then. If the state hasn't changed since the update, it might not fire.. The notification's condition includes 'state changes', which is evaluated at the time the trigger runs, not at the time of the update. In ServiceNow, when a notification is configured with a condition that checks for a field change (e.g., 'state changes'), the condition is evaluated when the scheduled trigger executes, not when the record is updated. If the trigger is scheduled for a later time (e.g., via an asynchronous business rule or scheduled job), the condition may no longer be true because the state has already changed and is no longer 'changing' at that moment, causing the notification to not fire.

Answer

The notification's 'Who will receive' is set to assignment group, but the assignment group is empty.

Answer

The notification condition requires the state field to change, but the state changed from 'New' to 'In Progress', so it should fire. The trigger is scheduled for later, so it will fire at that time.

Answer

The notification is configured to send only on insert, not on update.

Question 15

Refer to the exhibit. A user with username 'john.doe' tries to view an incident record. What is the outcome?

Accepted Answer

The user cannot view the incident because the ACL condition evaluates to false.. The ACL condition on the incident table evaluates to false for user 'john.doe'. In ServiceNow, an ACL (Access Control List) with a condition that returns false prevents the user from viewing the record, even if they have a role like 'itil'. The exhibit likely shows an ACL with a condition such as 'true == false' or a script that returns false, which overrides any role-based access.

Answer

The user can view the incident because no ACLs apply to incident table.

Answer

The user can view the incident because they have the itil role.

Answer

The user cannot view the incident because the ACL is missing a condition for itil role.