CCNA Application Rules, ACL and Notifications Questions

65 questions · Application Rules, ACL and Notifications · All types, answers revealed

1
MCQmedium

A company wants to allow managers to view all incidents, but only their own direct reports' incidents to be editable. Which ACL approach is most efficient?

A.Create a read ACL for managers and a write ACL with a script condition checking manager relationship.
B.Use a business rule to set a field indicating editable and use ACL on that field.
C.Use role-based ACLs and assign a separate role for each manager.
D.Create separate write ACLs for each manager's direct reports.
AnswerA

A script condition dynamically checks the relationship, making it scalable.

Why this answer

Option A is correct because it uses a read ACL to grant all managers view access to all incidents, and a separate write ACL with a script condition that dynamically checks whether the incident's assigned user is a direct report of the current manager. This approach is efficient as it avoids duplicating ACLs per manager or per group, leveraging a single script condition to enforce the manager–direct report relationship at runtime.

Exam trap

The trap here is that candidates often overcomplicate the solution by thinking they need separate ACLs or roles per manager, when a single scripted ACL condition can dynamically evaluate the manager–direct report relationship at runtime, which is both efficient and scalable.

How to eliminate wrong answers

Option B is wrong because using a business rule to set a field indicating editability and then an ACL on that field adds unnecessary complexity and latency; the ACL script condition can directly evaluate the relationship without needing an extra field or business rule. Option C is wrong because creating a separate role for each manager is not scalable and violates role-based access control best practices; roles should represent job functions, not individual users. Option D is wrong because creating separate write ACLs for each manager's direct reports is administratively unsustainable and does not scale as the number of managers or direct reports changes; a single scripted ACL is far more efficient.

2
MCQmedium

A company has a custom table 'u_employee_data' with a before query business rule that sets 'u_department' to 'Engineering' when the current user is in the 'ITIL' role. After the business rule is activated, users in the 'ITIL' role report that when they query the table, they see only records with department 'Engineering'. However, the business rule is intended to set the default department for new records only. What is the most likely cause?

A.The business rule should be set to 'async' to avoid affecting queries.
B.The business rule is set to run on the client side instead of server side.
C.The business rule is running on 'before query' instead of 'before insert'.
D.The condition script uses 'gs.getUser().hasRole("ITIL")' incorrectly.
AnswerC

Before query modifies the query for all retrievals, not just new records.

Why this answer

The business rule is configured to run on the 'before query' operation, which means it executes every time a query is made against the 'u_employee_data' table. This causes the condition to set the 'u_department' field to 'Engineering' for all records returned by the query, effectively filtering the result set to only those with that department. The intended behavior is to set the default department only when a new record is created, which requires the business rule to run on the 'before insert' operation instead.

Exam trap

The trap here is that candidates may confuse 'before query' with 'before insert' because both involve setting field values, but 'before query' affects all retrieved records while 'before insert' only affects new record creation.

How to eliminate wrong answers

Option A is wrong because setting the business rule to 'async' would not change the operation it runs on; asynchronous execution still runs on the same event (before query) and would still affect queries, not solve the issue. Option B is wrong because client-side business rules do not exist in ServiceNow; business rules are always server-side, and the problem is about the event trigger, not the execution location. Option D is wrong because the condition script using 'gs.getUser().hasRole("ITIL")' is correct for checking role membership; the issue is not with the condition but with the business rule running on the wrong event.

3
MCQhard

A notification on the 'incident' table is configured to send an email when the 'state' field changes to 'Resolved'. The condition uses the condition builder with 'State changes to Resolved'. However, the notification also sends when an incident is updated without a state change. What is the most likely cause?

A.The condition builder is incorrectly configured and should use 'State equals Resolved'.
B.The notification has multiple subscribers causing duplicate evaluations.
C.The 'Send when' field is set to 'Record is updated' instead of 'Record is inserted or updated'.
D.A business rule in the background updates the state to 'Resolved' on every update, so the notification fires each time.
AnswerD

Correct: If a BR always sets state to Resolved, the condition evaluates true on every update.

Why this answer

Option C is correct. The condition builder 'State changes to Resolved' fires on any update that meets the condition, but if there is no state change, it might still fire if the condition script is not properly checking the previous value. The most common cause is that the notification is also triggered by a business rule that updates the incident and sets state to Resolved even when state didn't change.

Option A is wrong because the condition builder is fine. Option B is wrong because the 'Send when' setting does not cause that. Option D is wrong because subscribers don't affect condition.

4
MCQhard

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?

A.The email notification is configured with 'Send when record is updated' and the update triggers multiple business rules that each fire the notification.
B.The 'Send email' action is set to 'Send to all users in the role' and multiple users have the same role.
C.The notification is also triggered by the 'cmdb_ci' field update.
D.The notification condition has a script that incorrectly evaluates to true multiple times.
AnswerD

Correct: A buggy script could cause multiple triggers.

Why this answer

Option D is correct because 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.

Exam trap

The trap here is that candidates assume duplicate emails are caused by multiple users or multiple triggers, but the real issue is a poorly written condition script that evaluates to true on every update, not just when the priority field actually changes.

How to eliminate wrong answers

Option A is wrong because 'Send when record is updated' triggers the notification once per update transaction, not multiple times; multiple business rules firing would still result in a single notification per update unless they explicitly call the notification action. Option B is wrong because 'Send to all users in the role' sends one email per user, but the issue is duplicate emails for the same user, not multiple recipients. Option C is wrong because the 'cmdb_ci' field update would not cause the notification to fire unless the condition explicitly checks that field; the condition is set to 'Priority changes to 1 - Critical', so unrelated field updates do not trigger it.

5
MCQhard

A company wants to block all update operations on the 'problem' table for users with only the 'itil' role, except for the user who created the record. Which ACL configuration should be used?

A.Create an ACL with type 'record', operation 'write', role 'itil', condition script 'current.assignment_group == gs.getUser().getMyGroups()', and set 'Requires role' true.
B.Create an ACL with type 'record', operation 'write', role 'itil', condition script empty, and uncheck 'Requires role'.
C.Create an ACL with type 'record', operation 'write', role 'itil', condition script 'current.created_by != gs.getUserID()', and set 'Requires role' true.
D.Create an ACL with type 'record', operation 'write', role 'itil', condition script 'current.created_by == gs.getUserID()', and set 'Requires role' true.
AnswerC

Denies write to itil users if they are not the creator.

Why this answer

Option C is correct because it uses a condition script that denies write access to users with the 'itil' role when the current record's creator is not the logged-in user. The ACL type 'record' with operation 'write' and 'Requires role' checked ensures that only users with the 'itil' role are evaluated, and the condition script 'current.created_by != gs.getUserID()' returns true for users who did not create the record, thus blocking their update operations. This matches the requirement to block all updates except for the record creator.

Exam trap

The trap here is that candidates often confuse the condition logic, selecting Option D because they think 'current.created_by == gs.getUserID()' will allow only the creator, but in a deny ACL, a true condition blocks access, so Option D would block the creator instead of allowing them.

How to eliminate wrong answers

Option A is wrong because it uses a condition script checking 'current.assignment_group == gs.getUser().getMyGroups()', which is irrelevant to the requirement of blocking updates based on record creator; it would incorrectly allow or deny updates based on group membership, not creator identity. Option B is wrong because it leaves the condition script empty and unchecks 'Requires role', which would apply the ACL to all users regardless of role, failing to restrict only users with the 'itil' role and potentially blocking all users from updating the table. Option D is wrong because it uses the condition script 'current.created_by == gs.getUserID()', which returns true for the record creator, thus allowing updates for the creator but also inadvertently allowing updates for any user who matches the creator condition; however, the requirement is to block all updates except for the creator, so the condition should deny when the user is not the creator, not allow when they are.

6
MCQeasy

A company has a business rule that runs on the Incident table during update. The rule checks if the state is 'In Progress' and sets a field. However, after saving, the field is not being set. Which of the following is the most likely cause?

A.The business rule is using 'setValue' instead of 'setDisplayValue'.
B.The business rule is set to run after the record updates but another business rule with a higher order reverts the field.
C.The business rule has the condition 'Current state changes' unchecked.
D.The business rule is set to run on 'display' instead of 'update'.
AnswerB

A higher-order rule can modify the field after this rule sets it.

Why this answer

Option B is correct because if a business rule runs after the record updates (i.e., 'When to run' is set to 'After'), and another business rule with a higher order number runs later and reverts the field, the first rule's change will be overwritten. The order of execution is determined by the 'Order' field; lower numbers run first. Since the field is not being set after save, a higher-order 'After' rule is the most likely culprit, as it can undo the change made by the original rule.

Exam trap

The trap here is that candidates often assume a business rule not working is due to a configuration error like using the wrong method or missing a condition, but the real issue is often the execution order of multiple 'After' business rules where a higher-order rule reverts the change.

How to eliminate wrong answers

Option A is wrong because 'setValue' sets the field's internal value, while 'setDisplayValue' sets the display value for choice fields; using 'setValue' is correct for setting a field value and would not prevent the field from being set. Option C is wrong because the condition 'Current state changes' being unchecked means the rule runs on every update regardless of state change, which would not prevent the field from being set; in fact, it would make the rule run more often. Option D is wrong because a business rule set to run on 'display' would not execute during an update operation at all; it would only run when the record is viewed, so it would never set the field during save, but the question states the rule 'runs on the Incident table during update', implying it is configured to run on update, not display.

7
MCQhard

Refer to the exhibit. An incident is created with state 'New' (1). The user creating the incident has the role 'itil', not 'admin'. After the business rule runs, what is the value of the priority field?

A.The priority remains null because the ACL denies write for non-admin users.
B.The priority is set to 1 because the business rule runs before the ACL check.
C.The priority is set to 1 but the update fails due to ACL.
D.The priority is set to 1 because business rules run with system user privileges.
AnswerD

Business rules execute with system user, so ACLs are not enforced.

Why this answer

The business rule runs before insert and sets priority to 1. However, the ACL for writing to priority requires admin role. The business rule runs with system user privileges, so it bypasses ACLs.

Therefore, the priority is set to 1.

8
Multi-Selectmedium

An ACL on the Task table has a role condition requiring the 'itil' role. A user with the 'itil' role is trying to update a task but is denied. Which TWO factors could be causing this? (Select two.)

Select 2 answers
A.The user also has a role that denies access.
B.The update operation requires a specific condition script that returns false.
C.The record is locked by another user.
D.Another ACL on the same table denies write access.
E.The ACL is set to 'Create' instead of 'Write'.
AnswersB, D

A script condition returning false denies access.

Why this answer

Options A and D are correct. A condition script that returns false would deny access. Another more specific ACL that denies access would take precedence.

Option B is wrong because roles do not deny; they allow. Option C is wrong because the user has the required role. Option E is wrong because record locking is not ACL-related.

9
Multi-Selecthard

A notification is set to send an email when an incident is updated with 'Urgency' = 'High'. The notification is not sending. Which THREE of the following could be the cause? (Select three.)

Select 3 answers
A.The notification has a condition that also checks 'State' which is not met.
B.The user's email address is missing from the user record.
C.The email notification system is configured with SMTP but the mail server is unreachable.
D.The notification is set to 'Active' = false.
E.The incident record is being updated by a web service that does not trigger business rules.
AnswersA, B, D

If the condition includes additional criteria, they must all be met.

Why this answer

Option A is correct because a notification's condition can include multiple fields, such as 'State' in addition to 'Urgency'. If the condition requires 'State' to be a specific value that is not met when the incident is updated, the notification will not trigger. This is a common misconfiguration where the condition logic is more restrictive than intended.

Exam trap

ServiceNow often tests the distinction between a notification not being triggered (condition not met or inactive) versus a notification being triggered but failing to deliver (SMTP issue), and candidates mistakenly select SMTP issues when the question explicitly says 'not sending' meaning not triggered.

10
MCQhard

A notification is configured to send an email when an incident is assigned to a user. However, users are receiving duplicate emails. Which of the following is the most likely cause?

A.The notification is triggered by a business rule that runs on after update.
B.The notification has 'Who will receive' set to both 'Assigned user' and 'User in group'.
C.The notification has two separate conditions that both evaluate to true.
D.The notification is set to 'Send for each record' and the record is being updated multiple times.
AnswerB

If both recipients are the same user (e.g., user is in the group and is the assigned user), they receive two emails.

Why this answer

Option B is correct because when 'Who will receive' is set to both 'Assigned user' and 'User in group', the notification can be sent to the same user twice if that user is both the assigned user and a member of the group. This is a common cause of duplicate emails in ServiceNow notifications, as the system evaluates each recipient list independently and sends separate emails.

Exam trap

ServiceNow often tests the misconception that duplicate emails are caused by multiple conditions or business rules, but the real trap is that selecting multiple recipient types in 'Who will receive' can cause the same user to receive the notification multiple times.

How to eliminate wrong answers

Option A is wrong because a business rule running on 'after update' does not inherently cause duplicate emails; it is the trigger for the notification, and duplicates would only occur if the notification itself has multiple recipients or multiple triggers. Option C is wrong because having two separate conditions that both evaluate to true would cause the notification to fire twice only if the notification is configured to send for each condition separately, but by default, a single notification with multiple conditions still sends one email per record update. Option D is wrong because 'Send for each record' is used for batch updates or multiple records, not for a single record being updated multiple times; duplicate emails from multiple updates would require the notification to be triggered on each update, not the 'Send for each record' setting.

11
MCQmedium

Refer to the exhibit. This ACL is applied to the Incident table for 'write' operation. A user is editing their own incident but is still denied. What is the issue?

A.The script returns false because current.caller_id is not the user's sys_id.
B.The ACL is set to 'read' instead of 'write'.
C.The user does not have the necessary role.
D.The script returns true but another ACL denies.
AnswerD

A more specific ACL can override this one.

Why this answer

Option D is correct because when an ACL is applied to a table for 'write' operations, multiple ACLs can evaluate the same operation. Even if one ACL (the one shown) returns true, another ACL on the same table for the same operation may return false, causing the overall write to be denied. The exhibit shows a script that checks `current.caller_id == gs.getUserID()`, which should allow the user to edit their own incident, but another ACL with a higher order or a different condition is blocking the write.

Exam trap

The trap here is that candidates assume a single ACL's result determines access, but ServiceNow evaluates all matching ACLs in order, and a 'false' from any ACL (unless overridden) will deny the operation, even if another ACL returns 'true'.

How to eliminate wrong answers

Option A is wrong because the script explicitly compares `current.caller_id` to `gs.getUserID()`, which returns the current user's sys_id; if the user is editing their own incident, this condition returns true, not false. Option B is wrong because the ACL is explicitly applied to the Incident table for 'write' operation, as stated in the question, and the exhibit shows the ACL type is 'record' with operation 'write', so it is not set to 'read'. Option C is wrong because the ACL does not require a role; it uses a script condition, and the question does not indicate that a role is missing or that the user lacks any required role.

12
MCQeasy

A user is able to view records in the Incident table but cannot edit them. Which ACL type is preventing the edit?

A.write
B.read
C.create
D.delete
AnswerA

Write ACL controls the ability to update records.

Why this answer

The correct answer is A (write). In ServiceNow, the write ACL controls the ability to update or edit existing records. Since the user can view records (read ACL allows this) but cannot edit them, the write ACL is the one blocking the operation.

The write ACL is evaluated when a user attempts to modify a record after it has been created.

Exam trap

The trap here is that candidates often confuse the write ACL with the read ACL, thinking that if they can see the record, they should be able to edit it, but ServiceNow separates these permissions distinctly.

How to eliminate wrong answers

Option B (read) is wrong because the read ACL controls the ability to view records, and the user can already view them, so the read ACL is not preventing the edit. Option C (create) is wrong because the create ACL controls the ability to insert new records, not edit existing ones. Option D (delete) is wrong because the delete ACL controls the ability to remove records, not modify them.

13
MCQeasy

Refer to the exhibit. This condition script is used in a notification. For which states will the notification trigger?

A.Only state 3
B.Both state 2 and state 3
C.Only state 2
D.Neither state 2 nor state 3
AnswerB

The logical OR returns true for either condition.

Why this answer

The condition script uses `current.state.changesTo(3)` which returns true only when the state transitions to 3 from a different state. Since the script also includes `current.state == 2`, the notification triggers for state 2 as well. Therefore, both state 2 and state 3 will cause the notification to fire.

Exam trap

The trap here is that candidates often confuse `changesTo()` with a static state check, assuming it behaves like `current.state == 3`, and thus incorrectly think the notification only triggers for state 2 or only for state 3.

How to eliminate wrong answers

Option A is wrong because it ignores the `current.state == 2` condition, which independently triggers the notification for state 2. Option C is wrong because it overlooks the `current.state.changesTo(3)` condition, which triggers the notification when the state changes to 3. Option D is wrong because both conditions are met for state 2 (direct equality) and state 3 (on change to 3), so the notification will trigger for both states.

14
Multi-Selecthard

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

Select 3 answers
A.An ACL with type 'deny' will override all other ACLs.
B.ACLs are evaluated in alphabetical order by name.
C.An ACL's 'Requires role' field can have multiple roles separated by commas.
D.Multiple ACLs that grant access are ORed together.
E.If no ACL exists for an operation, access is denied by default.
AnswersC, D, E

Correct: User needs any one of the roles.

Why this answer

Options B, D, and E are correct. B: ACLs are ORed, meaning if one grants access, access is granted. D: If no ACL exists, access is denied.

E: 'Requires role' on ACL can specify multiple roles, and the user needs any one. Option A is wrong because ACLs are processed in order of type (table, record, etc.), not alphabetically. Option C is wrong because 'Deny' ACLs do not exist; all ACLs grant, but conditions can restrict.

15
Multi-Selecthard

Which THREE of the following are true regarding Business Rules?

Select 3 answers
A.They are executed on the client side to improve performance
B.They automatically fire on every record in the database when created
C.They can be used to perform data validation before a record is saved
D.They can be configured to run asynchronously to avoid impacting user response time
E.They can be set to fire on insert, update, delete, or query
AnswersC, D, E

Before business rules can validate data and abort the save if needed.

Why this answer

Option C is correct because Business Rules in ServiceNow are server-side scripts that execute before or after a database operation, and they are commonly used to validate data before the record is saved. By using the 'Before' order, a business rule can check field values and abort the save if validation fails, ensuring data integrity.

Exam trap

ServiceNow often tests the misconception that Business Rules are client-side, but the trap here is that candidates confuse Business Rules with Client Scripts, which actually run on the client side.

16
MCQmedium

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?

A.Condition: 'Record is inserted'; Recipient: Manager of the assignment group.
B.Condition: 'Assigned to changes to Caller's manager'; Recipient: Caller.
C.Condition: 'State changes'; Recipient: Caller via email client.
D.Condition: 'Assignment group changes to <group>'; Recipient: Caller's manager.
AnswerD

Correct: Fires when group changes and sends to manager.

Why this answer

Option D is correct because the requirement is to notify the caller's manager when an incident is assigned to a specific group. The condition 'Assignment group changes to <group>' 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.

Exam trap

The trap here is that candidates often confuse 'Caller's manager' with 'Manager of the assignment group' or think a generic condition like 'State changes' will suffice, missing the precise condition and recipient required by the scenario.

How to eliminate wrong answers

Option A is wrong because 'Record is inserted' triggers on creation of a new incident, not on assignment to a specific group, and 'Manager of the assignment group' sends the email to the group's manager, not the caller's manager. Option B is wrong because 'Assigned to changes to Caller's manager' is a condition that triggers when the assigned user changes to the caller's manager, which is unrelated to the assignment group change, and the recipient is 'Caller' instead of the caller's manager. Option C is wrong because 'State changes' triggers on any state change (e.g., from New to In Progress), not specifically when the assignment group changes, and 'Caller via email client' sends to the caller, not their manager.

17
Multi-Selecteasy

Which TWO of the following are valid ways to control the visibility of a field on a form for specific users?

Select 2 answers
A.Create a UI Policy that sets the field's 'visible' attribute to false based on user role
B.Create a Data Policy with a read condition
C.Create an ACL with type 'field' and operation 'read' set to 'no access' for unwanted roles
D.Create a Client Script that sets g_form.setVisible() on load
E.Create a Business Rule that hides the field
AnswersA, C

UI Policies run client-side and can modify field visibility.

Why this answer

Option A is correct because a UI Policy runs on the client side and can set the 'visible' attribute of a field to false based on conditions such as user role. This directly controls the field's visibility on the form for specific users without affecting server-side access.

Exam trap

The trap here is that candidates often confuse Data Policies (which control mandatory/read-only behavior) with UI Policies (which control visibility), or assume that server-side Business Rules can directly manipulate client-side form visibility without a client-side trigger.

18
MCQeasy

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?

A.Group members (on the record)
B.Caller
C.Assignment group members
D.Assigned user
AnswerC

Correct: Sends to all members of the assignment group.

Why this answer

Option C is correct because 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.

Exam trap

The trap here is that candidates confuse 'Group members (on the record)' with 'Assignment group members', not realizing that ServiceNow treats these as separate fields with different notification behaviors, and the question specifically requires notification based on the 'Assignment group' field.

How to eliminate wrong answers

Option A is wrong because 'Group members (on the record)' refers to members of the group that is selected in the 'Group' field (if present), not the 'Assignment group' field; this is a different field and would not trigger based on assignment changes. Option B is wrong because 'Caller' is the user who reported the incident, not the group members who should be notified upon assignment. Option D is wrong because 'Assigned user' sends the notification only to the individual user assigned to the incident, not to the entire group; this would miss notifying other group members.

19
MCQhard

A system administrator notices that users in the 'itil' role can see the 'cost' field on the 'cmdb_ci_server' table, but the requirement is to hide it from all except users with the 'cmdb_admin' role. The administrator has already created an ACL with 'read' operation, type 'record', condition 'current.cost' (no script) and granted 'no access' to all roles. However, the field is still visible. What is missing?

A.The ACL condition should use a script instead of a condition
B.The ACL must be set to 'mandatory'
C.The user must be removed from the 'itil' role
D.The ACL type must be 'field' instead of 'record'
AnswerD

Field ACLs control read/write access to individual fields.

Why this answer

Option D is correct because a 'record' ACL controls access to the entire record, but the requirement is to hide a specific field ('cost') from certain roles. To control visibility at the field level, the ACL type must be 'field', not 'record'. A 'record' ACL determines whether a user can see or interact with the whole record, while a 'field' ACL governs access to individual fields.

Since the 'cost' field is still visible, the existing 'record' ACL is not applied to the field itself, allowing the 'itil' role to see it via default field-level access.

Exam trap

The trap here is that candidates often confuse 'record' ACLs with 'field' ACLs, assuming a record ACL with a condition on a field will hide that field, when in reality only a field ACL can control individual field visibility.

How to eliminate wrong answers

Option A is wrong because the condition 'current.cost' is a valid condition that checks if the field has a value; using a script is not required to hide a field, and the issue is the ACL type, not the condition format. Option B is wrong because 'mandatory' is a property for UI policies, not ACLs; ACLs do not have a 'mandatory' setting, and making an ACL mandatory would not change the type from record to field. Option C is wrong because removing the user from the 'itil' role would hide the field but does not address the root cause—the ACL is misconfigured as a record ACL instead of a field ACL, and the requirement is to hide the field from all except 'cmdb_admin', not to remove users from roles.

20
MCQhard

A company has an advanced business rule running on the 'incident' table with condition 'current.state == 2' (In Progress). The business rule creates a new child incident and also updates a field on the parent. However, when a state changes from 1 to 2 via a sys_created_by script, the child incident is created but the parent field is not updated. What is the most likely reason?

A.The business rule condition is not met
B.The child incident creation also fails
C.The business rule runs 'after' instead of 'before'
D.The business rule runs 'before' and there is an uncaught script error that aborts the update
AnswerD

If an error occurs in a 'before' rule, the entire transaction may roll back for the parent, but the child creation might have been committed if called in a separate transaction.

Why this answer

Option D is correct because if the business rule runs 'before', the update to the parent happens before the database operation, and if there is an error in the script (perhaps due to a glideRecord operation that fails silently), the update may not persist. Option A is less likely because the condition matches. Option B would affect child creation too.

Option C would affect all updates, not just the field update.

21
MCQhard

An administrator creates a new ACL for the 'incident' table with type 'record', operation 'read', condition script 'current.assignment_group == gs.getUser().getMyGroups()', and requires role 'snc_internal'. A user with role 'snc_internal' who is a member of group 'Service Desk' can view incidents assigned to 'Service Desk' but cannot view incidents assigned to 'Network Support'. What is the most likely reason?

A.The condition script uses 'current.assignment_group' which returns a sys_id, but 'gs.getUser().getMyGroups()' returns a list of group names.
B.The condition script should use 'current.assignment_group.isOneOf(gs.getUser().getMyGroups())' instead.
C.The user does not have the 'snc_internal' role.
D.Another ACL with higher order denies read access to all incidents not matching the condition.
AnswerD

ACL order matters; a deny rule could be overriding.

Why this answer

Option D is correct because ACLs in ServiceNow are evaluated in order of their 'order' field, and the first matching ACL (either allowing or denying access) determines the outcome. If another ACL with a higher order (lower numeric value) denies read access to incidents not matching the condition, that deny rule will take precedence over the new ACL, preventing the user from viewing incidents assigned to 'Network Support' even though the new ACL would allow it. The user's role and group membership are satisfied, so the issue lies in ACL ordering and a conflicting deny rule.

Exam trap

The trap here is that candidates focus on the syntax error in the condition script (options A and B) and overlook the ACL evaluation order, which is a more fundamental concept in ServiceNow that explains why the user can see some incidents but not others despite the flawed condition.

How to eliminate wrong answers

Option A is wrong because 'current.assignment_group' returns a sys_id (a reference to the sys_user_group table), and 'gs.getUser().getMyGroups()' returns a list of group sys_ids, not group names, so the comparison is technically valid but fails because it compares a single sys_id to a list of sys_ids (the condition script should use an array method like indexOf or isOneOf). Option B is wrong because while 'isOneOf' is a valid method for comparing a field to a list, the condition script as written would still fail due to the type mismatch (single value vs list), and the question asks for the 'most likely reason' given the described behavior—option D better explains why the user cannot see 'Network Support' incidents despite having the correct role and group membership. Option C is wrong because the user has the 'snc_internal' role, as stated in the question, so this is not the issue.

22
MCQhard

A system administrator needs to allow users with the 'incident_manager' role to delete incidents only if the incident state is 'New' or 'Work in Progress'. They create an ACL with the following conditions: type='record', operation='delete', name='incident', condition: gs.hasRole('incident_manager') && current.state == 1 || current.state == 2. After testing, users with the role can delete incidents in any state. What is the most likely cause?

A.The ACL is set on the 'incident' table but should be on the 'task' table.
B.The condition lacks parentheses to group the state checks.
C.The ACL should be created using the condition builder instead of script.
D.The condition does not check for the 'incident_manager' role.
AnswerB

Without parentheses, the OR binds weaker than AND, allowing state 2 to bypass role check.

Why this answer

The condition `gs.hasRole('incident_manager') && current.state == 1 || current.state == 2` is evaluated by JavaScript operator precedence, where `&&` binds tighter than `||`. This means it is parsed as `(gs.hasRole('incident_manager') && current.state == 1) || current.state == 2`. Consequently, any user (even without the role) can delete incidents in state 2 (Work in Progress), and users with the role can delete incidents in any state because the role check only applies to state 1.

Adding parentheses—`gs.hasRole('incident_manager') && (current.state == 1 || current.state == 2)`—fixes the logic.

Exam trap

ServiceNow often tests operator precedence in ACL conditions, tricking candidates into overlooking that `&&` binds tighter than `||`, which causes the role check to apply only to the first state condition.

How to eliminate wrong answers

Option A is wrong because the ACL is correctly set on the 'incident' table; the 'task' table is a parent table and would not apply to incident-specific state values. Option C is wrong because the condition builder is a UI wrapper that generates the same script; the issue is operator precedence, not the method of creation. Option D is wrong because the condition does check for the 'incident_manager' role via `gs.hasRole('incident_manager')`, but the lack of parentheses causes the role check to be bypassed for state 2.

23
MCQhard

A business rule set to run 'async' is supposed to update a large number of child records. The administrator notices that the updates are not being applied consistently. What is the most likely reason?

A.The business rule condition is incorrect
B.The system property 'glide.sys.schedulers.max_threads' is set too low
C.The async queue processes multiple instances simultaneously, causing race conditions
D.The business rule is running 'before' instead of 'after'
AnswerC

Async rules are queued and may run in parallel, leading to race conditions.

Why this answer

When a business rule is set to run 'async', it executes asynchronously via the system's queue. If the business rule updates a large number of child records, multiple instances of the same async business rule can be processed simultaneously by different queue workers. This concurrency can lead to race conditions, where one instance reads stale data or overwrites changes made by another instance, resulting in inconsistent updates.

Exam trap

The trap here is that candidates often confuse 'async' execution with simple timing or thread limits, overlooking the fundamental concurrency issue of race conditions in asynchronous processing.

How to eliminate wrong answers

Option A is wrong because an incorrect condition would cause the business rule to either not run at all or run on the wrong records, not to apply updates inconsistently across a large set of child records. Option B is wrong because the system property 'glide.sys.schedulers.max_threads' controls the maximum number of scheduler threads, not the async queue processing; the async queue uses a separate worker mechanism. Option D is wrong because the 'before' vs 'after' timing affects when the rule runs relative to the database operation, but does not cause inconsistency in updates when the rule is set to run asynchronously.

24
MCQeasy

An administrator creates a notification for the 'incident' table to send an email when the state changes to 'resolved'. The notification works for most users, but some users report not receiving the email. What is the most likely cause?

A.The notification weight is set too high.
B.The notification is not set to 'Active'.
C.The notification does not have an email template selected.
D.The users have set their 'Notification' preference to 'Do not send' for that type.
AnswerD

Individual user preferences can suppress emails.

Why this answer

The most likely cause is that the users have configured their personal Notification preference to 'Do not send' for that notification type. In ServiceNow, users can override system-level notification settings by setting their preference to suppress specific notification types, which would prevent the email from being sent even though the notification is active and properly configured.

Exam trap

The trap here is that candidates often assume the issue is a global configuration error (like inactive notification or missing template) rather than recognizing that user-level preferences can selectively block notifications for some users while others receive them.

How to eliminate wrong answers

Option A is wrong because notification weight controls the order in which notifications are processed, not whether they are sent; a high weight would not prevent delivery. Option B is wrong because if the notification were not active, no users would receive the email, contradicting the scenario where most users do receive it. Option C is wrong because if no email template were selected, the notification would fail for all users, not just a subset; the system requires a template to generate the email body.

25
MCQeasy

A user reports that they are unable to see any records in the 'incident' table, even though they have the itil role. The administrator checks the ACLs and finds that there are no read ACLs defined for the incident table. What will happen?

A.The system will create a default read ACL that grants access to the itil role.
B.All users can read all incident records.
C.No users can read any incident records.
D.Only users with the admin role can read incident records.
AnswerC

Correct: No read ACL denies all read access.

Why this answer

In ServiceNow, if no read ACLs are defined for a table, the system defaults to a 'deny all' behavior. This means that no users, including those with the itil role, can read any records in the incident table. The itil role grants access to incident records only when a read ACL explicitly allows it; without any read ACL, the implicit denial takes effect.

Exam trap

The trap here is that candidates often assume the itil role provides blanket read access to the incident table, but ServiceNow requires explicit read ACLs to grant that access; without them, the implicit deny blocks all users, including itil role holders.

How to eliminate wrong answers

Option A is wrong because ServiceNow does not automatically create a default read ACL that grants access to the itil role; instead, the absence of any read ACL results in an implicit deny for all users. Option B is wrong because without any read ACLs, the system does not allow all users to read records; it denies access to everyone. Option D is wrong because even users with the admin role are subject to the same implicit deny when no read ACLs exist; however, admin users can bypass ACLs via the 'admin' role's inherent 'security_admin' privilege, but the question's scenario implies standard ACL behavior without admin bypass being the default for all users.

26
MCQeasy

Which table field in a notification record defines the email subject?

A.Short description
B.Subject
C.Title
D.Name
AnswerB

This field holds the email subject line.

Why this answer

Option A is correct because the 'Subject' field in the notification record sets the email subject. Option B is wrong because 'Short description' is for records. Option C is wrong because 'Name' is the notification name.

Option D is wrong because 'Title' is not used for subject.

27
Multi-Selecteasy

A notification should be sent to the change manager when a change request is submitted. Which TWO fields must be configured? (Choose TWO.)

Select 2 answers
A.Set the notification to active.
B.Set a weight value.
C.Set the condition 'State changes to new' in 'When to send' tab.
D.Add 'Change manager' role to 'Recipients' in 'Who will receive' tab.
E.Select an email template.
AnswersC, D

Defines the trigger.

Why this answer

Option C is correct because the 'When to send' tab defines the trigger condition for the notification. Setting the condition to 'State changes to new' ensures the notification is sent exactly when a change request is submitted (i.e., when its state transitions to 'new'). Option D is correct because the 'Who will receive' tab specifies the recipients; adding the 'Change manager' role ensures that all users with that role receive the notification.

Exam trap

ServiceNow often tests the distinction between mandatory configuration fields and optional enhancements; the trap here is that candidates mistakenly select 'active' or 'email template' as required, when only the trigger condition and recipient definition are essential for the notification to function as intended.

28
MCQhard

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?

A.The ACL is defined on a different table that extends 'incident'.
B.The script uses gs.hasRole('service_desk') which checks role, not group membership.
C.The condition script does not have a default return false statement, so it returns undefined.
D.Another read ACL exists that explicitly denies read access to the 'service_desk' group.
AnswerC

Correct: A missing explicit false return causes undefined, which is falsy.

Why this answer

Option C is correct because 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.

Exam trap

The trap here is that candidates assume a condition script without a return statement will default to true or false, but ServiceNow treats undefined as false, causing the ACL to deny access unexpectedly.

How to eliminate wrong answers

Option A is wrong because if the ACL were defined on a different table that extends 'incident', it would still apply to the record via inheritance, so it would not prevent the user from seeing the record. Option B is wrong because gs.hasRole('service_desk') checks for the role, not group membership, but the question states the user is in the 'service_desk' group, and if the script used gs.hasRole, it would still return true if the user has the corresponding role, which is typically granted by group membership. Option D is wrong because another read ACL that explicitly denies read access would override the grant only if it has a higher priority (e.g., a deny ACL with a condition that matches), but the question says the user cannot see the record, and a deny ACL would be a plausible cause only if it existed and matched; however, the most likely cause given the condition script behavior is the missing return statement.

29
MCQmedium

An ACL on the Incident table has a script condition that returns true if the user is in the role 'incident_manager'. A user with the 'incident_manager' role still cannot update incidents. What could be the issue?

A.The ACL is set to 'read' instead of 'write'.
B.The user also has a role that explicitly denies access.
C.The script has a syntax error but is still returning false.
D.The ACL has a condition order that is not correct.
AnswerC

A syntax error in the script may cause it to return false, denying access.

Why this answer

Option C is correct because if the script condition has a syntax error, it will not execute properly and will return false by default, even if the user has the 'incident_manager' role. In ServiceNow, ACL script conditions that fail due to syntax errors are treated as false, denying access. The user's role is irrelevant if the condition itself does not evaluate to true.

Exam trap

The trap here is that candidates assume a valid role assignment guarantees access, overlooking that ACL script conditions must execute without errors and return true for the ACL to grant access.

How to eliminate wrong answers

Option A is wrong because the question states the user cannot update incidents, implying the ACL is intended for update operations; if it were set to 'read', the user would still be able to update if a separate write ACL existed, but the issue is specifically about update access. Option B is wrong because while explicit deny roles can override, the question does not mention any such role, and the scenario focuses on the script condition not working. Option D is wrong because condition order only matters when multiple ACLs match; a single ACL with a script condition that returns false will deny access regardless of order.

30
MCQmedium

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?

A.Add a condition script to verify that the manager exists before sending.
B.Check the notification template for the correct email field reference for the manager.
C.Change the notification to 'event-based' using a business rule.
D.Verify that the 'Manager' field on the user record has a read ACL that allows the system user to access it.
AnswerB

The template must correctly reference the manager's email, e.g., ${user.manager.email}. If it uses an incorrect field or literal text, the email will not be sent to the manager.

Why this answer

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.

Exam trap

The trap here is that candidates assume the issue is with the notification condition or ACLs, overlooking that the template's field reference for the manager's email could be incorrect even when the 'Who will receive' list is set correctly.

How to eliminate wrong answers

Option A is wrong because the notification already has a condition script ('current.state.changesTo(6)') and the 'Who will receive' list includes the manager; adding a script to verify manager existence is redundant and would not fix a template field reference issue. Option C is wrong because changing to event-based notification would not resolve the problem; the current 'record updated' operation is appropriate and the issue is with template field mapping, not the notification trigger mechanism. Option D is wrong because the 'Manager' field is populated and other notifications work, indicating ACLs are not blocking access; the system user typically has full read access, and a read ACL issue would affect all notifications, not just this one.

31
Multi-Selecteasy

An administrator wants to send an email notification when a change request state changes to 'scheduled'. The notification should be sent to the change manager. Which two fields must be configured in the notification record?

Select 2 answers
A."Advanced" tab: register an event to trigger the notification
B."Email template" tab: select an existing template
C."Who will receive" tab: add 'Change manager' role to 'Recipients'
D."When to send" tab: set condition to 'State changes to scheduled'
AnswersC, D

This ensures the notification is sent to the change manager.

Why this answer

Option C is correct because the 'Who will receive' tab allows you to specify the recipients of the notification by role, user, or group. Adding the 'Change manager' role ensures that all users with that role receive the email when the notification triggers. Option D is correct because the 'When to send' tab defines the condition that must be met for the notification to fire; setting it to 'State changes to scheduled' ensures the notification is sent precisely when the change request state transitions to 'scheduled'.

Exam trap

The trap here is that candidates often think an email template is mandatory for a notification to work, but ServiceNow will use a default template if none is selected, making option B incorrect as a required field.

32
MCQhard

Refer to the exhibit. The business rule is set to run 'before' update. When a user changes the state to 'Resolved' (value 3), the comments field is updated. However, the change does not appear on the form after save. What is the most likely reason?

A.The state condition is incorrect because state 3 is not 'Resolved'.
B.The script uses current.update() causing recursion and rollback.
C.The script should use current.setValue() instead of assignment.
D.The business rule should be 'after' instead of 'before'.
AnswerB

update() inside before rule triggers the rule again, causing recursion.

Why this answer

Option B is correct because calling current.update() inside a 'before' business rule triggers the same business rule again, causing recursion. ServiceNow detects this recursion and rolls back the update to prevent an infinite loop, so the comment field change is not saved. A 'before' business rule should modify fields directly without calling update(), as the system handles the save automatically.

Exam trap

ServiceNow often tests the misconception that calling current.update() is necessary to save changes in a 'before' business rule, when in fact it causes recursion and rollback, and direct field assignment is sufficient.

How to eliminate wrong answers

Option A is wrong because state 3 is indeed the 'Resolved' state in the default Incident table, so the condition is correct. Option C is wrong because using assignment (e.g., current.comments = 'text') is valid in a 'before' business rule; setValue() is also acceptable but not required. Option D is wrong because an 'after' business rule would still need to call current.update() to persist changes, and the recursion issue would persist; the core problem is the update() call, not the timing.

33
MCQeasy

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?

A.A higher-priority ACL with the same name is overriding this ACL.
B.The ACL is applied to the wrong table or the field name is misspelled.
C.The ACL is missing a script condition that returns false for non-admin users.
D.The ACL is of type 'record' instead of 'field'.
AnswerB

If the ACL does not match the exact table or field name, it will not be enforced, allowing default access.

Why this answer

Option B is correct because 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.

Exam trap

The trap here is that candidates often assume the ACL logic (condition or role requirement) is flawed, when in reality the ACL is simply not being applied due to a table/field name mismatch, which is a common oversight in ACL troubleshooting.

How to eliminate wrong answers

Option A is wrong because ACLs do not have a priority system based on name; they are evaluated by order of specificity (e.g., field-level overrides record-level) and by the 'order' property, not by name. Option C is wrong because the ACL already has a condition 'current.roles.contains("admin")' which is a script condition that returns false for non-admin users; adding another script condition is unnecessary and would not fix a table/field mismatch. Option D is wrong because the ACL is already of type 'field' as stated, and changing it to 'record' would affect the entire record, not just the field, which would not resolve the issue of the field being visible.

34
Matchingmedium

Match each ServiceNow module to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Restore normal service operation as quickly as possible

Control the lifecycle of all changes to the IT environment

Identify and manage root causes of incidents

Provide a menu of services for users to request

Capture and share knowledge articles

Why these pairings

These are core ITSM modules in ServiceNow.

35
MCQeasy

A system administrator needs to prevent users from deleting any records in the 'incident' table. Which method will achieve this most effectively?

A.Create a write ACL on the incident table with condition 'false'
B.Create a read ACL on the incident table with condition 'false'
C.Set the incident table 'Update' access to 'none' in the table configuration
D.Create an application ACL on the incident table with the 'delete' operation set to 'no access'
AnswerD

Application ACLs can control delete operation and 'no access' denies it.

Why this answer

Option C is correct because an 'application' record ACL with the 'delete' operation set to 'no access' explicitly denies delete permissions for all users. Options A and B only affect display or creation. Option D affects updating, not deleting.

36
Multi-Selectmedium

A business rule is configured to run on 'after' update. Which TWO of the following conditions would cause the rule to execute? (Select two.)

Select 2 answers
A.The condition script returns false.
B.The condition checkbox is unchecked (no condition).
C.The condition checkbox is checked but script returns false.
D.The condition script returns true.
E.The table is not the specified table.
AnswersB, D

Unchecked condition means rule runs unconditionally.

Why this answer

Option B is correct because when the condition checkbox is unchecked, the business rule has no condition script, so it always executes on the specified event (after update). Option D is correct because a condition script that returns true explicitly tells the rule to run. The 'after' update timing means the rule runs after the database write, but the condition still controls whether execution occurs.

Exam trap

The trap here is that candidates often think an unchecked condition checkbox means the rule never runs, but it actually means the rule always runs because there is no condition to evaluate.

37
MCQhard

You are a ServiceNow administrator for a large enterprise. The company has a custom application that uses a table 'u_asset_tracking' to track IT assets. The table has a before insert business rule that sets the 'u_assigned_to' field to the current user if the field is empty. Recently, the security team reported that some users are able to view asset records that they should not see. After investigation, you find that the 'u_asset_tracking' table has no ACLs defined, and the default table ACL allows read access to all authenticated users. The business rule is working correctly. You need to restrict read access so that users can only see records where 'u_assigned_to' is themselves or where they are in the same 'u_department' as the record's 'u_department'. You must ensure that the solution does not affect other tables. Which approach should you take?

A.Modify the default table ACL for the 'u_asset_tracking' table to require the 'asset_user' role.
B.Create a new ACL for the 'u_asset_tracking' table with type 'record', operation 'read', condition script 'current.u_assigned_to == gs.getUserID() || current.u_department == gs.getUser().getDepartment()', and set order to 0. Ensure 'Requires role' is unchecked.
C.Add a business rule to restrict read access by deleting records from the glide record set.
D.Create a new ACL for the 'u_asset_tracking' table with type 'record', operation 'read', condition script 'current.u_assigned_to == gs.getUserID()', and require the 'asset_user' role.
AnswerB

This ACL grants read access only to matching records and, with order 0, takes precedence over the default ACL.

Why this answer

Option B is correct because it creates a record-level ACL with a condition script that enforces row-level security: users can only read records where they are the assigned user or share the same department. The order of 0 ensures this ACL is evaluated before the default table ACL, and leaving 'Requires role' unchecked allows the condition to grant access without requiring a specific role, thus restricting read access based solely on the condition.

Exam trap

The trap here is that candidates often think modifying the default table ACL or adding a role requirement is sufficient, but they miss that record-level ACLs with condition scripts are the correct way to implement row-level security without affecting other tables.

How to eliminate wrong answers

Option A is wrong because modifying the default table ACL to require a role would apply to all tables, not just 'u_asset_tracking', and would not enforce the row-level condition (assigned to or same department). Option C is wrong because a business rule cannot restrict read access; business rules run on server-side operations like insert, update, delete, or query, but they cannot prevent a user from viewing records in a list or form (ACLs control read access). Option D is wrong because it only checks if the user is the assigned user, ignoring the department condition, and requiring the 'asset_user' role would block users without that role even if they meet the condition, which is not the requirement.

38
Drag & Dropmedium

Drag and drop the steps to configure an inbound email action in ServiceNow into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Inbound actions process incoming emails to create or update records.

39
MCQmedium

An administrator wants to enforce that when the 'state' field of an incident is set to 'Resolved', the 'resolution_notes' field must be filled. Which approach should be used?

A.Create a UI Policy that sets the 'resolution_notes' field to mandatory when state is 'Resolved'
B.Create a data policy with a condition on the state field
C.Create a data lookup condition on the incident table
D.Create a business rule that checks the condition and shows an error message
AnswerA

UI Policies are client-side and can make fields mandatory based on conditions.

Why this answer

Option C is correct because a UI Policy can set mandatory on the field based on a condition without requiring server-side coding. Option A requires coding, option B is server-side but less user-friendly, option D doesn't enforce mandatory.

40
Multi-Selectmedium

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

Select 2 answers
A.Email address
B.Users in a role
C.Dynamic recipient
D.Group
E.Email address from a field
AnswersB, E

Correct: Sends to all users with the specified role.

Why this answer

Option B is correct because ServiceNow allows notifications to be sent to all users who have a specific role assigned. When 'Users in a role' is selected as the recipient type, the system evaluates the role membership at runtime and sends the notification to every active user with that role, making it a valid and commonly used recipient definition.

Exam trap

The trap here is that candidates often confuse the 'Email address from a field' option (which is valid) with a static 'Email address' field (which is not a recipient type), and they may also mistake 'Dynamic recipient' for a real option when ServiceNow uses 'Dynamic user' or 'Dynamic group' instead.

41
MCQmedium

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

A.The user can view the incident because no ACLs apply to incident table.
B.The user can view the incident because they have the itil role.
C.The user cannot view the incident because the ACL is missing a condition for itil role.
D.The user cannot view the incident because the ACL condition evaluates to false.
AnswerD

Both conditions are false, so read is denied.

Why this answer

The ACL requires snc_internal role or username 'admin'. John has neither, so read is denied.

42
MCQhard

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?

A.The update is denied because the condition evaluates to false.
B.The update is allowed because the user has the admin role.
C.The update is allowed because the user's department matches the caller's department.
D.The update is denied because the ACL is misconfigured.
AnswerA

Both parts of the OR condition are false, so ACL denies.

Why this answer

The condition checks if user has admin role (false) or user's department equals caller's department (IT != Finance). Both false, so ACL denies write.

43
MCQhard

A junior administrator configures the above business rule and ACL. When a user without any role opens an incident with category 'database' and state 1, the priority is set to 1 correctly. However, the user cannot view the incident record. What is the most likely reason?

A.The ACL condition uses sys_id of assignment group, but the field stores display value.
B.The business rule runs before insert, but the ACL check occurs after insert.
C.The ACL requires a role (empty role list means no role requirement? Actually requires role checked, but no roles listed means any authenticated user, but unauthenticated? The user has no role, and condition fails because assignment group mismatch.
D.The business rule order (100) is too low and another rule overrides the priority.
AnswerC

The ACL requires a role and condition fails, so access is denied.

Why this answer

Option C is correct because the ACL condition checks if the assignment group's sys_id matches a value, but the user has no role and the assignment group field likely stores the display value (group name) rather than the sys_id. This mismatch causes the ACL to deny read access, even though the business rule sets the priority correctly. The empty role list in the ACL means no roles are required, but the condition still fails due to the sys_id vs. display value mismatch.

Exam trap

The trap here is that candidates assume the ACL's empty role list means no access control, but the condition itself can still deny access due to a field value mismatch, leading them to overlook the sys_id vs. display value issue.

How to eliminate wrong answers

Option A is wrong because the ACL condition uses sys_id of assignment group, but the field stores display value—this is actually the core issue described in option C, not a separate reason; the mismatch causes the ACL to fail, not the business rule. Option B is wrong because the business rule runs 'before insert' and the ACL check occurs after insert, but this timing difference does not affect the priority setting; the priority is set correctly, and the ACL check is independent of the business rule's execution order. Option D is wrong because the business rule order (100) is not too low; a lower order number means it runs earlier, and there is no evidence that another rule overrides the priority, as the priority is set correctly.

44
MCQeasy

What is the default behavior of an ACL if no ACL record exists for a given operation?

A.Log the attempt and allow.
B.Prompt the user for confirmation.
C.Deny access.
D.Allow access.
AnswerC

ServiceNow denies access if no ACL record exists.

Why this answer

Option B is correct because ServiceNow denies access by default. Option A is wrong because default is deny, not allow. Option C is wrong because no prompt is shown.

Option D is wrong because it does not log; it denies silently.

45
MCQmedium

A notification is not sending emails to the intended recipients. The notification's 'Who will receive' tab is set to 'Event creator' and the event is triggered by a business rule. However, the email recipient list is empty. What is the most likely cause?

A.The notification is inactive
B.The email template is missing the recipient field
C.The system property 'glide.email.smtp.port' is set incorrectly
D.The event was created by a system account, not a real user
AnswerD

System accounts like 'guest' have no valid email, resulting in empty recipient list.

Why this answer

When a notification's 'Who will receive' tab is set to 'Event creator' and the event is triggered by a business rule, the system resolves the recipient by looking up the user who triggered the event. If the event was created by a system account (e.g., 'system' or 'guest'), that account has no valid email address, resulting in an empty recipient list. This is the most likely cause because the notification is otherwise correctly configured and active.

Exam trap

The trap here is that candidates often assume the notification is inactive or misconfigured, but the real issue is that system accounts lack email addresses, causing the recipient list to be empty despite the notification being active and correctly configured.

How to eliminate wrong answers

Option A is wrong because if the notification were inactive, it would not attempt to send at all, but the question states the email recipient list is empty, implying the notification is active but fails to find recipients. Option B is wrong because the email template is used for the email body and subject, not for determining recipients; the recipient list is controlled by the 'Who will receive' tab and the event creator. Option C is wrong because an incorrect SMTP port would cause a delivery failure or error, not an empty recipient list; the recipient list is built before the SMTP connection is attempted.

46
MCQmedium

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?

A.The integration user's session has expired during the request.
B.The portal widget is using a different table name in the API call.
C.The ACL is evaluated against the portal user, who lacks the 'snc_internal' role.
D.The REST API endpoint is mapped to the wrong table.
AnswerC

Correct: In portal, the user's session is used for ACL checks.

Why this answer

Option C is correct because 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.

Exam trap

The trap here is that candidates assume the ACL is evaluated against the authenticated integration user (the REST message's credentials) rather than the end-user who triggered the portal action, leading them to overlook the role mismatch between the portal user and the ACL requirement.

How to eliminate wrong answers

Option A is wrong because if the integration user's session had expired, the REST API call would return an authentication error (e.g., HTTP 401), not a success status. Option B is wrong because using a different table name in the API call would cause a different error (e.g., 'Table not found' or HTTP 404), not a silent failure with a success response. Option D is wrong because if the REST API endpoint were mapped to the wrong table, the API call would either fail with an error or create a record in the wrong table, but the logs show a success response and no record creation, which points to an ACL issue, not a mapping issue.

47
MCQeasy

Based on the exhibit, who will receive the email notification?

A.No one receives the email.
B.The caller only.
C.The assigned user only.
D.Both assigned user and caller.
AnswerB

Caller is set and receives.

Why this answer

Option B is correct because the exhibit shows that the 'Caller' checkbox is selected in the notification's 'Who will receive' configuration, while the 'Assigned user' checkbox is not selected. In ServiceNow, when only the 'Caller' option is checked, the notification is sent exclusively to the user listed as the caller on the record, regardless of who the record is assigned to.

Exam trap

The trap here is that candidates often assume that the assigned user always receives notifications by default, but ServiceNow requires explicit selection of the 'Assigned user' checkbox in the notification record for that to happen.

How to eliminate wrong answers

Option A is wrong because the notification is configured with the 'Caller' checkbox selected, which means at least one recipient (the caller) will receive the email. Option C is wrong because the 'Assigned user' checkbox is not selected in the exhibit, so the assigned user will not receive the notification. Option D is wrong because both checkboxes would need to be selected for both the caller and assigned user to receive the notification; only the 'Caller' checkbox is selected.

48
MCQeasy

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?

A.The read ACL is set to type 'record' instead of 'table'.
B.The table 'u_employee_info' has no 'read' ACL defined by default, so access is denied.
C.The write ACL is overriding the read ACL because it has a higher priority.
D.The read ACL is set to require a role 'snc_employee' instead of 'employee'.
AnswerD

Correct: Role names must exactly match.

Why this answer

Option D is correct because 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.

Exam trap

The trap here is that candidates assume ACLs are inherited or that a write ACL implicitly grants read access, but ServiceNow requires separate ACLs for each operation and exact role name matching.

How to eliminate wrong answers

Option A is wrong because ACLs in ServiceNow are always applied at the table level for table access; there is no 'record' type for ACLs—the type 'record' does not exist. Option B is wrong because ServiceNow does not require a default read ACL; if no ACL matches, access is denied by default, but the administrator created a read ACL that should grant access if correctly configured. Option C is wrong because ACLs in ServiceNow do not have priority ordering; each ACL is evaluated independently, and a write ACL does not override a read ACL—both must be satisfied for their respective operations.

49
MCQmedium

Refer to the exhibit. An incident is updated and state changes from 'New' to 'In Progress'. Active is true. The notification is not sent. Which is the most likely cause?

A.The condition 'state changes' is not satisfied because the state changed from 'New' to 'In Progress', which is a change.
B.The email template 'incident_update' is missing or invalid.
C.The assigned user field is empty, so there is no recipient for the notification.
D.The notification is configured to send only on insert, not on update.
AnswerC

If assigned_to is empty, no user receives the notification.

Why this answer

The condition requires state changes AND active is true. Both are true. However, the notification might be missing a condition that the assigned user is not empty.

Or the email template might be missing. But the most typical reason is that the 'Who will receive' is 'Assigned user', but the incident's assigned_to field is empty. The exhibit does not show the assigned user, but the condition doesn't check assigned_to.

However, if assigned_to is empty, the notification will not send because there is no recipient. The log does not indicate an error, just that notification was not sent.

50
MCQeasy

A developer wants to create a Scripted REST API endpoint that returns data from a custom table. The endpoint must only be accessible to users with the 'api_user' role. Which of the following is the best practice to enforce this restriction?

A.Add a condition in the script that checks gs.hasRole('api_user') for each request.
B.Set the system property 'glide.service.catalog.enforce_acl' to true.
C.Use a 'read' ACL on the table and set the endpoint to 'Requires authentication'.
D.Define a read ACL on the custom table that requires the 'api_user' role.
AnswerD

Correct: ACLs provide table-level security.

Why this answer

Option D is correct because the best practice for restricting access to a Scripted REST API endpoint in ServiceNow is to use an ACL (Access Control List) on the underlying table. When the endpoint is set to 'Requires authentication', the platform automatically evaluates table-level ACLs for each record operation. By defining a read ACL that requires the 'api_user' role, you enforce role-based access at the data layer, which is more secure and maintainable than checking roles in script.

Exam trap

The trap here is that candidates often confuse 'Requires authentication' with role-based access control, assuming that authentication alone is sufficient to restrict access to specific roles, when in fact a separate ACL is required to enforce the role check.

How to eliminate wrong answers

Option A is wrong because checking gs.hasRole('api_user') in script is an anti-pattern; it bypasses the platform's declarative security model, is harder to audit, and can be inconsistent if the script logic is not applied uniformly. Option B is wrong because the system property 'glide.service.catalog.enforce_acl' is specific to Service Catalog items, not Scripted REST APIs or custom table access. Option C is wrong because setting the endpoint to 'Requires authentication' only ensures the user is authenticated, not that they have the 'api_user' role; a read ACL on the table is still needed to enforce role-based restrictions.

51
Multi-Selectmedium

Which TWO conditions must be met for a business rule to execute on a table? (Choose TWO.)

Select 2 answers
A.The business rule must be associated with a table.
B.The condition script must evaluate to true (or be empty).
C.The business rule must have at least one role specified in the 'Condition' tab.
D.The business rule must have an 'Advanced' script defined.
E.The business rule must have an order less than 100.
AnswersA, B

Business rules are table-specific.

Why this answer

Option A is correct because a business rule in ServiceNow is always scoped to a specific table; it cannot execute without being associated with one. The rule's 'Table' field defines the database table on which the rule triggers, and the platform checks this association before any execution logic runs.

Exam trap

The trap here is that candidates often confuse optional configuration fields (like roles or advanced scripts) with mandatory requirements, leading them to select options C or D as necessary conditions for execution.

52
MCQmedium

A notification is configured to send an email when a new incident is created. The email template uses the field 'Short Description', but the email shows empty for that field. The template is correct. What is the most likely cause?

A.The notification is not set to fire on create
B.The email template has a syntax error
C.The 'Short Description' field is read-only on the form
D.The 'Short Description' field is not populated at the time the notification is sent
AnswerD

Notifications often fire asynchronously; if the field is required but not yet filled, it could be empty.

Why this answer

Option D is correct because the notification fires when the incident is created, but the 'Short Description' field may not yet be populated at that exact moment if the record is saved before the field is filled. Notifications are triggered by the database write operation, and if the field is empty at that time, the email template will render it as blank, even though the template itself is correct.

Exam trap

The trap here is that candidates often assume a field is always populated at the time of record creation, but ServiceNow notifications fire immediately upon the database insert, before any post-save business rules or user input may fill the field.

How to eliminate wrong answers

Option A is wrong because the notification is explicitly configured to send an email when a new incident is created, so it does fire on create; the issue is not about the trigger event. Option B is wrong because the question states the template is correct, so a syntax error is not the cause. Option C is wrong because the 'Short Description' field being read-only on the form does not affect its value in the database; the field can still be populated via other means (e.g., inbound email, script), and read-only status does not cause an empty value in the notification.

53
MCQeasy

A ServiceNow administrator is troubleshooting a notification issue. The company has a 'Customer Satisfaction Survey' notification that is supposed to send an email to the 'caller' of an incident when the incident state changes to 'Resolved' (state=6). The notification is configured with table 'incident', condition 'state changes to 6', and recipient 'caller'. However, the email is not being sent. The administrator checks the system log and finds no errors. The notification has an advanced script that checks if the 'caller' has a valid email address. The script is: if (current.caller_id.email == '') { return false; }. The administrator confirms that the caller's email field is populated. What is the most likely reason the notification is not sending?

A.The advanced script should be removed because it is blocking valid emails.
B.The notification condition should be 'state is 6' rather than 'state changes to 6'.
C.The script should check for null instead of empty string.
D.The recipient field should use the email field directly instead of the reference 'caller'.
AnswerB

If the incident is created with state 6, 'changes to' condition does not trigger.

Why this answer

Option B is correct because the notification condition 'state changes to 6' triggers only when the state field transitions from a different value to 6. If the incident is already at state 6 when the notification is evaluated (e.g., after a business rule or update that sets state to 6 without a prior change), the condition will not fire. Using 'state is 6' ensures the notification sends whenever the incident is in that state, regardless of how it got there.

The advanced script is not the issue since the caller's email is populated, and the recipient field is correctly configured.

Exam trap

The trap here is that candidates often confuse 'state changes to' with 'state is', not realizing that 'changes to' requires a transition from a different value, while 'is' triggers on the current state regardless of history.

How to eliminate wrong answers

Option A is wrong because the advanced script correctly checks for an empty email string; removing it would not fix the issue since the email is populated and the script returns true. Option C is wrong because checking for null instead of empty string is unnecessary; the email field is a string and an empty string is the correct check for a missing email. Option D is wrong because using the reference field 'caller' is the standard way to access the caller's email via dot-walking (current.caller_id.email); the recipient field expects a user reference, not a direct email string.

54
MCQmedium

A business rule is set to run on 'before update' on the 'incident' table. The script updates 'current.description' and then calls 'current.update()'. What is the likely outcome?

A.The description is updated and no error occurs.
B.The script causes a recursion error or multiple updates.
C.The script fails silently because current.update() is not allowed in before business rules.
D.The script runs but the description is not updated.
AnswerB

current.update() triggers the same business rule again.

Why this answer

In ServiceNow, calling `current.update()` inside a 'before update' business rule triggers a recursive loop because the update operation re-invokes the same business rule. The platform detects this recursion and typically throws an error or causes multiple updates, leading to the described outcome. Option B is correct because the script explicitly calls `current.update()`, which is prohibited in before business rules to prevent infinite loops.

Exam trap

The trap here is that candidates assume `current.update()` is always safe or that it simply updates the record once, but ServiceNow's before business rules are designed to avoid explicit update calls to prevent recursion.

How to eliminate wrong answers

Option A is wrong because calling `current.update()` in a before update business rule does not simply update the description without issue; it causes recursion or multiple updates. Option C is wrong because `current.update()` is technically allowed in before business rules (the script will execute), but it is strongly discouraged due to recursion; it does not fail silently. Option D is wrong because the description is updated by the script, but the recursion or error prevents a clean single update.

55
MCQeasy

Which of the following best describes the purpose of a 'Script Include' in ServiceNow?

A.To run automated actions on a schedule
B.To set field values dynamically based on conditions
C.To define client-side behavior when a form loads
D.To encapsulate reusable server-side logic
AnswerD

Script Includes are used for server-side code reuse.

Why this answer

A Script Include in ServiceNow is designed to encapsulate reusable server-side logic that can be called from other server-side scripts, such as Business Rules, Scheduled Jobs, or other Script Includes. It promotes code modularity and reusability by defining functions or classes that execute on the server instance, not on the client. Option D correctly identifies this core purpose.

Exam trap

ServiceNow often tests the distinction between server-side and client-side execution contexts, and the trap here is that candidates confuse Script Includes with Client Scripts or Business Rules, failing to recognize that Script Includes are purely for reusable server-side logic and not for direct UI or scheduled automation.

How to eliminate wrong answers

Option A is wrong because running automated actions on a schedule is the purpose of a Scheduled Job, not a Script Include; Script Includes are invoked programmatically, not by a time-based trigger. Option B is wrong because setting field values dynamically based on conditions is typically handled by Business Rules (server-side) or Client Scripts (client-side), not by Script Includes, which are reusable libraries. Option C is wrong because defining client-side behavior when a form loads is the role of a Client Script (e.g., onLoad), whereas Script Includes execute exclusively on the server and cannot directly manipulate the client DOM or browser events.

56
Multi-Selectmedium

Which THREE of the following are true regarding business rules and their execution order?

Select 3 answers
A.After business rules run after the database write operation.
B.Before business rules cannot prevent the record from being saved.
C.Before business rules run before the database write operation.
D.Before display business rules run when the record is loaded into a form.
E.Async business rules run in the same transaction as the triggering event.
AnswersA, C, D

After rules execute post-insert/update.

Why this answer

Option A is correct because 'After' business rules are configured to execute after the database write operation has completed. This means they run once the record has been successfully saved to the database, allowing them to perform actions that depend on the record's existence, such as triggering notifications or updating related records.

Exam trap

The trap here is that candidates often confuse 'Async' business rules as running in the same transaction as the triggering event, but they actually run in a separate transaction, which can lead to unexpected behavior if not accounted for.

57
MCQmedium

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?

A.The user making the web service call does not have the 'itil' role.
B.The business rule is not configured to run in the 'System' (global) scope across all applications.
C.The business rule runs after the web service update and the field is already committed.
D.The business rule condition is incorrect for web service updates.
AnswerB

Correct: Business rules need appropriate application access to run cross-scope.

Why this answer

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.

Exam trap

The trap here is that candidates assume 'global scope' means the rule runs everywhere, but ServiceNow's scoping model requires an explicit 'Run in all scopes' flag for global rules to execute across application boundaries.

How to eliminate wrong answers

Option A is wrong because the 'itil' role is not required for a business rule to execute; business rules run based on table operations, not user roles, and the rule's condition does not check for roles. Option C is wrong because the business rule is set to run 'before update', so it executes before the database commit, not after; the web service update would still trigger the before-update event. Option D is wrong because the business rule condition (assignment group empty) is straightforward and does not differentiate between UI updates and web service updates; the issue is scope, not the condition logic.

58
MCQhard

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?

A.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.
B.The notification's 'Who will receive' is set to assignment group, but the assignment group is empty.
C.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.
D.The notification is configured to send only on insert, not on update.
AnswerA

For timed notifications, the condition is evaluated when the trigger executes. If the state hasn't changed (i.e., it still is 'In Progress'), the condition 'state changes' will be false because it compares to previous value. Since the state changed earlier, at trigger time the field may not have changed from the last value. Actually, 'state changes' is a condition that checks if the field changed during the update that caused the trigger. For timed notifications, the condition is evaluated at the time of the trigger, and 'state changes' might not be true if the field hasn't changed since the trigger was created. This is a common pitfall.

Why this answer

The condition requires state changes AND assigned_to is not empty. On update, both conditions are met, but the trigger may still be waiting. However, the condition is checked at the time of the update; it should fire.

The issue might be that the notification is configured to send only on insert or update, but the trigger shows a future next_action, indicating it's scheduled. Possibly the notification is set to send after a delay or the condition uses 'state changes' which is a field change condition that might not be met if the state changed from null to 'In Progress'? Actually, state changes is a condition that checks if the field changed. The correct answer is that the condition 'state changes' is not satisfied because the previous state was empty? But incident state is always set.

Another possibility: the notification is set to 'Record inserted or updated' but the trigger is still waiting; maybe the notification is timed and the condition is evaluated at the time of the trigger, not at the time of the update. The most likely reason is that the condition 'state changes' requires the previous value to be different, which it is. However, the exhibit shows a sys_trigger with state 'waiting' and a future next_action, indicating the notification is scheduled for a later time and hasn't run yet.

So the notification will fire later.

59
Multi-Selecthard

Which THREE statements about Access Control Lists (ACLs) are true? (Choose THREE.)

Select 3 answers
A.ACLs can be defined for tables, records, fields, and scripts.
B.ACLs can use condition scripts to grant or deny access.
C.If 'requires role' is checked and no roles are listed, only users with the 'admin' role can access.
D.An ACL can only have one role specified.
E.An ACL must have a script to evaluate conditions.
AnswersA, B, C

ACL types include table, record, field, and script.

Why this answer

Option A is correct because in ServiceNow, Access Control Lists (ACLs) can be defined to control access at multiple granularity levels: tables (entire table operations), records (specific rows), fields (individual columns), and scripts (execution of business rules or script includes). This allows administrators to enforce security policies precisely where needed.

Exam trap

ServiceNow often tests the misconception that ACLs must have a script to evaluate conditions, but in ServiceNow, conditions can be purely role-based or use simple field comparisons without any scripting.

60
MCQeasy

A business rule is configured to run 'before' a record is updated. If the business rule sets a field value and then a subsequent 'after' business rule also updates the same field, what will be the final value stored in the database?

A.Both values are stored in a history field
B.The database rejects the second change
C.The value set by the 'after' business rule
D.The value set by the 'before' business rule
AnswerC

The 'after' rule runs after the initial save and can modify the record again.

Why this answer

In ServiceNow, business rules execute in a defined order: 'before' business rules run first, followed by 'after' business rules. When both a 'before' and an 'after' business rule update the same field, the 'after' business rule executes later in the transaction and its value overwrites the 'before' business rule's value. The final value stored in the database is therefore the one set by the 'after' business rule, because the database write occurs after all business rules have completed.

Exam trap

The trap here is that candidates often assume 'before' rules have final authority because they run earlier, but ServiceNow's execution order ensures 'after' rules override 'before' rules for the same field.

How to eliminate wrong answers

Option A is wrong because ServiceNow does not automatically store both values in a history field; field history is only recorded if the 'Audit' feature is enabled on the field, and even then it tracks changes over time, not both values from a single update. Option B is wrong because the database does not reject the second change; ServiceNoW's database engine (MySQL/MariaDB) processes the final value after all business rules run, and no conflict detection is triggered for sequential updates within the same transaction. Option D is wrong because the 'before' business rule runs first, but its value is overwritten by the later-executing 'after' business rule, so the 'before' value is not the final stored value.

61
Multi-Selectmedium

Which TWO of the following are best practices when working with ACLs?

Select 2 answers
A.Always create a single, broad ACL that covers all needs
B.Ensure ACLs are scoped to the application that needs them
C.Use the condition builder instead of scripts for simple conditions
D.Grant 'read' access to all users on all tables to simplify administration
E.Write complex scripts in ACLs to handle all edge cases
AnswersB, C

Scoping prevents ACLs from affecting other applications.

Why this answer

Option B is correct because ACLs should be scoped to the specific application that requires them. This ensures that only the necessary records and fields are accessible, following the principle of least privilege. Overly broad ACLs can expose sensitive data and violate data security requirements.

Exam trap

The trap here is that candidates often think a single broad ACL simplifies administration, but ServiceNow's ACL evaluation engine processes ACLs in order, and a broad ACL can inadvertently grant access to records that should be restricted.

62
MCQhard

A before business rule on the Change Request table is supposed to set the 'risk' field based on the 'impact' and 'urgency' fields. The rule uses the current.update() method. However, when the rule runs, it causes a recursive loop. What is the best solution?

A.Use current.setValue() instead of current.update().
B.Use current.update() with a query to avoid recursion.
C.Add a condition to check if the risk field is already set.
D.Set the business rule to run after instead of before.
AnswerA

setValue() modifies the field without triggering another business rule.

Why this answer

Option A is correct because current.update() triggers the business rule again on the same record, causing a recursive loop. Using current.setValue() only modifies the field in memory without writing to the database, so it does not re-trigger the business rule. This is the standard pattern for avoiding recursion in before business rules when setting field values.

Exam trap

The trap here is that candidates may think checking a condition or changing the timing (before vs. after) will stop recursion, but the root cause is the use of current.update() which always triggers a new database write and re-evaluation of business rules.

How to eliminate wrong answers

Option B is wrong because current.update() with a query still performs a database write, which will re-trigger the business rule and cause recursion; there is no built-in mechanism to suppress recursion via query parameters. Option C is wrong because checking if the risk field is already set does not prevent recursion—the business rule still calls current.update(), which will fire the rule again regardless of the field's current value. Option D is wrong because changing the business rule to run after instead of before does not solve the recursion; current.update() in an after business rule also writes to the database and re-triggers the rule, and after rules are typically used for non-field-setting actions like notifications.

63
Multi-Selecteasy

Which TWO of the following are true about business rules in ServiceNow? (Choose two.)

Select 2 answers
A.They are only available in the global scope.
B.They can be configured to run 'before' or 'after' a database operation.
C.They can be scheduled to run at specific times.
D.They can be set to run on display, insert, update, delete, or query.
E.They run on the client side to provide immediate feedback.
AnswersB, D

Correct: 'When to run' field specifies before or after.

Why this answer

Option B is correct because business rules in ServiceNow can be configured to run 'before' or 'after' a database operation (insert, update, delete, or query). This allows administrators to perform actions such as data validation or modification at specific points in the database transaction lifecycle, ensuring data integrity and automating business logic.

Exam trap

The trap here is that candidates often confuse business rules with scheduled jobs or client scripts, mistakenly thinking business rules can be scheduled or run client-side, when in fact they are strictly server-side and event-driven by database operations.

64
MCQmedium

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?

A.The 'Required roles' field on the 'incident' table form layout requires a different role to update.
B.The ACL is defined on a different table that extends 'incident'.
C.There is a read ACL that denies read access, which prevents any write operations.
D.The table is set to 'High Security' in the application properties.
AnswerA

Correct: Form-level required roles can override ACLs for UI actions.

Why this answer

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.

Exam trap

The trap here is that candidates often focus solely on ACLs and overlook the form layout's 'Required roles' setting, assuming that ACL permissions alone control all write operations, when in fact form-level restrictions can override ACL grants.

How to eliminate wrong answers

Option B is wrong because an ACL defined on a different table that extends 'incident' would still apply to the 'incident' table via inheritance, and if it grants write access, it would not prevent updates. Option C is wrong because a read ACL that denies read access would prevent users from viewing records, but it does not directly block write operations; write operations are controlled by separate write ACLs, and the administrator confirmed no other write ACLs exist. Option D is wrong because the 'High Security' setting in application properties affects table-level security by requiring the 'admin' role for all operations, but it does not selectively block updates for the 'itil' role; it would block all access unless the user has the 'admin' role.

65
MCQhard

A catalog client script is supposed to show a variable when another variable equals 'Yes'. The script runs on 'onChange' of the first variable. However, the second variable does not appear. What is a possible cause?

A.The g_form.setDisplay() method is used incorrectly.
B.The client script is not set to 'All' catalog items.
C.The condition is written with 'g_form.getValue' for the wrong variable.
D.The script is set to 'onLoad' instead of 'onChange'.
AnswerB

If the script is restricted to specific items, it won't run on others.

Why this answer

Option B is correct because a client script that is not set to run on 'All' catalog items will only execute on the specific catalog item it was created for. If the script is scoped to a different item, the onChange event for the first variable on the current item will not trigger the script, so the second variable will never be shown. In ServiceNow, catalog client scripts must be explicitly associated with the correct catalog item or set to 'All' to apply globally.

Exam trap

ServiceNow often tests the misconception that a client script will automatically apply to all catalog items unless explicitly scoped, when in fact the default behavior requires explicit association or setting the catalog item field to 'All'.

How to eliminate wrong answers

Option A is wrong because g_form.setDisplay() is a valid method for showing or hiding a variable, and if used correctly with the right parameters (e.g., g_form.setDisplay('variable_name', true)), it would work; the issue here is that the script does not run at all, not that the method is misused. Option C is wrong because if the condition were written with g_form.getValue for the wrong variable, the script would still execute but evaluate incorrectly; the symptom of the variable not appearing at all indicates the script is not firing, not a logic error in the condition. Option D is wrong because the question states the script runs on 'onChange' of the first variable, so it is not set to 'onLoad'; if it were onLoad, it would run when the form loads, not on a field change, but the problem description confirms the intended event is onChange.

Ready to test yourself?

Try a timed practice session using only Application Rules, ACL and Notifications questions.