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

Question 1

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?

Accepted Answer

The developer used gs.setValue() instead of current.setValue().. 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.

Answer

The business rule runs after the database update.

Answer

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

Answer

The business rule is set to run on insert only.

Question 2

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?

Accepted Answer

Before business rule. 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.

Answer

Display business rule

Answer

Async business rule

Answer

After business rule

Question 3

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?

Accepted Answer

The GlideRecord query requires an explicit gr.updateMultiple() or gr.commit() to persist changes.. 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.

Answer

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

Answer

After business rules cannot update other tables.

Answer

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

Question 4

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?

Accepted Answer

current.state.changes() && current.state.changesFrom('New'). 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'.

Answer

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

Answer

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

Answer

current.state.changesTo('In Progress')

Question 5

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?

Accepted Answer

'Default'. 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.

Answer

Both values will be concatenated

Answer

The value set by the rule at order 100

Answer

The field will be empty because gotoField() clears it

Question 6

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

Accepted Answer

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

Answer

Form load

Answer

Timer event

Answer

Inbound email receipt

Question 7

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

Accepted Answer

Set the Order field to control execution sequence. 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.

Answer

Use gs.sleep() to wait for other processes

Answer

Use GlideAggregate for updating records

Question 8

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?

Accepted Answer

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

Answer

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

Answer

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

Answer

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

Question 9

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?

Accepted Answer

Use the 'Condition' field on the business rule to specify the condition.. 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.

Answer

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

Answer

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

Answer

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

Question 10

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

Accepted Answer

GlideAggregate can be used to perform SQL-like GROUP BY operations.. 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.

Answer

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

Answer

GlideAggregate automatically orders the results by the aggregated field.

Answer

GlideAggregate can only be used in client scripts.

Question 11

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?

Accepted Answer

The GlideRecord used in the REST API does not load the record's previous values, so changes() returns false.. 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.

Answer

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

Answer

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

Answer

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

Question 12

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?

Accepted Answer

Condition type: 'when to run' set to 'on update' with condition 'current.assigned_to.changes()'. 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.

Answer

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

Answer

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

Answer

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

Question 13

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?

Accepted Answer

The condition 'current.short_description.changes()' can be used to ensure the rule runs only when short_description changes.. 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.

Answer

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

Answer

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

Answer

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

Question 14

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?

Accepted Answer

The business rule runs before insert, so the correlation_id field may not have a value yet.. 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.

Answer

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

Answer

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

Answer

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

Question 15

Drag and drop the steps to create a Client Script in ServiceNow into the correct order.