A business rule in ServiceNow is a server-side script written in JavaScript that executes when a record
is inserted, updated, deleted, or queried. Business rules allow for automation and enforcement of
business logic without requiring manual intervention.
Business rules are not tied to forms but instead run on the server-side when a database operation
occurs. They can be configured to execute:
Before a record is saved (Before Business Rule)
After a record is saved (After Business Rule)
Asynchronously (Async Business Rule)
Before a query is run on the database (Query Business Rule)
Explanation of the Correct Answer:
✅ B. A business rule can be a piece of JavaScript (Correct)
Business rules are written in JavaScript, allowing administrators to define custom logic that executes
on the server.
These scripts can modify data, enforce rules, validate fields, or trigger other workflows.
Example JavaScript snippet for a business rule:
if (current.state == '3' && current.priority != '1') {
current.priority = '1';
gs.addInfoMessage("Priority set to High because state is Resolved.");
}
This rule ensures that if an incident's state is changed to Resolved, its priority is automatically set to
High.
Why the Other Options Are Incorrect:
❌ A. A business rule must run before a database action occurs (Incorrect)
Business rules can run before a database action occurs, but they can also execute after or
asynchronously.
Business rules have four execution types:
Before – Runs before the record is inserted/updated in the database.
After – Runs after the record is committed to the database.
Async – Runs in the background after the transaction completes.
Query – Runs before data is returned to a user (modifies query results).
❌ C. A business rule must not run before a database action occurs (Incorrect)
This is false because some business rules do run before a database action (e.g., a Before Business
Rule can validate data before saving).
❌ D. A business rule monitors fields on a form (Incorrect)
Business rules do not monitor form fields directly. Instead, they execute based on database
operations.
If real-time monitoring of form fields is needed, Client Scripts (not Business Rules) are used for this
purpose.
Example Use Cases for Business Rules:
Automatically assigning priority based on ticket severity.
Preventing updates to certain records if a condition is not met.
Sending email notifications when a record changes.
Modifying data before it is saved to enforce business policies.
Reference:
ServiceNow Documentation: Business Rules Overview
ServiceNow CSA Learning Path: Business Rule Fundamentals
ServiceNow Docs: Server-Side Scripting in Business Rules
