Courseiva

CCNA Automating application logic with business rules and scripts Questions

67 questions · Automating application logic with business rules and scripts · All types, answers revealed

Practice these questionsDomain overviewAll 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

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

Prefixes indicate the origin or module of the table.

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
AnswersC, D

On insert, state changes from null to a value, causing an extra email.

Why this answer

Option C: another business rule might also send an email for state changes, causing duplicates. Option E: if the rule runs on insert as well, it will send an email when the state is first set. Option A would not cause duplicates.

Option B is incorrect because before and after are separate. Option D would not cause duplicates because changes() is correct.

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

Option D is correct because 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; non-global script includes are scoped and may not be accessible from scheduled jobs.

Why this answer

Option B is correct because if the script include is not global, it may not be accessible from all contexts like scheduled jobs. Option A is incorrect because user context does not affect script include visibility. Option C is incorrect because log level settings are separate.

Option D is incorrect because the scheduled job is in the same scope.

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

Option D is correct because if the function signature changed, calls to it would fail with 'undefined' errors. Option A would cause 'not found' errors, not undefined. Option B ACLs do not affect server-side execution.

Option C scope change could cause issues but typically results in access errors, not undefined.

Practice this question →
8
MCQeasy

A business rule on the Change Request table needs to update a field on the same record after the record is updated. Which 'When' option should be used?

A.Display
B.After
C.Async
D.Before
AnswerB

Correct; 'After' runs after the record is saved and allows modifications to the same record.

Why this answer

Option B is correct because 'After' runs after the database operation and is appropriate for updating the same record after the fact. Option A is incorrect because 'Before' would modify the record before save, not after. Option C is incorrect because 'Async' runs asynchronously and may not be needed.

Option D is incorrect because 'Display' runs when the form is displayed.

Practice this question →
9
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

Option C is 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 →
10
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

Option A is correct because 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 →
11
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

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

Option C is correct because a Business Rule condition that is syntactically or logically incorrect will cause the rule to evaluate as false, preventing the email notification from being sent. However, the question states the email is sent despite the condition not being met, which indicates the condition itself is flawed—for example, using an incorrect operator or referencing a field that always evaluates to true. In ServiceNow, Business Rules evaluate conditions in JavaScript; if the condition is written incorrectly (e.g., `current.state == 1` when the field is a string), it may always return true, triggering the action unexpectedly.

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 →
13
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

Option A is correct because the proper order is to setAbortAction(true) first, then add an error message. Option B is incorrect because the order is reversed; the error message may not display. Option C and D use addInfoMessage which is for informational messages, not errors.

Practice this question →
14
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

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

Option C is correct because Condition with state=Closed and days since closed > 30, and abort action when field is updated ensures updates are prevented. Option A only sets field read-only when state changes to Closed, not after 30 days. Option B on query does not prevent updates.

Option D UI Policy is client-side only.

Practice this question →
16
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

The correct answer is A because 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 →
17
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

Option A is correct because 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 →
18
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

Option B is correct because 'Async' runs the rule in a background thread, improving performance. Option A is incorrect because immediate execution is not async. Option C is incorrect because 'Display' is for form views.

Option D is incorrect because async rules can run on updates.

Practice this question →
19
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

Option A is correct because `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 →
20
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 →
21
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

Option B is correct. 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 might cause delays if asynchronous is not properly configured, and still runs the same operation. Option D removes functionality entirely, which is not desired.

Practice this question →
22
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

Option B is correct because 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 →
23
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 →
24
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

Option A is correct because 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 →
25
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

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

Option A is correct because 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 →
27
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

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

Option B is correct because 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 →
29
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 →
30
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 →
31
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

Option A is correct because `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 →
32
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 →
33
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

Option C is correct because the Business Rule debug tool allows stepping through execution and inspecting variables. Option A logging is less efficient. Options B and D require development environment setup.

Practice this question →
34
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 →
35
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 →
36
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

Option D is correct because 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 →
37
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; to avoid unintended modifications, script includes should not modify current unless intended.

Why this answer

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

A is incorrect because scoped script includes are accessible within their scope. C is incorrect because script includes can call other script includes. E is incorrect because they are not auto-evaluated.

Practice this question →
38
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 →
39
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 →
40
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 →
41
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

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 →
42
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

Option A is correct because it is the quickest fix with minimal disruption: adding a condition check prevents the business rule from failing when the field is missing, and the rule will run correctly once the field is added. Option B is incorrect because reordering does not fix the root cause; the first rule can run, but the second would still fail if the field is missing. Option C is incorrect because removing the condition entirely would cause the script to run on every insert, which might have unintended side effects, and the field existence check in the script would still be needed.

Option D is incorrect because deactivating the rule prevents the intended functionality entirely until the field is added, which is more disruptive.

Practice this question →
43
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

Option A is correct because an empty script does nothing; no action is taken. Option B is incorrect because there are no default actions. Option C is incorrect because a script is not required.

Option D is incorrect because the condition is valid.

Practice this question →
44
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

Option A is correct because business rules can be configured to run on UI actions only, which excludes web service updates. Option B is incorrect because the condition 'current.operation() == 'update'' is typically used correctly. Option C is incorrect because web services do trigger business rules unless explicitly excluded.

Option D is incorrect because an inactive rule would never run.

Practice this question →
45
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

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

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

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

Option B is correct because 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 →
49
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 A, B, and D are correct. A: Aborting the transaction must happen before the database write. B: Setting a default value must happen before insert.

D: Updating a field on the current record is only possible in 'before' (in 'after' the record is already saved). C and E can be done in 'after' as well.

Practice this question →
50
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

Option A is correct because 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 →
51
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 assumes the CI record is of type 'cmdb_ci_server'. If the CI is a different class (e.g., cmdb_ci_router), the GlideRecord will not find it. Option A is incorrect because after business rules can update other records.

Option B is not the root cause. Option C is false because synchronous rules can update other records.

Practice this question →
52
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

Option B is correct because 'Before' runs before the database insert, allowing default values to be set. Option A is incorrect because 'After' runs after the record is already saved. Option C is incorrect because 'Async' runs later.

Option D is incorrect because 'Display' runs on form display.

Practice this question →
53
MCQmedium

The above script runs in a business rule on the Incident table. What is a potential issue with this script?

A.It will only update the first matching record.
B.It may cause an infinite loop if the same business rule triggers on update.
C.It uses a deprecated API.
D.It will not commit changes because update() is not used correctly.
AnswerB

Correct; the script updates incidents, and if the business rule also fires on update, it can trigger recursively.

Why this answer

Option B is correct because updating incidents using gr.update() could trigger the same business rule again (if the rule runs on update), causing an infinite loop. Option A is incorrect because the API is not deprecated. Option C is incorrect because update() does commit changes.

Option D is incorrect because the while loop iterates all matching records.

Practice this question →
54
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

Option A is correct because 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 →
55
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 →
56
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

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

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

If the rule runs after the record is saved, changes to current are not automatically saved. The script must call current.update(). Options A and B are not relevant.

Display business rules run on the client side.

Practice this question →
59
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

Option A is correct because 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 →
60
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.
AnswerC

If no CI is selected, get() fails silently and the update never runs.

Why this answer

Option C is correct because the script assumes 'current.cmdb_ci' is populated. If the CI field is not required, a change request can be submitted without a CI, causing the GlideRecord get() to fail silently. Option A is incorrect because asynchronous execution does not affect the script logic; the issue is data.

Option B is incorrect because the condition is not missing; the script runs on insert by default. Option D is incorrect because the syntax 'previous != null' in the function signature is invalid; the correct syntax is 'current, previous' but the extra '!= null' would cause a script error, not a silent failure. The error would be logged, which contradicts the statement that no errors are shown.

Practice this question →
61
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

Option A is correct because 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 →
62
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: this condition returns true if the field changed.

Why this answer

Option A is correct because the `changes()` method in ServiceNow returns true only when the specified field's value has been modified during the current transaction. This ensures the business rule triggers exclusively on updates to the `short_description` field, preventing unnecessary execution on other field changes. Option B is correct because `current.short_description` always holds the new (updated) value of the field when the business rule runs after the database update.

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 →
63
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 →
64
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

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

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

Option B is correct. On insert, 'current.category.changes()' returns false because there is no previous value. Option A is incorrect because the rule may run on insert but condition fails.

Option C is incorrect because 'before' rule runs before save. Option D is incorrect because setValue works on insert.

Practice this question →
67
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 condition is not met on update, the rule does not execute.

Why this answer

Option A: if the condition depends on category, on update the category might not trigger the rule. Option C: if the script only runs on insert conditionally, it won't run on update. Option E: another rule might override the group.

Option B: scope is not an issue. Option D: read-only fields can be set in business rules.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Automating application logic with business rules and scripts questions.

Start 20-question session