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

Question 1

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?

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

Accepted Answer

The 'amount' field is not numeric in the invoice table.. 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.

Answer

The getTotal method is not properly defined.

Answer

The GlideAggregate query syntax is incorrect.

Answer

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

Question 2

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?

Accepted Answer

The business rule's 'When' field is set to 'UI action only' which excludes web service updates.. ServiceNow business rules have a 'When' field that can be set to 'before', 'after', 'async', 'display', or 'UI action only'. If set to 'UI action only', the rule fires only when triggered from a UI action, not from web service (REST/SOAP) updates — which explains why the rule does not fire for web service calls.

Answer

The business rule is inactive.

Answer

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

Answer

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

Question 3

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?

Accepted Answer

The script include is not global.. A script include that is not marked 'Accessible from all scopes' (i.e., not global) can only be called from scripts within its own application scope. If the business rule and script include share a scope, the call succeeds; if the scheduled job runs in a different scope, the call fails silently and no log is written. Making the script include global (or adding a cross-scope access privilege) resolves it.

Answer

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

Answer

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

Answer

The scheduled job runs with a different user context.

Question 4

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?

Accepted Answer

current.setAbortAction(true); gs.addErrorMessage('Short description required');. The proper order is to call `current.setAbortAction(true)` first to abort the save, then use `gs.addErrorMessage()` to display an error message. Option A is incorrect because it uses `gs.addInfoMessage()` for an informational message instead of an error, which does not properly indicate a validation failure. Option B is incorrect both because it reverses the order (the error message may not display after abort) and uses `addInfoMessage`. Option C is incorrect because it reverses the order: the error message is added before the abort action, which may cause the message to be lost. Only D uses the correct order and the correct method for error messages.

Answer

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

Answer

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

Answer

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

Question 5

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?

Accepted Answer

The field was renamed in the cloned instance.. 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.

Answer

The assignment_group field does not exist on the Task table.

Answer

The script include that defines the field is missing.

Answer

The clone process incorrectly copies business rules.

Question 6

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

Accepted Answer

new GlideRecord('table').query();. 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.

Answer

GlideRecord.query();

Answer

gs.query();

Answer

GlideRecord.newQuery();

Question 7

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?

Accepted Answer

The business rule is set to 'after' and cannot modify the current record.. 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.

Answer

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

Answer

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

Answer

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

Question 8

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

Accepted Answer

current.state.changesTo('Resolved'). current.state.changesTo('Resolved') is the standard GlideRecord method that evaluates to true only when the state field's value is being set to 'Resolved' in the current save operation, which precisely matches the business rule's trigger condition. Option C is also correct because combining current.state.changesTo('Resolved') with current.operation() == 'update' ensures the notification fires only on updates (not on inserts) where the state transitions to 'Resolved', which is the intended behavior for a state-change notification. Option A is not correct because current.state == 'Resolved' is true on every save where the record's state is 'Resolved', including updates that don't change the state, so it would fire repeatedly rather than only on the transition. Option D is not correct because current.state.changes() returns true whenever the state field changes to any value, not specifically to 'Resolved'. Option E is not correct because current.state.changesFrom() != 'Resolved' only checks that the previous value wasn't 'Resolved' and does not verify the new value is 'Resolved'.

Answer

current.state == 'Resolved'

Answer

current.state.changes()

Answer

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

Question 9

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

Accepted Answer

Setting a default value on a new record. Option C is correct because a 'before' business rule executes prior to the database insert, allowing it to set a default value on the new record before it is saved. Option D is correct because a 'before' rule can modify fields on the current record in memory, and those changes are persisted with the same database operation without triggering a second update. Option E is correct because a 'before' rule can call the setAbortAction() method to abort the current transaction before the database operation completes, which is not possible in an 'after' rule. Option A is not correct because sending an email notification is typically done in an 'after' rule, since the record must exist and be committed before the notification is meaningful. Option B is not correct because deleting a related record is a separate database operation that should occur in an 'after' rule, as the current record must first exist to establish the relationship.

Answer

Sending an email notification

Answer

Deleting a record related to the current record

Question 10

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

Accepted Answer

Nothing, because there is no script.. A business rule with an empty script still fires when its condition and trigger match, but because there is no server-side code to execute, no action occurs. The rule does not error out — ServiceNow permits empty scripts — and it does not apply default behavior. The net effect is that the state change to Resolved proceeds normally with no additional logic.

Answer

The business rule will not fire because condition is invalid.

Answer

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

Answer

The business rule will still fire and execute default actions.

Question 11

What is the effect of this business rule?

Accepted Answer

It sets assignment_group to 'IT Support' every time the caller or short description changes.. 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.

Answer

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

Answer

It only runs when both caller and short description change.

Answer

It only sets assignment_group when the incident is first created.

Question 12

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?

Accepted Answer

current.operation() in ['insert','update']. 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.

Answer

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

Answer

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

Answer

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

Question 13

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?

Accepted Answer

The condition should check current.caller_id.department instead. 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.

Answer

The rule is set to run only on insert

Answer

The script uses synchronous business rule instead of asynchronous

Answer

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

Question 14

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?

Accepted Answer

Use glideRecord.addEncodedQuery() instead of addQuery(). 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.

Answer

Move the script to a condition builder script include

Answer

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

Answer

Make the business rule asynchronous

Question 15

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?

Accepted Answer

current.priority.changes(). The method current.priority.changes() is the correct way to check if the 'priority' field has changed during an after update business rule. This method compares the current and previous values of the specified field and returns true if they differ. It is the standard ServiceNow API for detecting field changes in business rules.

Answer

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

Answer

current.changes()

Answer

previous.priority != current.priority