SNOW-CAD Automating application logic with business rules and scripts Practice Test 3 — 15 Questions

Question 1

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?

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

Accepted Answer

The rule runs after the record is saved. The rule runs after the record is saved. In ServiceNow, a business rule that runs 'after' the database operation (after insert/update) cannot modify the record's field values because the record has already been committed to the database. Any changes made to the current object in an after business rule are not persisted unless an explicit update is performed. Since the assignment group is not being saved, the rule must be executing after the record is saved, preventing the change from taking effect.

Answer

The rule is a display business rule

Answer

The business rule is set to run on before update only

Answer

The script does not use current.setAbortAction(false)

Question 2

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?

Accepted Answer

The new business rule uses query.setCondition() to set the query condition, replacing the existing condition. The new business rule uses query.setCondition() to set the query condition, replacing the existing condition. In ServiceNow, when multiple business rules run on the same table and operation, the order of execution matters. If a new business rule runs after the existing one and uses query.setCondition() to set a new condition, it will overwrite the condition added by the existing rule, effectively removing the filter. The existing rule's condition is lost because setCondition() replaces the entire query condition.

Answer

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

Answer

The existing business rule is set to run only on insert

Answer

The new business rule uses glide.addNullQuery

Question 3

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?

Accepted Answer

current.operation() == 'update' && current.state.changesFrom('In Progress') && current.state.changesTo('Resolved'). The changesFrom() and changesTo() methods are ServiceNow's purpose-built GlideElement methods for detecting field value transitions in business rules. current.state.changesFrom('In Progress') returns true only when the previous value was 'In Progress', and current.state.changesTo('Resolved') returns true only when the new value is 'Resolved'. Combined with current.operation() == 'update', this precisely matches the required condition.

Answer

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

Answer

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

Answer

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

Question 4

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?

Accepted Answer

Set the rule to run as the system user. The business rule fails because it executes in the security context of the logged-in user, who lacks the 'change_request.create' role needed to insert the related task. Setting the rule to run as the system user bypasses ACL checks, allowing the insert to succeed regardless of the user's roles. This is the standard ServiceNow solution for business rules that must perform privileged operations on behalf of any user.

Answer

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

Answer

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

Answer

Use current.setAbortAction(false) to ignore the error

Question 5

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.)

Accepted Answer

current.operation() == 'update'. Option A is correct because the business rule is configured to run on 'after update' of the Incident table, and using current.operation() == 'update' in the condition field explicitly restricts execution to update operations, preventing the rule from firing on insert or delete. Option C is correct because it compares the incident's assignment_group reference field to the specific assignment group named 'IT Support', which is exactly the requirement to fire only when the incident is assigned to that group. Option B is incorrect because isValidRecord() merely verifies that the referenced assignment group record exists, not that it matches a specific group. Option D is incorrect because changes() only checks whether the assignment_group field was modified, regardless of which group it changed to. Option E is incorrect because it checks the current user's manager, which is unrelated to the incident's assignment group.

Answer

current.assignment_group.isValidRecord()

Answer

current.assignment_group.changes()

Answer

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

Question 6

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.)

Accepted Answer

The email notification is triggered by a different business rule. Option D is correct because if a separate business rule also fires on after update of the Incident table and sends the same email notification, the notification will be sent more than once for a single update, producing duplicate emails. Option E is correct because a business rule configured to run on before update as well as after update will execute in both timing phases, so the email-sending logic can run twice for the same update. Option A is not correct because current.state.changes() already compares the current value to the previous database value, so the absence of an explicit previous-state check does not by itself cause multiple sends. Option B is not correct because a condition of 'state changes' merely limits when the rule runs; it does not cause duplicate execution. Option C is not correct because running on both insert and update would not duplicate an email for the same update event.

Answer

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

Answer

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

Answer

The business rule runs on both insert and update

Question 7

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.)

Accepted Answer

The business rule's condition field requires the category to be set. Option A: If the business rule's condition depends on the category field, and the category isn't changed on update, the rule may not run, preventing assignment group update. Option C: If the script only runs on insert but not update, it won't execute on updates. Option E: Another business rule acting after this one could reset the assignment group. Option B: The assignment group being read-only on the form does not stop business rules from setting its value; this is not a cause. Option D: Running only in the global scope does not affect whether the rule runs on update; scope is not a cause.

Answer

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

Answer

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

Question 8

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?

Accepted Answer

The script does not include a condition to check if the CI belongs to the cmdb_ci_server table. The script uses `gr.get('cmdb_ci_server', current.cmdb_ci)` which only finds CI records of the 'cmdb_ci_server' table. If the CI belongs to a different class (e.g., 'cmdb_ci_router'), the query returns no record, so the update never occurs. Option B is correct because the script lacks a condition to verify the CI's table class. Option A is incorrect because business rules running after save can still update other records. Option C is false since synchronous rules can update other records. Option D is not the root cause; the `gr.update()` is present, but the problem is that the record is not found.

Answer

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

Answer

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

Answer

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

Question 9

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?

Accepted Answer

Use current.cmdb_ci directly. The [CORRECT] answer is to use `current.cmdb_ci` directly because the business rule runs on the `change_request` table, and `current` already represents the current change request record. The `cmdb_ci` field is a reference field on the change request, so accessing it via `current.cmdb_ci` retrieves the related CI without an unnecessary GlideRecord query. This avoids the null reference error caused by querying the wrong table and ensures the workflow starts correctly for all change requests.

Answer

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

Answer

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

Answer

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

Question 10

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?

Accepted Answer

Create a script include with a static variable to cache the mapping for the duration of the current transaction. 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.

Answer

Use GlideAggregate to retrieve the count of matching groups

Answer

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

Answer

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

Question 11

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.

Accepted Answer

The script uses 'previous' incorrectly; remove 'previous != null' from the function signature.. The business rule contains a syntax error in the function signature. The correct format for a business rule script is `(function executeRule(current, previous))`. The script uses `(function executeRule(current, previous != null))` which is invalid JavaScript and prevents the script from executing. Since the script never runs, no error appears in the logs, and the CI is not updated. Option A is incorrect because changing to synchronous does not fix a syntax error. Option B is incorrect because the condition field being empty means the rule runs, but the script still fails to execute. Option C addresses a possible data issue, but the primary cause is the syntax error; even if `cmdb_ci` is populated, the script would still not run.

Answer

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

Answer

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

Answer

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

Question 12

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.

Accepted Answer

Change the condition script to check if the field exists before using it, and if not, exit the script gracefully.. It is the quickest fix with minimal disruption: by checking if the field exists in the condition script, the business rule gracefully exits without error when the field is missing, and once the field is added, the condition will pass and the rule will run as intended. Option A is incorrect because reordering does not address the root cause; the 'Asset Assignment' rule would still fail due to the missing field. Option B is incorrect because moving the check into the script (instead of the condition) would not prevent the condition script from referencing the missing field; the condition script would still error. Option C is incorrect because deactivating the rule prevents the intended functionality entirely until the field is added, which is more disruptive than a simple condition check.

Answer

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.

Answer

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

Answer

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

Question 13

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?

Accepted Answer

The condition 'current.impact.changes()' returns false on insert because the previous value is null.. 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.

Answer

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

Answer

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

Answer

The business rule is inactive.

Question 14

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

Accepted Answer

The update will trigger other business rules that run on update.. 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.

Answer

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

Answer

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

Answer

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

Question 15

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?

Accepted Answer

Add a condition to the business rule so that it only executes when specific important fields (e.g., status, assigned to) are changed.. Adding a condition to limit execution to only significant changes (e.g., important fields) reduces the frequency of the heavy operation. Option A is not valid because before business rules cannot write to a different table after the operation; they would need to use a separate script. Option C is incorrect because implementing the audit logic using a script include called from a UI policy is not suitable; UI policies are client-side and cannot perform server-side operations like writing to an audit table. Option D might cause delays if asynchronous execution is not properly configured, and it still runs the same operation; additionally, asynchronous business rules can lead to data consistency issues.

Answer

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

Answer

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

Answer

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