SNOW-CAD Automating application logic with business rules and scripts — 10 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?

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

Accepted Answer

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

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

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

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 6

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

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 in ServiceNow business rules, current.short_description.changes() is a valid method that returns true only when the short_description field has been modified during the current update, ensuring the rule fires only on that change. Option B is correct because current represents the record with its new, incoming values, so current.short_description holds the updated value that the rule must inspect for the substring 'urgent'. Option C is incorrect because previous.short_description holds the old value before the update, not the new value needed for the check. Option D is incorrect because the proper server-side API is current.priority.setValue(1) only in certain contexts; in a business rule the standard approach is current.priority = 1, and setValue is not the typical method for setting a field value on a GlideRecord in this scenario. Option E is incorrect because while indexOf can test for a substring, the idiomatic and safer ServiceNow approach is current.short_description.includes('urgent') or indexOf('urgent') >= 0, and the strict !== -1 comparison is not the standard recommended pattern for this rule.

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 8

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

Accepted Answer

Use the Business Rule debug tool.. The Business Rule debug tool in ServiceNow allows you to simulate the execution of a business rule with a specific record, showing the order of execution, conditions, and script logic. It is the most efficient way to debug a business rule because it provides a controlled environment to test and inspect variables without affecting production data. It also shows which other business rules are triggered and their relative order.

Answer

Add a breakpoint in the script.

Answer

Use the debugger in Studio.

Answer

Insert a gs.log() message.

Question 9

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

Accepted Answer

Add a condition on the child table's Business Rule referencing the parent.. 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.

Answer

Use a workaround with a scheduled job.

Answer

This is not possible in ServiceNow.

Answer

Use a before query Business Rule on the child table.

Question 10

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?

Accepted Answer

The Business Rule runs after the database operation.. `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.

Answer

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

Answer

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

Answer

The Business Rule has a condition that is not met.