Knowledge + Practice

CCNA Sn Automation Scripts Questions

65 questions · Sn Automation Scripts topic · All types, answers revealed

Practice these questions Exam hub All questions

1

Multi-Selecthard

Which TWO statements are true about using GlideAggregate in business rules?

Select 2 answers

A.GlideAggregate allows adding non-aggregated fields to the result set using addField().

B.GlideAggregate can be used to perform SQL-like GROUP BY operations.

C.GlideAggregate can be used inside a business rule to compute values.

D.GlideAggregate automatically orders the results by the aggregated field.

E.GlideAggregate can only be used in client scripts.

AnswersB, C

GlideAggregate is designed to perform grouping and aggregate functions like count, sum, min, max.

Why this answer

GlideAggregate extends GlideRecord and allows performing SQL-like GROUP BY operations on database queries, enabling aggregation of data such as sums, counts, averages, etc. Option C is correct because GlideAggregate can be instantiated and used within a business rule to compute aggregated values from the database, which is a common pattern for server-side calculations.

Exam trap

The trap here is that candidates often confuse GlideAggregate's addField() with GlideRecord's addField() for retrieving field values, not realizing that in GlideAggregate, addField() is used for grouping and does not return raw non-aggregated data.

Practice this question →

2

MCQeasy

A company needs to automatically update the 'Assignment group' field on the Change Request table to 'Change Management' when the 'Category' field is set to 'Network'. Which type of business rule should be used?

A.Display business rule

B.Async business rule

C.After business rule

D.Before business rule

AnswerD

Before rules run before the database write and can set field values that will be saved.

Why this answer

A Before business rule (Option D) is correct because it runs before the record is saved to the database, allowing you to set the 'Assignment group' field value based on the 'Category' field before the insert or update operation completes. This ensures the assignment group is correctly populated in the same database transaction, avoiding the need for a separate update.

Exam trap

ServiceNow often tests the distinction between Before and After business rules, and the trap here is that candidates may choose 'After business rule' thinking it can still update the record, but they overlook that an After rule requires an additional update operation, which is not the most efficient or correct approach for setting a field value at the time of save.

How to eliminate wrong answers

Option A is wrong because a Display business rule runs on the client side when a form is loaded or refreshed, and cannot modify field values that are persisted to the database. Option B is wrong because an Async business rule runs asynchronously after the record is committed, which would cause a delay and require a second database operation to update the assignment group, not meeting the requirement for an automatic update at the time of save. Option C is wrong because an After business rule runs after the record has been saved, so any changes made to the 'Assignment group' field would require an additional database write (update), which is less efficient and could lead to race conditions or extra audit records.

Practice this question →

3

Matchingmedium

Match each ServiceNow table naming convention to its purpose.

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

Concepts

Matches

User-created custom table

System table (platform core)

Scoped application table

Performance Analytics tables

CMDB tables

Why these pairings

In ServiceNow, table naming conventions use prefixes to indicate their origin or module. sys_ denotes core system tables, u_ denotes user-created custom tables, and m2m_ denotes many-to-many relationship tables. Common confusions involve swapping these prefixes.

Practice this question →

4

Multi-Selectmedium

A developer is writing a business rule that should run on after update of the Incident table to send an email notification when the state changes. The developer uses the method current.state.changes() to detect the change. However, the email is sent multiple times for the same incident update. What are two possible reasons? (Choose two.)

Select 2 answers

A.The business rule is set to run on every update, but the script does not check the previous state

B.The business rule's condition field is set to 'state changes'

C.The business rule runs on both insert and update

D.The email notification is triggered by a different business rule

E.The business rule is set to run on before update as well

AnswersD, E

Correct. Another business rule might also be sending an email on state change, leading to duplicate notifications.

Why this answer

Duplicate emails on the same incident update occur when multiple business rules send the notification or when the same rule runs multiple times. Option D is correct: another business rule may also be configured to send an email on state change, causing duplicates. Option E is correct: if the business rule runs on both before and after update, it will execute twice for the same update, sending two emails.

Option C is incorrect because running on insert causes an additional email on insert, not multiple emails during a single update operation. Option A is incorrect because current.state.changes() properly detects state changes; the issue is not about checking the previous state. Option B is incorrect because setting the condition field to 'state changes' would actually help filter, not cause duplicates.

Practice this question →

5

Multi-Selecthard

Which two of the following are best practices when writing Script Includes in ServiceNow? (Choose two.)

Select 2 answers

A.Keep the script source code under 10 KB to improve performance.

B.Wrap all code in try-catch blocks to handle errors gracefully.

C.Use gs.addInfoMessage() to output debug information while developing.

D.Avoid using GlideRecord queries inside loops to prevent performance issues.

E.Use GlideAggregate instead of GlideRecord for aggregation calculations like count or sum.

AnswersD, E

Queries inside loops cause multiple database calls; use batch processing or GlideAggregate.

Why this answer

Running GlideRecord queries inside loops (e.g., for or while) causes multiple database round-trips, which severely degrades performance, especially with large datasets. Instead, you should use GlideRecord's query() once and iterate over the result set, or use GlideAggregate for aggregated calculations to minimize database calls.

Exam trap

ServiceNow often tests the misconception that all code should be wrapped in try-catch for error handling, but in ServiceNow, this is not a best practice because it can hide logic errors and is rarely needed due to the platform's built-in error logging and transactional rollback.

Practice this question →

6

MCQhard

A developer creates a script include named 'Utils' with a function that uses gs.log('message'). When called from a business rule on the incident table, the log is written. However, when called from a scheduled job in the same scope, no log appears. What could be the reason?

A.The scheduled job's log level is set to 'errors only'.

B.The business rule runs in the same scope but the scheduled job runs in a different scope.

C.The script include is not global.

D.The scheduled job runs with a different user context.

AnswerC

Correct. If the script include is not global, it may not be accessible from scheduled jobs even if in the same scope, because scheduled jobs can run in a different context.

Why this answer

If the script include is not global (i.e., it is scoped to a specific application), it may not be accessible from all execution contexts. Even though the scheduled job is defined in the same scope, scheduled jobs can run under a different context (such as the global scope) or have additional restrictions that prevent access to non-global script includes. This explains why the business rule works (as it runs in the application scope) but the scheduled job does not.

Option A is incorrect because log level settings do not affect script include accessibility—they control whether log messages are displayed. Option B is incorrect because the scenario states the scheduled job is in the same scope. Option D is incorrect because user context does not affect script include visibility; it affects record access.

Practice this question →

7

MCQhard

A script include is defined as a public static function and is called from multiple business rules. After an upgrade, some business rules start failing with 'undefined' errors. What is the most likely cause?

A.The script include was made private.

B.The script include's ACLs changed.

C.The script include's function signature changed.

D.The script include's scope changed.

AnswerC

Function parameter count or name change leads to undefined errors on call.

Why this answer

If the function signature changed (e.g., parameters or return type), existing calls to the script include would fail with 'undefined' errors. Option A would cause 'not found' errors, not undefined. Option B: ACLs do not affect server-side execution.

Option D: scope change could cause access errors or 'not found', not typically 'undefined'.

Practice this question →

8

MCQmedium

In a large enterprise environment, the ServiceNow instance is heavily customized. A business rule on the Change Request [change_request] table runs on after update to initiate a complex workflow involving multiple approvals and updates to Configuration Items (CIs). Recently, the IT operations team noticed that the workflow fails to start for many change requests. The system logs show the error: "Business rule script error: Cannot read property 'sys_id' of null". The developer inspects the business rule script and sees the following code snippet: var task = new GlideRecord('task'); task.get(current.sys_id); var relatedCI = task.cmdb_ci; // The rest of the script uses relatedCI to update the CI's status. The developer knows that change requests are not stored in the task table; they are in change_request. However, the script was written by a previous developer and has been working for months. The developer must fix the script to ensure the workflow starts correctly. Which action should the developer take?

A.Wrap the script in a try-catch block and log the error then return

B.Change GlideRecord('task') to GlideRecord('change_request')

C.Use current.cmdb_ci directly

D.Add a check if (task.isValidRecord()) before accessing cmdb_ci

AnswerC

The current record is a change request, so current.cmdb_ci contains the CI.

Why this answer

Best because current is already the change request record, so current.cmdb_ci is directly available. Option A would work but adds unnecessary database query. Option B would prevent the error but not fix the root cause; the script would still fail to get the CI if the record is not in task.

Option D would hide the error but not fix the logic.

Practice this question →

9

MCQeasy

A small IT department uses ServiceNow for incident management. They have a business rule that runs after insert on the Incident table. The rule is intended to send an email notification to the assignment group whenever a new incident is created. The rule uses a standard "send event" method, and the email notification is set up in the system mail properties. Recently, the group leader noticed that some incidents are not triggering emails. The developer investigates the business rule and confirms that the script executes without errors, but the email is not sent for those specific incidents. The developer checks the email notification configuration and finds that it is set to send to the "assigned user" rather than the "assigned group". After correcting this, the emails start working. However, the developer wants to understand why only some incidents were affected. Which of the following best explains the issue?

A.The email notification was incorrectly configured to send to the user, so only incidents assigned to a specific user triggered emails; incidents assigned to a group had no recipient

B.The assignment group did not have any members for those incidents

C.The business rule script had a condition that randomly skipped some incidents

D.The SMTP server was intermittently down

AnswerA

When an incident is assigned to a group, there is no 'assigned user' to send the email to.

Why this answer

The email notification was configured to send to the 'assigned user' field, which is populated only when an incident is assigned to a specific individual. Incidents assigned directly to a group (with no user assigned) would have an empty 'assigned user' field, causing the notification to have no recipient and thus not be sent. After correcting the configuration to send to the 'assigned group', emails were triggered for all incidents, confirming that the issue was the recipient field mismatch.

Exam trap

The trap here is that candidates might assume the business rule or SMTP server is at fault, rather than recognizing that an empty recipient field in the notification configuration causes selective delivery failures based on assignment state.

How to eliminate wrong answers

Option B is wrong because the assignment group having no members would not prevent the email from being sent; the notification would still attempt to send to the group, and if the group had no members, it might log a warning but not silently fail for some incidents. Option C is wrong because the developer confirmed the business rule script executes without errors and there is no evidence of a random condition; the issue is purely in the email notification configuration, not the business rule logic. Option D is wrong because an intermittent SMTP server outage would affect all outgoing emails, not selectively only those assigned to a group, and the developer found the root cause in the recipient configuration.

Practice this question →

10

MCQeasy

Refer to the exhibit. The script runs as a business rule on the incident table. What will happen when this script executes?

A.The update will only occur if the business rule condition evaluates to true.

B.The update will trigger other business rules that run on update.

C.The record will be updated without triggering any other business rules.

D.The script will throw an error because setValue() requires a third parameter.

AnswerB

When update() is called, it triggers all business rules set to run on update for that table.

Why this answer

The script uses `setValue()` to update a field on the current record, which is an update operation. In ServiceNow, business rules that run on 'update' will fire when a record is updated, unless the business rule is specifically configured to run 'asynchronously' or with the 'Don't run other business rules' option. Since the exhibit does not show such configuration, the update will trigger other business rules that run on update.

Exam trap

ServiceNow often tests the misconception that `setValue()` in a business rule will not trigger other business rules, but the default behavior is that it does, unless the 'Don't run other business rules' checkbox is explicitly selected.

How to eliminate wrong answers

Option A is wrong because the script does not contain a condition; the business rule's condition is evaluated before the script runs, but the script itself will execute regardless of the condition if the condition is true. Option C is wrong because the default behavior in ServiceNow is that updates trigger other business rules unless the 'Don't run other business rules' checkbox is selected, which is not shown. Option D is wrong because `setValue()` in ServiceNow only requires two parameters (field name and value) and does not require a third parameter; the script will not throw an error for that reason.

Practice this question →

11

MCQmedium

A Business Rule is designed to send an email notification when a record is assigned to a specific group. The email is sent despite the condition not being met. What is the most likely cause?

A.The Business Rule runs on insert only.

B.The email notification is also triggered by a different Business Rule.

C.The condition is written incorrectly.

D.The condition is using a field that is not on the table.

AnswerC

Syntax error may cause condition to always be true.

Why this answer

A Business Rule condition that is syntactically or logically incorrect can cause the condition to always evaluate to true, triggering the email notification even when the intended condition is not met. For example, using an incorrect operator or referencing a field that always evaluates to true (e.g., `current.state == 1` when the field is a string) may cause the condition to be true unexpectedly. In ServiceNow, Business Rules evaluate conditions in JavaScript; if the condition is written incorrectly, it may always return true, causing the action to execute despite the intended condition not being satisfied.

Exam trap

ServiceNow often tests the misconception that a Business Rule will not execute if the condition is invalid, when in fact an incorrectly written condition can silently evaluate to true and trigger actions unexpectedly.

How to eliminate wrong answers

Option A is wrong because a Business Rule running on insert only would not affect the condition evaluation; if the condition is met on insert, the email would still be sent, but the issue is the email is sent when the condition is not met, so the trigger type is irrelevant. Option B is wrong because while another Business Rule could also send an email, the question specifies the email is sent 'despite the condition not being met' for this specific rule, implying the rule itself is faulty, not that a separate rule is responsible. Option D is wrong because using a field not on the table would cause a script error or null reference, typically preventing the Business Rule from running or sending the email, not causing it to send when the condition is false.

Practice this question →

12

MCQmedium

A developer wants to use a business rule to prevent a user from saving an incident if the short description is empty. Which script should be used?

A.current.setAbortAction(true); gs.addInfoMessage('Short description required');

B.gs.addInfoMessage('Short description required'); current.setAbortAction(true);

C.gs.addErrorMessage('Short description required'); current.setAbortAction(true);

D.current.setAbortAction(true); gs.addErrorMessage('Short description required');

AnswerD

Correct; setAbortAction stops the save and then the error message is displayed.

Why this answer

The proper order is to call `current.setAbortAction(true)` first to abort the save, then use `gs.addErrorMessage()` to display an error message. Option A is incorrect because it uses `gs.addInfoMessage()` for an informational message instead of an error, which does not properly indicate a validation failure. Option B is incorrect both because it reverses the order (the error message may not display after abort) and uses `addInfoMessage`.

Option C is incorrect because it reverses the order: the error message is added before the abort action, which may cause the message to be lost. Only D uses the correct order and the correct method for error messages.

Practice this question →

13

MCQeasy

The business rule above is intended to set the category of an incident based on the correlation_id. However, it is not working as expected. What is the most likely cause?

A.The script is trying to set a field that is read-only before insert.

B.The business rule runs before insert, so the correlation_id field may not have a value yet.

C.The sys_choice table does not contain the choices for the incident category field.

D.The GlideRecord query is incorrectly using 'name' instead of 'table'.

AnswerB

Before insert, the record is new; correlation_id might be empty if not provided.

Why this answer

Business rules that run 'before insert' execute before the record is saved to the database. At that point, the `correlation_id` field may not yet have a value if it is not provided by the user or set by another process. The script attempts to read `current.correlation_id` to determine the category, but if the field is empty, the condition fails and the category is never set.

Exam trap

ServiceNow often tests the misconception that all fields are populated at the time a 'before insert' business rule runs, when in fact only fields explicitly provided in the current operation are available.

How to eliminate wrong answers

Option A is wrong because the incident category field is not read-only before insert; it is a writable field that can be set by business rules. Option C is wrong because the sys_choice table contains the choices for the incident category field by default, and the issue is not about missing choices but about the timing of the script execution. Option D is wrong because the GlideRecord query using 'name' instead of 'table' would cause a different error (invalid table name), but the question describes the rule not working as expected, not throwing an error, and the core issue is the timing of the correlation_id value.

Practice this question →

14

MCQeasy

A company needs to prevent updates to a field after a record has been in state 'Closed' for more than 30 days. What is the best approach?

A.Use a Business Rule on query to check state and field value.

B.Use a UI Policy to set field read-only.

C.Use a Business Rule with condition when state changes to Closed, set the field to read-only.

D.Use a Business Rule on update with condition state=Closed and days since closed > 30, and abort action when field is being updated.

AnswerD

Correctly aborts update if condition met.

Why this answer

It uses a Business Rule on update with condition state=Closed and days since closed > 30, and abort action when the field is being updated. This server-side rule directly prevents any updates to the field after the condition is met. Option A (Business Rule on query) runs on query, not on update, so it does not prevent updates.

Option B (UI Policy) is client-side only and can be bypassed by direct web service or scripted updates. Option C (Business Rule when state changes to Closed, set field read-only) only makes the field read-only at the time of closure, but after 30 days it may not be enforced; also read-only is client-side and not a true prevention.

Practice this question →

15

MCQmedium

A developer writes a business rule to run on 'before' update of the Incident table. The rule sets a short description only if it is empty. However, the short description is never set even when it's empty. What is the most likely cause?

A.The developer used gs.setValue() instead of current.setValue().

B.The business rule runs after the database update.

C.The condition 'short_description IS EMPTY' is evaluated on the old value.

D.The business rule is set to run on insert only.

AnswerA

gs.setValue() is not a valid method; current.setValue() must be used to set field values in business rules.

Why this answer

In ServiceNow business rules, `gs.setValue()` is a GlideSystem method that does not exist for setting field values on the current record. The proper method is `current.setValue()`, which directly modifies the field on the current GlideRecord object. Using `gs.setValue()` would result in no change to the short description, even if the condition is met.

Exam trap

The trap here is that candidates may confuse `gs.setValue()` with a valid method, not realizing that `gs` is a system-level object without record manipulation capabilities, and that `current.setValue()` is the required approach for modifying fields on the current record.

How to eliminate wrong answers

Option B is wrong because the business rule is explicitly set to run 'before' update, so it executes prior to the database update, not after. Option C is wrong because the condition 'short_description IS EMPTY' is evaluated on the current value (the new value) in a 'before' update rule, not the old value; the old value is accessed via `current.short_description` before any changes. Option D is wrong because the business rule is explicitly set to run on update (as stated in the question), not on insert only.

Practice this question →

16

MCQhard

A company has a business rule on the Task table that runs on 'before' insert. The rule uses current.gotoField('short_description') and current.setValue('short_description', 'Default'). The rule is ordered to run at 500. However, a second business rule on the same table with order 100 also sets the short_description. What will be the final value of short_description?

A.'Default'

B.Both values will be concatenated

C.The value set by the rule at order 100

D.The field will be empty because gotoField() clears it

AnswerA

The rule with order 500 runs last and sets the value to 'Default'.

Why this answer

Business rules execute in ascending order based on their 'order' field. The rule at order 100 runs first and sets the short_description. Then the rule at order 500 runs and overrides that value with 'Default' using current.setValue().

Since both are 'before' insert rules, the final value written to the database is the one set by the last-executed rule, which is order 500.

Exam trap

The trap here is that candidates mistakenly think current.gotoField() clears the field or that rules execute in reverse order, when in fact the rule with the highest order number runs last and its setValue() takes precedence.

How to eliminate wrong answers

Option B is wrong because current.setValue() replaces the field value, it does not concatenate strings. Option C is wrong because although the rule at order 100 sets the value first, the rule at order 500 runs later and overwrites it, so the final value is not from order 100. Option D is wrong because current.gotoField() navigates to the field but does not clear its value; it only makes the field the current focus for scripting, and the subsequent setValue() writes 'Default'.

Practice this question →

17

MCQeasy

What is the purpose of using the 'Async' option in a business rule?

A.To run the rule immediately after the database operation.

B.To run the rule only when the record is viewed.

C.To prevent the rule from running on updates.

D.To run the rule in a separate background thread to avoid performance impact.

AnswerD

Correct; async rules are queued and run asynchronously.

Why this answer

The 'Async' option in a business rule causes the rule to execute in a separate background thread after the database operation, which avoids performance impact on the main transaction. Therefore, option D is correct. Option A is incorrect because running immediately is the default synchronous behavior, not async.

Option B is incorrect because 'Async' is not related to record viewing; that is controlled by the 'Display' condition. Option C is incorrect because async rules still run on updates; they just run asynchronously.

Practice this question →

18

Multi-Selecteasy

A developer is creating a business rule that should run on after update of the Incident table. The developer wants to ensure the rule only fires when the incident is assigned to a specific assignment group. Which conditions should be used in the business rule's condition field? (Choose two.)

Select 2 answers

A.current.operation() == 'update'

B.current.assignment_group.isValidRecord()

C.current.assignment_group == 'IT Support'

D.current.assignment_group.changes()

E.gs.getUser().getManager() == 'admin'

AnswersA, C

This ensures the rule only runs on update.

Why this answer

`current.operation() == 'update'` ensures the business rule only runs during an update operation on the Incident table. This is the standard way to check the database operation type in ServiceNow business rules, matching the requirement that the rule should fire 'on after update'.

Exam trap

The trap here is that candidates often confuse `current.assignment_group.changes()` with a condition that checks the current value, when in fact it only detects a change event, not the actual group assignment.

Practice this question →

19

MCQhard

A ServiceNow instance has a business rule that runs on after query on the Incident table. The rule adds a condition to the query to filter out incidents with state = 'Closed'. Recently, an update set containing a new business rule was installed, and now the filter is not applied. What might have caused this?

A.The new business rule has a higher order than the existing rule

B.The existing business rule is set to run only on insert

C.The new business rule uses query.setCondition() to set the query condition, replacing the existing condition

D.The new business rule uses glide.addNullQuery

AnswerC

setCondition() overwrites any previous conditions.

Why this answer

The new business rule likely uses query.setCondition() which replaces any existing conditions, including the filter from the existing rule. Option A is less likely because order determines execution sequence, but setCondition replaces. Option B is incorrect.

Option D is irrelevant.

Practice this question →

20

MCQmedium

You are a ServiceNow administrator for a large organization that uses a custom application to manage IT assets. The application has a business rule on the 'asset' table that runs 'after update' and logs changes to a separate audit table. Recently, users have reported that saving an asset record takes over 30 seconds, and the system performance has degraded. Upon investigation, you find that the business rule contains a GlideRecord query that retrieves all related asset history records for each update, and then performs additional calculations. The asset table has over 500,000 records, and each asset has an average of 50 history records. The business rule is triggered on every field update, including minor changes like last modified date. You need to improve the response time without losing the audit functionality. Which course of action should you take?

A.Change the business rule to run 'before' update to perform the audit logging earlier in the process.

B.Add a condition to the business rule so that it only executes when specific important fields (e.g., status, assigned to) are changed.

C.Delete the business rule and implement the audit logic using a script include called from a UI policy.

D.Change the business rule to run asynchronously by selecting 'Run asynchronously' in the advanced view.

AnswerB

This reduces the number of times the resource-intensive code runs, improving performance while still logging critical changes.

Why this answer

Adding a condition to limit execution to only significant changes (e.g., important fields) reduces the frequency of the heavy operation. Option A is not valid because before business rules cannot write to a different table after the operation; they would need to use a separate script. Option C is incorrect because implementing the audit logic using a script include called from a UI policy is not suitable; UI policies are client-side and cannot perform server-side operations like writing to an audit table.

Option D might cause delays if asynchronous execution is not properly configured, and it still runs the same operation; additionally, asynchronous business rules can lead to data consistency issues.

Practice this question →

21

Multi-Selectmedium

A business rule on the Incident table should send an email notification when the state changes to 'Resolved'. Which two conditions should be checked in the business rule script? (Choose two.)

Select 2 answers

A.current.state == 'Resolved'

B.current.state.changesTo('Resolved')

C.current.state.changesTo('Resolved') && current.operation() == 'update'

D.current.state.changes()

E.current.state.changesFrom() != 'Resolved'

AnswersB, C

Correct; this specifically checks if state changes to Resolved.

Why this answer

The `changesTo()` method in GlideRecord checks if the specified field has changed to a specific value during the current transaction. This is the precise way to detect a state transition to 'Resolved'. Option C is also correct because it adds the `current.operation() == 'update'` condition, which ensures the business rule only fires on update operations, preventing false triggers on insert or delete.

Together, these two conditions guarantee the email is sent only when an existing record's state is updated to 'Resolved'.

Exam trap

The trap here is that candidates often pick only option B, forgetting that `changesTo()` can return true on insert if the field is set to that value, so the additional `current.operation() == 'update'` condition is necessary to restrict the rule to updates only, which is the intended behavior for a state transition notification.

Practice this question →

22

MCQmedium

A company has a business rule that runs after a record is inserted on the Change Request table. The rule creates a related task record. Recently, the rule stopped working for some users. The developer discovers that the rule fails silently when the logged-in user lacks the 'change_request.create' role. What is the best way to fix this?

A.Set the rule to run as the system user

B.Use gs.hasRole('change_request.create') to check and abort if false

C.Move the script to a script action that runs in the background

D.Use current.setAbortAction(false) to ignore the error

AnswerA

Running as the system user grants full rights and avoids role checks.

Why this answer

Setting the business rule to run as the system user bypasses role-based restrictions. Option A would prevent execution. Option C does not handle the error.

Option D is unnecessary.

Practice this question →

23

MCQeasy

A developer needs to create a business rule that automatically sets the 'assignment_group' of an incident to 'Service Desk' when the 'category' is 'Network' and the 'subcategory' is 'VPN'. Which condition type should be used to ensure the rule only runs when both conditions are met?

A.Use the 'Condition' field on the business rule to specify the condition.

B.Select the 'Advanced' checkbox and write the condition in the 'Condition' field.

C.Set a filter on the 'When to run' tab to match the category and subcategory.

D.Write the condition in the script field using an if statement and no condition in the Condition field.

AnswerA

The Condition field is designed for exactly this purpose, using boolean logic on field values.

Why this answer

The 'Condition' field on a business rule is the standard place to define the filter that determines when the rule executes. By entering 'category=="Network"^subcategory=="VPN"' in the Condition field, the rule will only run when both conditions are true, without needing advanced scripting. This is the simplest and most efficient approach for a straightforward condition check.

Exam trap

The trap here is that candidates often confuse the 'Condition' field with the 'Advanced' checkbox, thinking they must always check 'Advanced' to write any condition, when in fact the standard Condition field supports simple AND/OR logic without scripting.

How to eliminate wrong answers

Option B is wrong because selecting the 'Advanced' checkbox is only necessary when you need to write complex script logic in the 'Condition' field (e.g., using GlideRecord queries or multiple conditions with OR/AND logic that cannot be expressed in the simple condition syntax). For a simple AND condition like this, the standard Condition field suffices. Option C is wrong because the 'When to run' tab controls the trigger timing (e.g., before/after insert, update, delete) and does not have a filter field for condition logic; conditions are not set there.

Option D is wrong because writing the condition only in the script field with an if statement and leaving the Condition field empty will cause the business rule to run on every trigger event (e.g., every insert or update), which is inefficient and may lead to unintended side effects; the Condition field should always be used to filter execution.

Practice this question →

24

MCQeasy

A developer is creating a business rule that should run after a record is inserted or updated. The script should fire on both insert and update. Which condition should be used?

A.current.operation().indexOf('insert') != -1

B.current.operation() == 'insert' || current.operation() == 'update'

C.current.operation() in ['insert','update']

D.current.operation() in ['insert','update','delete']

AnswerC

This is the recommended way to check multiple operations.

Why this answer

The `in` operator checks if `current.operation()` matches any value in the list `['insert','update']`, which is the exact requirement for a business rule that should fire on both insert and update. This is the most concise and idiomatic way in ServiceNow to test for multiple operation types.

Exam trap

The trap here is that candidates often choose Option B because it explicitly lists both conditions, not realizing that the `in` operator is the preferred and more concise syntax in ServiceNow, or they pick Option D because they forget to exclude 'delete' from the list.

How to eliminate wrong answers

Option A is wrong because `current.operation().indexOf('insert') != -1` would incorrectly match any operation string containing 'insert', such as 'inserting' or 'inserted', and is not a reliable or standard way to check the operation type. Option B is wrong because while the logic is correct, it is unnecessarily verbose and less readable compared to the `in` operator; however, it would technically work, but the question asks for the condition that should be used, implying the best practice. Option D is wrong because it includes 'delete', which would cause the business rule to also fire on delete operations, violating the requirement to fire only on insert and update.

Practice this question →

25

MCQmedium

A ServiceNow developer needs to implement a business rule that automatically sets the 'state' field to 'In Progress' when a user is assigned to an incident. The rule should run only when the 'assigned_to' field changes, and should not run on any other updates. Which condition type and condition script should be used?

A.Condition type: 'when to run' set to 'on update' with condition 'current.assigned_to.changes()'

B.Condition type: 'when to run' set to 'on update' with condition 'current.assigned_to.changes() || current.state.changes()'

C.Condition type: 'when to run' set to 'on insert or update' with condition 'current.assigned_to.changes()'

D.Condition type: 'advanced' with condition script 'current.assigned_to.changes()' and run on 'update'

AnswerA

Correct: condition type 'when to run' with 'on update' and the condition script 'current.assigned_to.changes()' ensures it only runs on update when assigned_to changes.

Why this answer

The 'when to run' condition type set to 'on update' with the condition 'current.assigned_to.changes()' ensures the business rule triggers only when the 'assigned_to' field is updated, and not on insert or other field changes. The 'changes()' method returns true only when the specified field has been modified during the current transaction, which precisely meets the requirement.

Exam trap

The trap here is that candidates often confuse 'changes()' with 'changed()' (which is not a valid method) or incorrectly assume that 'on update' alone without a field condition will run on any update, leading them to add unnecessary conditions like 'current.state.changes()' or choose the 'advanced' option.

How to eliminate wrong answers

Option B is wrong because it adds '|| current.state.changes()', which would cause the rule to also run when the 'state' field changes, violating the requirement to run only on 'assigned_to' changes. Option C is wrong because 'on insert or update' would trigger the rule on record creation, which is not allowed since the requirement specifies the rule should run only on updates. Option D is wrong because the 'advanced' condition type with a condition script is unnecessary; the simple 'when to run' condition with 'current.assigned_to.changes()' is sufficient and more efficient, and the 'run on update' is redundant when the condition type already specifies 'on update'.

Practice this question →

26

MCQhard

A business rule on the Task table uses 'current.assignment_group' in a condition. After cloning the application, the business rule fails with 'undefined' error for the assignment_group field. What is the most likely cause?

A.The assignment_group field does not exist on the Task table.

B.The script include that defines the field is missing.

C.The clone process incorrectly copies business rules.

D.The field was renamed in the cloned instance.

AnswerD

Correct; renaming would break the reference.

Why this answer

Cloning an application copies the business rule as-is, but if the assignment_group field was renamed in the cloned instance (e.g., from 'assignment_group' to 'assignment_group_new'), the condition referencing 'current.assignment_group' will fail with an 'undefined' error. The business rule still runs, but the field name no longer matches the database column, causing the script to reference a non-existent property on the GlideRecord object.

Exam trap

The trap here is that candidates often assume the clone process is faulty (Option C) or that the field is missing entirely (Option A), rather than recognizing that a renamed field causes a mismatch between the script's hardcoded field name and the actual database column name.

How to eliminate wrong answers

Option A is wrong because the assignment_group field does exist on the Task table by default in ServiceNow; if it were missing, the error would occur in the source instance as well, not just after cloning. Option B is wrong because assignment_group is a database column, not a script include; script includes define reusable server-side code, not field definitions. Option C is wrong because the clone process does copy business rules correctly; the issue is not with the copying mechanism but with the target instance's schema being different from the source.

Practice this question →

27

Multi-Selectmedium

Which THREE factors should be considered when designing a Business Rule for optimal performance? (Select THREE)

Select 3 answers

A.Avoid using synchronous GlideAjax calls.

B.Limit the use of gs.log() statements in production.

C.Use GlideAggregate instead of GlideRecord for calculations.

D.Use 'current' and 'previous' instead of querying the database.

E.Set the Business Rule to run on 'before' if possible.

AnswersB, C, D

Logging can impact performance.

Why this answer

Excessive gs.log() statements in production can degrade performance by writing to the system log, which consumes I/O resources and can fill up the database. In ServiceNow, logging should be minimized or removed in production scripts to avoid unnecessary overhead, especially in high-volume Business Rules.

Exam trap

The trap here is that candidates may confuse client-side performance concerns (like synchronous GlideAjax) with server-side Business Rule optimization, or assume that running a rule 'before' always improves performance without considering the specific logic and context.

Practice this question →

28

Multi-Selecteasy

Which TWO of the following are valid ways to trigger a business rule? (Choose two.)

Select 2 answers

A.Form load

B.Insert

C.Timer event

D.Update

E.Inbound email receipt

AnswersB, D

Business rules can run on insert.

Why this answer

Business rules in ServiceNow can be triggered by database operations such as Insert and Update. These are the core 'when to run' conditions that fire the rule before or after a record is created or modified in the database. Options B and D are correct because they directly correspond to these fundamental database operations.

Exam trap

The trap here is that candidates confuse client-side events (like form load) or other system actions (like inbound email) with the actual database operation triggers that business rules use, leading them to select options that are not valid server-side triggers.

Practice this question →

29

Multi-Selectmedium

Which THREE of the following are best practices when writing business rules? (Choose three.)

Select 3 answers

A.Set the Order field to control execution sequence

B.Use condition scripts to keep scripts clean

C.Use gs.sleep() to wait for other processes

D.Avoid long-running synchronous business rules

E.Use GlideAggregate for updating records

AnswersA, B, D

Order ensures business rules run in the desired sequence.

Why this answer

Setting the Order field on a business rule controls the sequence in which multiple business rules execute on the same table and event. This is critical when rules have dependencies, ensuring that prerequisite logic (e.g., data validation) runs before subsequent logic (e.g., field updates). Without explicit ordering, execution order is undefined and may vary between instances.

Exam trap

The trap here is that candidates confuse GlideAggregate with GlideRecord and assume it can perform updates, or they think gs.sleep() is a harmless delay when it actually blocks the entire script execution thread.

Practice this question →

30

MCQhard

A Business Rule uses 'current.setAbortAction(true)' to stop a record from being saved. However, the record is still saved under certain conditions. Which scenario could cause this?

A.The Business Rule runs after the database operation.

B.The Business Rule is on a table that is extended from a table with a higher order Business Rule.

C.Another Business Rule runs in the same order but sets abort to false.

D.The Business Rule has a condition that is not met.

AnswerA

After rules cannot abort the operation.

Why this answer

`current.setAbortAction(true)` must be called in a Business Rule that runs before the database operation (e.g., 'before' or 'before query' order). If the Business Rule runs 'after' the database operation, the record has already been committed to the database, so aborting the action has no effect on the save. The abort flag only prevents the pending database write; once the write is complete, the flag is irrelevant.

Exam trap

The trap here is that candidates assume `setAbortAction(true)` works regardless of when the Business Rule runs, but the platform only honors the abort flag in 'before' or 'before query' scripts, not in 'after' scripts.

How to eliminate wrong answers

Option B is wrong because a Business Rule on an extended table with a higher order rule does not inherently cause `setAbortAction(true)` to be ignored; order values determine execution sequence, but the abort flag still works if the rule runs before the database operation. Option C is wrong because `setAbortAction(false)` does not override a previous `setAbortAction(true)` in the same transaction; once abort is set to true, it remains true for the current operation, and no other script can reset it to false. Option D is wrong because if the condition is not met, the Business Rule does not execute at all, so `setAbortAction(true)` is never called, and the record saves normally—this is expected behavior, not a scenario where the abort is ignored despite being called.

Practice this question →

31

MCQhard

A developer creates a business rule on the Incident table that executes a GlideRecord query to update related records. The rule runs on 'after' update and queries the Problem table to set a field. However, the update is not being committed. What is the most likely reason?

A.The developer forgot to use gr.insert() instead of gr.update().

B.The GlideRecord query requires an explicit gr.updateMultiple() or gr.commit() to persist changes.

C.After business rules cannot update other tables.

D.The query returns more than 100 records, causing a governor limit.

AnswerB

When updating multiple records, gr.updateMultiple() is needed to commit all changes at once.

Why this answer

In ServiceNow, when a GlideRecord query is used in an 'after' business rule to update records on another table, the changes are not automatically committed. The developer must explicitly call gr.updateMultiple() to persist updates to multiple records, or gr.update() for a single record. Option B correctly identifies this requirement, as the update is not being committed without an explicit method call.

Exam trap

The trap here is that candidates assume GlideRecord updates are automatically committed in any context, but ServiceNow requires explicit update calls in 'after' business rules for cross-table modifications, unlike 'before' rules where changes to the current record are auto-saved.

How to eliminate wrong answers

Option A is wrong because gr.insert() is used to create new records, not update existing ones; the issue here is about updating, not inserting. Option C is wrong because 'after' business rules can indeed update records on other tables; there is no restriction that prevents cross-table updates. Option D is wrong because while governor limits exist (e.g., 10,000 records per query), the problem states the update is not being committed, not that it fails due to a limit; the most likely cause is the missing explicit update call.

Practice this question →

32

MCQeasy

To debug a Business Rule that runs on update, which technique is most efficient?

A.Add a breakpoint in the script.

B.Use the Business Rule debug tool.

C.Use the debugger in Studio.

D.Insert a gs.log() message.

AnswerB

Built-in tool specifically for debugging Business Rules.

Why this answer

The Business Rule debug tool provides a dedicated interface for stepping through business rule execution, inspecting variable values, and identifying issues without modifying code. Options A, C, and D are less efficient: A (breakpoint) and C (Studio debugger) require more setup and are not as streamlined for business rules, while D (gs.log()) requires scrolling through logs and does not offer interactive debugging.

Practice this question →

33

MCQeasy

A developer is tasked with writing a business rule that should only execute when the record is being updated and the value of the 'state' field changes from 'In Progress' to 'Resolved'. Which condition should be used in the business rule?

A.current.operation() == 'update' && previous.state == 'In Progress' && current.state == 'Resolved'

B.current.operation() == 'update' && current.state.changesFrom('In Progress') && current.state.changesTo('Resolved')

C.current.operation() == 'update' && current.state.changes() && current.state == 'Resolved'

D.current.operation() == 'update' && current.state == 'Resolved' && previous.state == 'In Progress'

AnswerB

These methods are specifically designed for checking field value transitions.

Why this answer

The changesFrom() and changesTo() methods are the recommended approach for checking field transitions. Options A and D use direct comparison but are less efficient. Option C only checks that state changed, not the specific transition.

Practice this question →

34

MCQmedium

A developer writes a Business Rule to calculate a total on an Aggregate field. The rule runs on 'insert' and 'update' on the parent table. However, the total is not updating correctly when child records are deleted. Why?

A.The Business Rule should use 'current' and 'previous' to detect deletion.

B.The Business Rule should be on the child table's delete event.

C.The Business Rule should also run on 'delete'.

D.The Business Rule should be a Global Business Rule.

AnswerB

Child delete triggers need separate rule on child table.

Why this answer

A Business Rule that runs on 'insert' and 'update' on the parent table will not fire when a child record is deleted, because the delete event occurs on the child table, not the parent. To correctly update an aggregate field on the parent when child records are deleted, the Business Rule must be defined on the child table's 'delete' event. This ensures the rule executes when the child record is removed, allowing the aggregate to be recalculated.

Exam trap

The trap here is that candidates assume a Business Rule on the parent table with a 'delete' event will catch child deletions, but in ServiceNow, the delete event only fires on the table where the record is actually deleted, not on related parent records.

How to eliminate wrong answers

Option A is wrong because 'current' and 'previous' are used to compare field values within the same record, not to detect deletion events on a different table; they cannot trigger a rule on the parent when a child is deleted. Option C is wrong because adding 'delete' to the parent table's Business Rule still does not fire when a child record is deleted—the delete event must be on the child table itself. Option D is wrong because making the rule Global does not change the event trigger; a Global Business Rule still requires the correct table and event (child table delete) to execute.

Practice this question →

35

MCQhard

A business rule on the Incident table runs 'after' update and calls a script include that modifies the current record. However, changes made by the script include are not saved. What is the reason?

A.The script include uses current.update() which triggers the same business rule recursively.

B.The business rule condition uses current.operation() incorrectly.

C.The script include uses gs.sleep(1000) and times out.

D.The business rule is set to 'after' and cannot modify the current record.

AnswerD

Correct; after rules cannot update the current record.

Why this answer

Business rules set to run 'after' the database operation cannot modify the current record directly; any changes made to the current record in an 'after' business rule are not saved to the database. The script include may alter the record in memory, but since the database write has already occurred, those changes are discarded unless a separate database operation (like current.update()) is explicitly called.

Exam trap

The trap here is that candidates often assume any business rule can modify the current record, overlooking the fundamental difference between 'before' and 'after' execution phases in ServiceNow.

How to eliminate wrong answers

Option A is wrong because current.update() in a script include called from an 'after' business rule would trigger the business rule again, but the issue is that changes are not saved, not that they cause recursion. Option B is wrong because current.operation() is used to check the operation type (e.g., 'insert', 'update'), and an incorrect condition would prevent the rule from running, not cause unsaved changes. Option C is wrong because gs.sleep(1000) would delay execution but not prevent changes from being saved; a timeout would cause an error, not silent failure to save.

Practice this question →

36

Multi-Selectmedium

A developer wants to use a script include to reuse logic across multiple business rules. Which two considerations should be made? (Choose two.)

Select 2 answers

A.Script includes cannot call other script includes.

B.Script includes should not have side effects on current record.

C.Script includes must be global to be accessible from all scopes.

D.Script includes can be scoped and still accessible from business rules in the same scope.

E.Script includes are automatically evaluated at server start.

AnswersB, D

Correct because script includes should not have side effects on current record to maintain reusability.

Why this answer

Options B and D are correct. B: Script includes should not have side effects on current record to maintain reusability. D: Script includes can be scoped and still accessible from business rules in the same scope.

A is incorrect because script includes can call other script includes. C is incorrect because script includes do not need to be global; they can be scoped. E is incorrect because they are not auto-evaluated.

Practice this question →

37

MCQeasy

A developer writes a business rule that runs on after update. The script intends to send an email notification when the priority changes. Which method should be used to compare the previous and current values?

A.current.getDisplayValue('priority') != previous.getDisplayValue('priority')

B.current.priority.changes()

C.current.changes()

D.previous.priority != current.priority

AnswerB

This method returns true exactly when the priority field changes.

Why this answer

The changes() method on a field object returns true if the field changed. Option B is correct. Option A checks if any field changed.

Option C uses direct comparison but is not a method. Option D uses getDisplayValue which compares labels, not values.

Practice this question →

38

MCQhard

Refer to the exhibit. A Business Rule in the same scope calls this script include using 'var total = new MyUtils().getTotal("invoice", "state=paid");' but gets '0' even though there are records. What is the most likely cause?

A.The getTotal method is not properly defined.

B.The 'amount' field is not numeric in the invoice table.

C.The GlideAggregate query syntax is incorrect.

D.The script include is not accessible from the Business Rule's scope.

AnswerB

Non-numeric field causes SUM to return null.

Why this answer

The Business Rule calls `getTotal` which uses `GlideAggregate` to sum the `amount` field. If the `amount` field is not numeric (e.g., it is a string or another non-numeric type), `GlideAggregate.addAggregate('SUM', 'amount')` will return `0` because it cannot perform a numeric aggregation on non-numeric data. This matches option B.

Exam trap

ServiceNow often tests the misconception that a GlideAggregate query syntax error is the cause, when the real issue is a non-numeric field type that prevents aggregation from returning a valid sum.

How to eliminate wrong answers

Option A is wrong because the script include is called successfully (no error), so the method is properly defined. Option C is wrong because the GlideAggregate query syntax is correct: `addQuery('state', 'paid')` and `addAggregate('SUM', 'amount')` are standard methods. Option D is wrong because the Business Rule and script include are in the same scope, so accessibility is not an issue.

Practice this question →

39

MCQeasy

Which scripting environment should be used to write a Business Rule that runs on schedule?

A.Business Rule

B.Events

C.Script Include

D.Scheduled Job

AnswerD

Scheduled Jobs run at defined intervals.

Why this answer

A Scheduled Job is the correct scripting environment for running a Business Rule on a schedule because Business Rules in ServiceNow are event-driven and execute only when a record is inserted, updated, deleted, or queried. To run logic at a specific time or interval, you must use a Scheduled Job, which leverages the system's job scheduler (based on Quartz) to execute a script at defined intervals or cron expressions.

Exam trap

The trap here is that candidates confuse the 'Business Rule' name with the ability to run on a schedule, but ServiceNow explicitly separates event-driven logic (Business Rules) from time-based logic (Scheduled Jobs), and the exam tests this distinction.

How to eliminate wrong answers

Option A is wrong because a Business Rule runs only in response to database operations (insert, update, delete, query) on a table, not on a time-based schedule. Option B is wrong because Events are used to trigger notifications, scripts, or other actions in response to a condition, but they themselves do not run on a schedule; they are fired by other processes. Option C is wrong because a Script Include is a reusable server-side script library that must be called from another script (e.g., a Business Rule or Scheduled Job) and cannot run autonomously on a schedule.

Practice this question →

40

Drag & Dropmedium

Drag and drop the steps to create a Client Script 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

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order: navigate, create new, set table and name, choose UI type and trigger, then write script and submit.

Practice this question →

41

MCQhard

A senior developer has created a complex business rule called 'Asset Assignment' on the 'alm_asset' table that runs after insert. The rule queries the 'User' table to find a manager and assigns the asset to that manager's department via a GlideRecord update. The rule has an order of 100. Another business rule called 'Asset Log' on the same table also runs after insert with an order of 200, which logs the assignment in a separate table. After deploying to production, the 'Asset Log' rule executes but the assignment update from 'Asset Assignment' fails silently. The developer discovers that the 'Asset Assignment' rule has a condition script that references a new field that was not added to the 'alm_asset' table in production. The field exists in the developer's instance but not in production. The developer wants to minimize disruption and fix the issue quickly. Which action should the developer take? A. Change the condition script to check if the field exists before using it, and if not, exit the script gracefully. B. Reorder the business rules so that 'Asset Log' runs first and 'Asset Assignment' runs second, and add a condition to 'Asset Log' to only run if the assignment succeeded. C. Remove the condition from 'Asset Assignment' and move the field existence check into the script, setting the field value only if it exists. D. Deactivate the 'Asset Assignment' business rule until the field is added to the table in production, then reactivate it after the next maintenance window.

A.Reorder the business rules so that 'Asset Log' runs first and 'Asset Assignment' runs second, and add a condition to 'Asset Log' to only run if the assignment succeeded.

B.Remove the condition from 'Asset Assignment' and move the field existence check into the script, setting the field value only if it exists.

C.Deactivate the 'Asset Assignment' business rule until the field is added to the table in production, then reactivate it after the next maintenance window.

D.Change the condition script to check if the field exists before using it, and if not, exit the script gracefully.

AnswerD

This prevents the rule from failing when the field is missing and will work once the field is added.

Why this answer

It is the quickest fix with minimal disruption: by checking if the field exists in the condition script, the business rule gracefully exits without error when the field is missing, and once the field is added, the condition will pass and the rule will run as intended. Option A is incorrect because reordering does not address the root cause; the 'Asset Assignment' rule would still fail due to the missing field. Option B is incorrect because moving the check into the script (instead of the condition) would not prevent the condition script from referencing the missing field; the condition script would still error.

Option C is incorrect because deactivating the rule prevents the intended functionality entirely until the field is added, which is more disruptive than a simple condition check.

Practice this question →

42

MCQhard

The business rule has an empty script. What will happen when an incident state changes to 'Resolved'?

A.The business rule will not fire because condition is invalid.

B.Nothing, because there is no script.

C.The business rule will cause an error because script is required.

D.The business rule will still fire and execute default actions.

AnswerB

Correct; the rule fires but does nothing.

Why this answer

The business rule will fire because the condition (incident state changes to 'Resolved') is valid. However, since the script is empty, nothing happens. No default actions are executed.

Option A is wrong because the condition is not invalid; it is valid. Option C is wrong because a script is not required for a business rule to fire. Option D is wrong because there are no default actions; the business rule only runs the script, which is empty.

Practice this question →

43

MCQmedium

A company has a business rule that runs on update of the Incident table. The rule sets the caller_id field to the sys_id of the user who last modified the record. However, the rule does not fire when an update is made via web services. What is the most likely cause?

A.The business rule's 'When' field is set to 'UI action only' which excludes web service updates.

B.The business rule is inactive.

C.Business rules never run when updates are made via web services.

D.The business rule's condition is 'current.operation() == 'update'' but the web service uses a different operation.

AnswerA

This is correct because the 'UI action only' setting limits the rule to UI-triggered updates.

Why this answer

When the 'When' field of a business rule is set to 'UI action only', the rule only triggers on UI actions and not on web service updates. Option B is incorrect because if the business rule were inactive, it would never fire at all, but the question states it doesn't fire only when updated via web services, so it must be active. Option C is incorrect because business rules do run on web service updates unless specifically excluded.

Option D is incorrect because the condition 'current.operation() == 'update'' would still be true for web service updates since web services use the update operation.

Practice this question →

44

MCQhard

A mid-sized company heavily relies on ServiceNow for incident management. They have a business rule that runs before insert on the Incident table. The rule dynamically sets the assignment group based on the category of the incident and the location of the caller. To determine the correct group, the script performs a GlideRecord query against a custom table called "u_group_mapping", which contains approximately 5000 records mapping category-location pairs to groups. During peak business hours, when many incidents are created simultaneously, the business rule causes significant delays and occasional timeouts, impacting user experience. The development team has been tasked with optimizing this business rule without changing its functionality. The current script structure is roughly: (function executeRule(current, previous) { var gr = new GlideRecord('u_group_mapping'); gr.addQuery('category', current.category); gr.addQuery('location', current.caller_id.location); gr.query(); if (gr.next()) { current.assignment_group = gr.assignment_group; } })(current, previous); The team wants to reduce the database access overhead. Which optimization technique should the developer implement?

A.Use GlideAggregate to retrieve the count of matching groups

B.Store the mapping in a global script include variable that persists across sessions

C.Create a script include with a static variable to cache the mapping for the duration of the current transaction

D.Move the business rule to run after insert so it does not block the insert

AnswerC

This caches the query results within the same request, reducing database calls.

Why this answer

Caching the mapping data in a static variable within a script include ensures that the GlideRecord query against the 5000-record custom table is executed only once per transaction, rather than on every incident creation. This drastically reduces database access overhead during peak hours, as subsequent invocations of the business rule within the same transaction reuse the cached results, eliminating redundant queries and preventing timeouts.

Exam trap

The trap here is that candidates often confuse caching across sessions (Option B) with caching within a transaction (Option C), mistakenly thinking a global variable is more efficient, but ServiceNow’s architecture requires transaction-scoped caching to avoid stale data and concurrency conflicts.

How to eliminate wrong answers

Option A is wrong because using GlideAggregate to count matching groups does not retrieve the actual assignment group value; it only returns a count, which is useless for setting the assignment group and still requires a separate query to fetch the group. Option B is wrong because storing the mapping in a global script include variable that persists across sessions would introduce concurrency issues and stale data, as the mapping could change between sessions and the variable would not be automatically refreshed, leading to incorrect assignments. Option D is wrong because moving the business rule to run after insert does not reduce database access overhead; it merely shifts the timing, and the same GlideRecord query would still execute, potentially causing delays in post-insert processing and still impacting user experience if the insert itself is blocked by synchronous operations.

Practice this question →

45

MCQmedium

A ServiceNow administrator notices that a business rule designed to update the 'short_description' field on the 'incident' table is not executing when a user changes the field via a custom UI page that uses GlideRecord. The script in the business rule uses current.setValue() and current.update(). What is the most likely cause?

A.The 'short_description' field is read-only on the form.

B.The business rule is updating itself recursively and has been disabled.

C.The business rule is set to run on the server, but the custom UI page uses client-side GlideRecord which does not trigger server-side business rules.

D.The 'short_description' field is not in the business rule's 'Fields to update' list.

AnswerC

Client-side GlideRecord operations do not invoke server-side business rules; they go directly to the database without triggering 'after' update logic.

Why this answer

Client-side GlideRecord (g_form.getReference or direct GlideRecord in a UI page) runs entirely in the browser and does not trigger server-side business rules. Business rules execute only when a record is saved via server-side operations (e.g., form submit, web service, or server-side script). Since the custom UI page uses client-side GlideRecord, the update bypasses the business rule engine entirely.

Exam trap

The trap here is that candidates often assume any GlideRecord call triggers business rules, but client-side GlideRecord bypasses server-side execution, and the exam tests this specific distinction between client-side and server-side script execution contexts.

How to eliminate wrong answers

Option A is wrong because a read-only field on the form only prevents user input on that form; it does not prevent a business rule from updating the field via current.setValue() and current.update(). Option B is wrong because if the business rule were updating itself recursively, it would cause a loop and potentially be disabled by the system, but the question states the rule is not executing at all, not that it was disabled due to recursion. Option D is wrong because the 'Fields to update' list is not a property of business rules; business rules do not have a 'Fields to update' list—that concept applies to dictionary overrides or field-level security, not business rule execution.

Practice this question →

46

MCQeasy

What is the effect of this business rule?

A.It will cause an error because assignment_group is a reference field.

B.It only runs when both caller and short description change.

C.It sets assignment_group to 'IT Support' every time the caller or short description changes.

D.It only sets assignment_group when the incident is first created.

AnswerC

Correct; the condition OR means either change triggers the script.

Why this answer

The business rule is configured to trigger 'on change' for both the 'caller' and 'short description' fields. When either field changes, the rule sets the 'assignment_group' field to 'IT Support'. This is a typical use of a business rule to automatically assign incidents based on field updates.

Exam trap

The trap here is that candidates often confuse the condition logic (thinking 'changes to caller OR short description' means both must change) or assume reference fields cannot be set by business rules, leading them to pick option A or B.

How to eliminate wrong answers

Option A is wrong because assignment_group is a reference field, but business rules can set reference fields by specifying a sys_id or a name that resolves to a valid record; no error occurs as long as the value exists. Option B is wrong because the condition uses OR logic (either field changes), not AND; the rule runs when caller OR short description changes, not only when both change. Option D is wrong because the rule is not restricted to the 'on insert' event; it runs on updates as well, so it sets assignment_group whenever the specified fields change, not just on creation.

Practice this question →

47

MCQeasy

Which script function is used to query the database in a business rule?

A.GlideRecord.query();

B.new GlideRecord('table').query();

C.gs.query();

D.GlideRecord.newQuery();

AnswerB

Correct; this creates a GlideRecord object and queries the table.

Why this answer

In ServiceNow, a business rule must instantiate a new GlideRecord object using the 'new' keyword and then call the query() method on that instance to retrieve records from the database. The syntax 'new GlideRecord('table').query()' properly creates a GlideRecord object for the specified table and executes the query to fetch matching records.

Exam trap

ServiceNow often tests the distinction between static class references and instance methods, so the trap here is that candidates mistakenly think 'GlideRecord.query()' is valid because they confuse it with other static utility classes like 'GlideSystem' or 'GlideAggregate', forgetting that GlideRecord requires instantiation with 'new'.

How to eliminate wrong answers

Option A is wrong because 'GlideRecord.query()' is a static call on the class itself, not on an instance; GlideRecord is not a static utility class and query() must be called on an instantiated object. Option C is wrong because 'gs.query()' is not a valid function; the 'gs' object (GlideSystem) provides methods like gs.getUser() or gs.log(), but does not have a query() method for database operations. Option D is wrong because 'GlideRecord.newQuery()' is not a valid method; GlideRecord has no static 'newQuery' method, and the correct approach is to use 'new GlideRecord()' followed by '.query()'.

Practice this question →

48

Multi-Selecthard

Which three actions require a business rule to be set to 'before' to work correctly? (Choose three.)

Select 3 answers

A.Sending an email notification

B.Deleting a record related to the current record

C.Setting a default value on a new record

D.Updating a field on the current record

E.Aborting the current transaction

AnswersC, D, E

Correct; defaults must be set before the record is saved.

Why this answer

Options C, D, and E are correct. C: Setting a default value on a new record must occur before the record is saved to the database. D: Updating a field on the current record must be done before the record is saved, because after save the record is already stored.

E: Aborting the current transaction must happen before the database write; in an after business rule, the transaction has already been committed. Options A (sending an email notification) and B (deleting a related record) can be performed in after business rules because they do not require modifying the record before it is saved.

Practice this question →

49

MCQhard

A script include has a function that uses the 'GlideRecordSecure' class. When called from a Business Rule in a different scope, it throws a security exception. What is the most likely cause?

A.The script include does not have the 'Accessible from' property set to all scopes.

B.The function is not defined as a static function.

C.The GlideRecordSecure class is not accessible from other scopes.

D.The script include is not marked as public.

AnswerA

Must be set to 'All scopes' or specific scope.

Why this answer

The 'Accessible from' property on a Script Include controls which scopes can invoke its functions. When this property is not set to 'All scopes', a Business Rule in a different scope cannot call the Script Include, resulting in a security exception. The GlideRecordSecure class itself is accessible across scopes, but the Script Include's access restriction prevents the call.

Exam trap

ServiceNow often tests the misconception that GlideRecordSecure is the cause of cross-scope access issues, when in fact the Script Include's 'Accessible from' property is the primary gatekeeper for cross-scope invocation.

How to eliminate wrong answers

Option B is wrong because static functions are not required for cross-scope access; the 'Accessible from' property is the key control. Option C is wrong because the GlideRecordSecure class is accessible from other scopes by default; the issue is the Script Include's access restriction, not the class. Option D is wrong because marking a Script Include as 'public' (via the 'Accessible from' property) is exactly what is missing; the term 'public' in this context refers to the 'Accessible from' setting, not a separate flag.

Practice this question →

50

MCQmedium

Refer to the exhibit. The business rule is intended to update the CI's operational status when an incident is resolved. However, the CI is not being updated. What is the most likely reason?

A.The business rule runs after the record is saved, so changes to the CI are not saved

B.The script does not include a condition to check if the CI belongs to the cmdb_ci_server table

C.The business rule runs synchronously, so it cannot update another record

D.The script uses gr.update() without checking if the CI record exists

AnswerB

If the CI is not a server, the GlideRecord may fail to find it.

Why this answer

The script uses `gr.get('cmdb_ci_server', current.cmdb_ci)` which only finds CI records of the 'cmdb_ci_server' table. If the CI belongs to a different class (e.g., 'cmdb_ci_router'), the query returns no record, so the update never occurs. Option B is correct because the script lacks a condition to verify the CI's table class.

Option A is incorrect because business rules running after save can still update other records. Option C is false since synchronous rules can update other records. Option D is not the root cause; the `gr.update()` is present, but the problem is that the record is not found.

Practice this question →

51

MCQmedium

A developer needs to create a script that runs before a record is inserted, to set a default value. Which business rule 'When' option is appropriate?

A.Before

B.Async

C.After

D.Display

AnswerA

Correct; before insert allows modifying the record before save.

Why this answer

(Before) is correct because 'Before' business rules run before the record is saved to the database, allowing default values to be set. Option B (Async) is incorrect because Asynchronous rules run later in a separate transaction. Option C (After) is incorrect because 'After' rules run after the record is already saved, so they cannot set default values before insert.

Option D (Display) is incorrect because 'Display' rules run when the form is loaded, not before insert.

Practice this question →

52

Multi-Selecthard

Which THREE statements are correct about script includes and their usage across scopes? (Select THREE)

Select 3 answers

A.A script include can be accessed from a Business Rule in a different scope if the script include is defined as a global script include.

B.Script includes defined as 'public' can be accessed from any scope without restriction.

C.A script include must be marked as 'public' to be accessible from other scopes.

D.To call a script include from another scope, you must use the global scope prefix.

E.The 'Accessible from' property can be set to 'All scopes' or specific scopes.

AnswersA, C, E

Global script includes are accessible.

Why this answer

Script includes in ServiceNow are isolated by scope by default. To make a script include accessible from a business rule in a different scope, it must be defined as a global script include (i.e., its scope is set to 'Global'). This allows the script include to be referenced and executed from any scope without requiring the global scope prefix.

Exam trap

The trap here is that candidates often confuse the 'public' access modifier from other programming languages with ServiceNow's 'Accessible from' property, leading them to select option B as correct.

Practice this question →

53

MCQhard

A large financial institution has a custom application for managing trade requests. The application uses a business rule on the 'Trade' table that calculates and sets the 'net_value' field based on 'quantity' and 'price'. Recently, traders have reported that when they update existing trades via a REST API integration, the 'net_value' field is not being recalculated. The business rule is set to run 'before' insert and 'before' update. The REST API uses GlideRecord to update the trade records. Upon investigation, the developer finds that the business rule script includes a check: 'if (current.changes('quantity') || current.changes('price')) { // recalculate }'. The script works correctly when updates are made from the UI. What is the most likely cause of the issue?

A.The business rule is set to run 'before' update, but the REST API triggers 'after' update.

B.The GlideRecord used in the REST API does not load the record's previous values, so changes() returns false.

C.The REST API sends the update request to a different instance, bypassing the business rule.

D.The condition 'current.changes('quantity') || current.changes('price')' is incorrectly formatted; it should use 'current.changes('quantity') || current.changes('price')'.

AnswerB

The changes() method relies on the previous values being loaded into the GlideRecord object. If the script creates a new GlideRecord and sets fields without first getting the record, or if the update is performed via a GlideRecord that hasn't been initialized with the old record, changes() may not detect changes.

Why this answer

The GlideRecord API used in REST API integrations does not automatically load the previous values of fields into the `changes()` method. When a record is updated via GlideRecord in a scripted REST API, the `current` object in the business rule does not have the 'previous' values populated, so `current.changes('quantity')` and `current.changes('price')` both return `false`. This causes the recalculation logic to be skipped, even though the business rule is set to run 'before update'.

In contrast, UI updates load previous values correctly, making `changes()` work as expected.

Exam trap

The trap here is that candidates assume `changes()` works universally in all update contexts, but ServiceNow specifically designed it to rely on the `previous` object, which is not populated in scripted REST API GlideRecord updates unless the record is explicitly loaded with `get()` before modification.

How to eliminate wrong answers

Option A is wrong because the business rule is set to run 'before update', and REST API updates still trigger 'before update' business rules; the issue is not about timing. Option C is wrong because REST API updates target the same instance where the business rule is defined; they do not bypass it unless explicitly routed elsewhere. Option D is wrong because the condition syntax is correct; the problem is not with the formatting of the condition but with the underlying data available to `changes()`.

Practice this question →

54

MCQmedium

A developer wants to trigger a Business Rule on a child table when a parent record is updated. How can this be achieved?

A.Use a workaround with a scheduled job.

B.Add a condition on the child table's Business Rule referencing the parent.

C.This is not possible in ServiceNow.

D.Use a before query Business Rule on the child table.

AnswerB

Condition can check parent field changes.

Why this answer

A Business Rule on the child table can include a condition that checks whether a related parent record has been updated. This is done by referencing the parent table's fields via dot-walking (e.g., `current.parent_field.changes()`) or by querying the parent record's sys_updated_on field. The Business Rule runs on the child table when a child record is inserted or updated, and the condition evaluates the parent's state, allowing the rule to trigger logic based on parent changes without requiring a direct trigger on the parent table.

Exam trap

The trap here is that candidates assume a Business Rule can only be triggered directly on the table being updated, overlooking the ability to use conditions on related table records to react to parent changes.

How to eliminate wrong answers

Option A is wrong because using a scheduled job is an inefficient workaround that introduces latency and complexity; it is not the intended or recommended approach for reacting to parent updates in real time. Option C is wrong because it is indeed possible to achieve this behavior using a condition on the child table's Business Rule, as described in the correct answer. Option D is wrong because a before query Business Rule runs during query operations (retrieval), not on updates, and cannot be used to trigger logic when a parent record is updated.

Practice this question →

55

MCQmedium

A company has a business rule that should update the 'priority' field on the Incident table whenever the 'impact' field is changed to 'High'. However, the business rule is not firing. The business rule is set to run 'before' insert/update, with condition 'current.impact.changes()'. The 'impact' field is of type 'choice' with values 'Low', 'Medium', 'High'. Which of the following is the most likely cause?

A.The business rule is set to run 'after' instead of 'before'.

B.The script uses 'gs.addErrorMessage()' which stops execution.

C.The business rule is inactive.

D.The condition 'current.impact.changes()' returns false on insert because the previous value is null.

AnswerD

On insert, the previous value is null, so 'changes()' returns false. The condition should be modified to handle both insert and update.

Why this answer

The condition `current.impact.changes()` checks if the field value has changed from a previous value. On an insert, the previous value is null, so the condition returns false even when the impact is set to 'High'. This prevents the business rule from firing on insert, which is a common pitfall when using `changes()` without also checking for the new value.

Exam trap

ServiceNow often tests the subtle difference between `changes()` and `changesTo()` in business rules, where candidates mistakenly assume `changes()` works on insert when it only detects changes from a prior value.

How to eliminate wrong answers

Option A is wrong because the business rule is set to run 'before', which is appropriate for updating a field on the same record; running 'after' would still allow the update but is not the cause of the rule not firing. Option B is wrong because `gs.addErrorMessage()` does not stop script execution; it only adds a message to the user interface and the script continues. Option C is wrong because if the business rule were inactive, it would never fire, but the question states the rule is not firing under specific conditions, implying it is active.

Practice this question →

56

MCQhard

A developer creates a business rule that runs before a record is inserted or updated on the Incident table. The rule sets the assignment group based on the category. However, after the rule runs, the assignment group is not being saved. What is the most likely cause?

A.The rule is a display business rule

B.The rule runs after the record is saved

C.The business rule is set to run on before update only

D.The script does not use current.setAbortAction(false)

AnswerB

After business rules require an explicit current.update() to save changes.

Why this answer

The most likely cause is that the business rule is configured to run 'after' the record is saved (option B), even though the developer intended it to run 'before'. In a 'before' business rule, changes to fields on the current record are automatically saved when the record is committed. However, in an 'after' business rule, the record is already saved, so modifications to current are not persisted unless the script explicitly calls current.update().

Option A describes a display business rule, which runs client-side and does not affect server-side saving. Option C is unlikely because if it ran on before update only, it would still run before save. Option D is incorrect because setAbortAction(false) is used in 'before' rules to allow the save to proceed, not to persist changes.

Practice this question →

57

MCQmedium

A developer needs to create a business rule that runs only when the 'State' field of an Incident changes from 'New' to 'In Progress'. Which condition script should be used?

A.current.state.changes() && current.state.changesFrom('New')

B.current.state == 'New' && current.state.changesTo('In Progress')

C.current.state.changes() && previous.state == 'New'

D.current.state.changesTo('In Progress')

AnswerA

This correctly checks that the state changed and the previous value was 'New'.

Why this answer

It uses both `current.state.changes()` to verify the field has changed and `current.state.changesFrom('New')` to ensure the previous value was 'New'. This combination precisely captures the transition from 'New' to any other state, which when combined with the business rule's 'when to run' condition (set to 'In Progress' in the rule's filter or script), ensures the rule fires only when the state changes from 'New' to 'In Progress'.

Exam trap

The trap here is that candidates often pick Option D thinking `changesTo('In Progress')` alone is sufficient, forgetting that it does not restrict the previous state, so the rule would fire for any transition into 'In Progress', not just from 'New'.

How to eliminate wrong answers

Option B is wrong because `current.state == 'New'` checks the current value, not the previous value; this would incorrectly fire when the state is currently 'New' and changes to 'In Progress', which is impossible since the state cannot be both 'New' and changing to 'In Progress' at the same time. Option C is wrong because `previous.state == 'New'` only checks the previous value but does not verify that the new value is 'In Progress'; the rule would fire for any state change from 'New' (e.g., to 'Resolved' or 'Canceled'). Option D is wrong because `current.state.changesTo('In Progress')` alone does not ensure the previous state was 'New'; the rule would fire if the state changes to 'In Progress' from any other state (e.g., from 'On Hold' or 'Assigned').

Practice this question →

58

MCQmedium

A ServiceNow instance has a business rule named 'Update CI Status' that runs on the 'Change Request' table after insert. The rule is intended to update the 'Configuration Item' record's 'Operational Status' to 'Under Maintenance' when a change request is created. The business rule uses the following script: (function executeRule(current, previous != null)) { var gr = new GlideRecord('cmdb_ci'); gr.get(current.cmdb_ci); gr.operational_status = 'Under Maintenance'; gr.update(); })(current, previous); After a recent upgrade to the Vancouver release, the business rule stopped working. The change request is created successfully, but the CI's operational status remains unchanged. The system logs show no errors. What is the most likely cause and the correct fix? A. The business rule is running asynchronously; change it to synchronous. B. The condition field is empty; add 'gs.action() === 'insert'' as the condition. C. The 'current.cmdb_ci' field is not populated; check that the field is required on the form. D. The script uses 'previous' incorrectly; remove 'previous != null' from the function signature.

A.The condition field is empty; add 'gs.action() === 'insert'' as the condition.

B.The business rule is running asynchronously; change it to synchronous.

C.The 'current.cmdb_ci' field is not populated; check that the field is required on the form.

D.The script uses 'previous' incorrectly; remove 'previous != null' from the function signature.

AnswerD

The script uses an invalid function signature with `previous != null`. Removing `!= null` corrects the syntax, allowing the script to run and update the CI.

Why this answer

The business rule contains a syntax error in the function signature. The correct format for a business rule script is `(function executeRule(current, previous))`. The script uses `(function executeRule(current, previous != null))` which is invalid JavaScript and prevents the script from executing.

Since the script never runs, no error appears in the logs, and the CI is not updated. Option A is incorrect because changing to synchronous does not fix a syntax error. Option B is incorrect because the condition field being empty means the rule runs, but the script still fails to execute.

Option C addresses a possible data issue, but the primary cause is the syntax error; even if `cmdb_ci` is populated, the script would still not run.

Practice this question →

59

MCQmedium

A company uses a business rule to set a field on the Incident table based on the caller's department. However, the rule runs correctly on insert but not on update. The developer suspects the condition is incorrect. The current script uses: if (current.operation() == 'insert' && gs.getUser().getDepartment() == 'IT'). What might be the issue?

A.The condition should check current.caller_id.department instead

B.The rule is set to run only on insert

C.The script uses synchronous business rule instead of asynchronous

D.The condition should use current.operation() == 'update' as well

AnswerA

The script should use current.caller_id.department to reference the caller's department.

Why this answer

The business rule should check the department of the caller associated with the incident record, not the logged-in user. The condition `current.caller_id.department` retrieves the department value from the caller's user record via a dot-walk to the sys_user table, ensuring the rule triggers based on the incident's caller, not the session user. The current script incorrectly uses `gs.getUser().getDepartment()`, which returns the department of the user running the update, which may differ from the caller's department, causing the rule to fail on update.

Exam trap

The trap here is that candidates often confuse the session user (`gs.getUser()`) with the record's related user (e.g., caller_id), leading them to overlook the need to dot-walk to the caller's department instead of using the logged-in user's department.

How to eliminate wrong answers

Option B is wrong because the rule's 'When to run' configuration is not mentioned in the question; the developer suspects the condition is incorrect, not the trigger timing, and the script already checks `current.operation() == 'insert'`, so the rule could still run on update if the condition were fixed. Option C is wrong because synchronous vs asynchronous execution affects when the rule runs relative to the database operation, not the condition logic; the issue is the condition's field reference, not the execution mode. Option D is wrong because adding `current.operation() == 'update'` would still not fix the core problem—the condition would still check the wrong department (the session user's department) instead of the caller's department, and the rule would still fail to set the field correctly on update.

Practice this question →

60

Multi-Selecthard

A developer is writing a business rule that should trigger on update of the 'short_description' field of an incident. The rule needs to check if the new value contains 'urgent' and, if so, set the priority to 1. Which TWO statements are true about implementing this rule?

Select 2 answers

A.The condition 'current.short_description.changes()' can be used to ensure the rule runs only when short_description changes.

B.The new value of short_description can be accessed using current.short_description.

C.The new value of short_description can be accessed using previous.short_description.

D.To set the priority, use current.priority.setValue(1).

E.The comparison should use current.short_description.indexOf('urgent') !== -1.

AnswersA, B

Correct. The changes() method on a GlideElement returns true only when the field's value has been modified during the current transaction.

Why this answer

The changes() method on a GlideElement returns true only when the field's value has been modified during the current transaction. Placing `current.short_description.changes()` in the business rule's condition ensures the rule triggers only when the short_description field is updated, not on other field changes. Option B is correct because `current` always holds the updated record after the database write; thus `current.short_description` contains the new value.

Options C and D are incorrect: `previous.short_description` holds the old value before the update, and `setValue()` is not a method on GlideRecord fields—priority should be set by direct assignment (e.g., `current.priority = 1`). Option E is incorrect because `current.short_description` is a GlideElement object, not a plain string; the indexOf() method does not exist on GlideElement. To check for a substring, you must convert to string first, e.g., `current.short_description.toString().indexOf('urgent') !== -1`.

Therefore, the two true statements are A and B.

Exam trap

The trap here is that candidates often confuse `current` and `previous`—thinking `previous` holds the new value—or mistakenly use `setValue()` instead of direct assignment for GlideRecord fields.

Practice this question →

61

Multi-Selecteasy

Which TWO statements are true about ServiceNow Business Rules? (Select TWO)

Select 2 answers

A.Business Rules run on the client side.

B.Business Rules can be set to run on 'before' or 'after' the database operation.

C.Business Rules can only be triggered by updates to a record.

D.Business Rules are executed asynchronously by default.

E.Business Rules can be used to send email notifications.

AnswersB, E

Correct, they have a 'When to run' property.

Why this answer

Business Rules are server-side scripts that execute when a record is inserted, updated, deleted, or queried. They can be configured to run 'before' the database operation (to modify data before it is saved) or 'after' the operation (to perform additional actions like logging or notifications). This flexibility is a core feature of the ServiceNow platform.

Exam trap

The trap here is that candidates often confuse server-side Business Rules with client-side scripts, or assume they only run on updates, but the exam tests the precise trigger conditions and execution context.

Practice this question →

62

MCQmedium

Refer to the exhibit. Which scenario most likely caused this error?

A.The Business Rule runs on delete and 'current' is null.

B.The Business Rule tries to access a field that doesn't exist.

C.The Business Rule uses 'previous.sys_id' but the record is new.

D.The Business Rule is not active.

AnswerC

On insert, previous is null.

Why this answer

When a Business Rule runs on 'insert' or 'update' and references 'previous.sys_id', the 'previous' object is null for new records (since there is no prior version). This causes a 'Cannot read property 'sys_id' of null' error. The error occurs specifically because the script attempts to access a property on an undefined object.

Exam trap

ServiceNow often tests the distinction between 'current' and 'previous' objects in Business Rules, and the trap here is that candidates may not realize 'previous' is null for new records, leading them to incorrectly assume the error is about a missing field or inactive rule.

How to eliminate wrong answers

Option A is wrong because if a Business Rule runs on delete and 'current' is null, the error would be about 'current' being null, not 'previous'. Option B is wrong because accessing a non-existent field typically throws a 'Field does not exist' error, not a null reference error on 'previous'. Option D is wrong because an inactive Business Rule simply does not execute, so it would not produce any error at all.

Practice this question →

63

MCQhard

A global business rule that runs on after query on the Task table is causing performance degradation. The rule modifies the query condition for all task records. The developer needs to optimize the rule without changing its functionality. Which approach is best?

A.Move the script to a condition builder script include

B.Convert the business rule to a script action in a flow designer

C.Make the business rule asynchronous

D.Use glideRecord.addEncodedQuery() instead of addQuery()

AnswerD

addEncodedQuery allows passing a single encoded query string, reducing multiple database calls.

Why this answer

Using `glideRecord.addEncodedQuery()` allows the business rule to directly apply a pre-encoded query string to the GlideRecord object, which is more efficient than using multiple `addQuery()` calls. This reduces the overhead of parsing individual conditions and improves performance when modifying query conditions on the Task table, without altering the rule's functionality.

Exam trap

The trap here is that candidates often assume asynchronous execution (Option C) always improves performance, but they overlook that changing the business rule to asynchronous would prevent it from modifying the query condition before execution, thus breaking the required functionality.

How to eliminate wrong answers

Option A is wrong because moving the script to a condition builder script include does not address the performance degradation; it merely relocates the logic without optimizing the query construction. Option B is wrong because converting the business rule to a script action in Flow Designer introduces additional orchestration overhead and is not designed for optimizing query conditions in a before query business rule. Option C is wrong because making the business rule asynchronous would change its functionality—it would no longer run synchronously during the query phase, which is required to modify the query condition before execution.

Practice this question →

64

MCQeasy

Refer to the exhibit. The Business Rule is set to run on before update. When a record's category is changed to 'hardware', the assignment group is updated correctly. However, when a record is inserted with category 'hardware', the assignment group is not set. Why?

A.The condition 'current.category.changes()' returns false on insert.

B.The Business Rule does not run on insert.

C.The Business Rule runs after the database operation.

D.The setValue method does not work on insert.

AnswerA

On insert, changes() is false because no previous value.

Why this answer

The condition 'current.category.changes()' checks if the category field has changed from its previous value. On insert, there is no previous value, so this condition returns false, causing the business rule to not execute the assignment group update. Option B is incorrect because the business rule does run on insert (it is configured to run on insert as well, despite the stem mentioning only 'before update'), but the condition fails.

Option C is incorrect because the rule runs before the database operation. Option D is incorrect because setValue works on insert.

Practice this question →

65

Multi-Selecthard

A developer is creating a business rule to automatically assign tasks to a specific group based on the category. The rule is set to run before insert and update on the Task table. The script uses current.assignment_group = 'IT Support'. However, the assignment group is not being set on update even though it works on insert. Which three potential causes should the developer investigate? (Choose three.)

Select 3 answers

A.The business rule's condition field requires the category to be set

B.The assignment group field is read-only on the form but can be set via business rule

C.The script does not include a condition to run on update

D.The business rule is set to run only in the global scope

E.Another business rule is resetting the assignment group after this rule runs

AnswersA, C, E

If the business rule has a condition that checks for category, the rule may not fire on update if the category field is not updated or empty.

Why this answer

Option A: If the business rule's condition depends on the category field, and the category isn't changed on update, the rule may not run, preventing assignment group update. Option C: If the script only runs on insert but not update, it won't execute on updates. Option E: Another business rule acting after this one could reset the assignment group.

Option B: The assignment group being read-only on the form does not stop business rules from setting its value; this is not a cause. Option D: Running only in the global scope does not affect whether the rule runs on update; scope is not a cause.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Sn Automation Scripts questions.

Start 20-question session