Automating application logic with business rules and scripts practice questions

Display

Why wrong: Display runs when the form is displayed, not after the record is updated. It is not appropriate for updating the same record after the fact.

Async

Why wrong: Async business rules execute in the background, *after* the current transaction has completed. This prevents them from synchronously updating the *same* record within the immediate user session, which is required for an instant field modification. It is tempting as it runs post-update, but 'Async' is correctly utilised for non-critical, potentially long-running operations like sending notifications or integrating with external systems, where blocking the user or immediate record feedback is unnecessary.

Before

Why wrong: Before runs before the database operation, so the record hasn't been saved yet. It would modify the record before the save, not after.

It will only update the first matching record.

Why wrong: Incorrect; the while loop processes all matching records.

It uses a deprecated API.

Why wrong: Incorrect; GlideRecord is not deprecated.

It will not commit changes because update() is not used correctly.

Why wrong: Incorrect; update() commits changes properly.

The business rule runs after the database update.

Why wrong: Business rules can run before or after; the issue is not timing but the method used to set the field.

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

Why wrong: The condition checks the current record's value, which is empty before the update.

The business rule is set to run on insert only.

Why wrong: The rule is set to run on update, as described.

Display business rule

Why wrong: Display rules affect how the form is rendered, not the data saved.

Async business rule

Why wrong: Async rules run later and are not suitable for immediate field updates.

After business rule

Why wrong: After rules cannot modify the current record's fields for the same transaction.

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

Why wrong: gr.update() is correct for updating existing records.

After business rules cannot update other tables.

Why wrong: After rules can update any table using GlideRecord.

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

Why wrong: There is no hard limit of 100 records; governor limits are higher.

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

Why wrong: current.state == 'New' checks the current value, which after update is 'In Progress', so condition fails.

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

Why wrong: previous() is deprecated; use changesFrom() instead.

current.state.changesTo('In Progress')

Why wrong: This does not check that the previous state was 'New'; it could change from any state.

Both values will be concatenated

Why wrong: Only one value is stored; the last set value wins.

The value set by the rule at order 100

Why wrong: The rule at order 500 runs after and overwrites the value.

The field will be empty because gotoField() clears it

Why wrong: gotoField() does not clear the field; it just moves the cursor.

Form load

Why wrong: Form load triggers display business rules, but not as a standard trigger.

Timer event

Why wrong: Timer events are handled by scheduled jobs, not business rules.

Inbound email receipt

Why wrong: Inbound email actions are separate from business rules.

Use gs.sleep() to wait for other processes

Why wrong: gs.sleep() is not recommended as it blocks the thread.

Use GlideAggregate for updating records

Why wrong: GlideAggregate is for queries, not updates.

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

Why wrong: Read-only fields can still be updated via script; the issue is the trigger.

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

Why wrong: Recursive updates would cause a loop, not prevent execution; the business rule is simply not triggered.

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

Why wrong: Business rules do not have a 'Fields to update' list; they use conditions and script logic.

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

Why wrong: Advanced checkbox enables script conditions, but the condition should still be in the Condition field; the script itself is for actions.

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

Why wrong: The 'When to run' tab filters are for update/insert/delete triggers, not for field value conditions.

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

Why wrong: While possible, the best practice is to use the Condition field for conditions; the script field is for actions.

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

Why wrong: addField() is used to specify fields to group by, not to add non-aggregated fields; all selected fields must be in GROUP BY or aggregate function.

GlideAggregate automatically orders the results by the aggregated field.

Why wrong: GlideAggregate does not automatically order results; you must use addOrderBy() to specify ordering.

GlideAggregate can only be used in client scripts.

Why wrong: GlideAggregate is a server-side class for performing database aggregation queries (SUM, COUNT, AVG) and cannot be instantiated in client scripts, which lack server-side execution context. It is tempting because GlideAggregate resembles GlideRecord, which is commonly used in both client and server scripts, leading to the mistaken assumption that aggregation methods share the same scope. In scenarios requiring client-side data summaries, a GlideAjax call to a Scripted REST API or a business rule would be the correct approach.

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

Why wrong: REST API updates trigger 'before' and 'after' business rules based on the operation; 'before' should still run.

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

Why wrong: The REST API is calling the same instance; otherwise, the trade wouldn't be updated at all.

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

Why wrong: The syntax is correct; the issue is not with the condition itself.

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

Why wrong: Adding '|| current.state.changes()' is unnecessary and could cause the rule to run when state changes but assigned_to does not.

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

Why wrong: This would also run on insert, which is not desired.

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

Why wrong: 'advanced' condition type is used for a condition script that returns true/false, but the condition script 'current.assigned_to.changes()' already returns boolean; however, typical approach is to use 'when to run' with condition.

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

Why wrong: Incorrect. previous.short_description holds the old value before the update.

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

Why wrong: Incorrect. GlideRecord fields are set by direct assignment (current.priority = 1), not by setValue().

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

Why wrong: Incorrect. current.short_description is a GlideElement object, not a string; indexOf() does not exist on it. Use toString() first.

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

Why wrong: Category is writable before insert.

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

Why wrong: It does, choices are stored there.

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

Why wrong: 'name' is the correct field for table name in sys_choice.

Navigate to Client Scripts, then click New, then choose the UI Type and Trigger, then set the Table and Name, then write the script, then submit.

Why wrong: This is incorrect because the UI Type and Trigger selection depends on the table and name context; typically you set the table and name first to define the script's scope before choosing UI specifics.

Navigate to Client Scripts, then click New, then set the Table and Name, then write the script, then choose the UI Type and Trigger, then submit.

Why wrong: This is incorrect because the UI Type and Trigger determine when and where the script runs; you need to set these before writing the script to ensure the script's logic matches the intended trigger event.

Navigate to Client Scripts, then set the Table and Name, then click New, then choose the UI Type and Trigger, then write the script, then submit.

Why wrong: This is incorrect because you cannot set the Table and Name before clicking New; the New button creates the record form where those fields are available.

sys_: User-created custom tables for business-specific data

Why wrong: Incorrect — this describes the u_ prefix, not sys_.

u_: Core system tables for storing configuration and metadata

Why wrong: Incorrect — this describes the sys_ prefix, not u_.

m2m_: Tables for external data integration (e.g., LDAP)

Why wrong: Incorrect — this describes a different convention (e.g., ext_), not m2m_.

Use a Business Rule on query to check state and field value.

Why wrong: Query rule does not prevent updates.

Use a UI Policy to set field read-only.

Why wrong: UI Policy is client-side, not server-side enforcement.

Use a Business Rule with condition when state changes to Closed, set the field to read-only.

Why wrong: Does not prevent updates after 30 days.

The Business Rule should use 'current' and 'previous' to detect deletion.

Why wrong: Previous is not available in delete context.

The Business Rule should also run on 'delete'.

Why wrong: Delete of parent not relevant.

The Business Rule should be a Global Business Rule.

Why wrong: Global rule does not solve trigger issue.