Business Rules

Business Rules in ServiceNow: A Comprehensive Guide for CAD Exam Preparation

Business Rules in ServiceNow

Why Are Business Rules Important?

Business Rules are one of the most fundamental and powerful server-side automation tools in ServiceNow. They are critical because they allow administrators and developers to control what happens when records are inserted, updated, deleted, or queried in the database. Nearly every ServiceNow implementation relies heavily on Business Rules to enforce data integrity, automate field values, prevent unauthorized changes, and trigger downstream processes. For the ServiceNow Certified Application Developer (CAD) exam, Business Rules represent a core topic that you absolutely must master, as questions about them appear frequently and test both conceptual understanding and practical application.

What Are Business Rules?

A Business Rule is a server-side script that executes when a record is displayed, inserted, updated, deleted, or when a table is queried. Business Rules are associated with a specific table and are configured to run based on defined conditions and timing.

Key Characteristics:
- Business Rules run on the server side, not the client side
- They are tied to a specific table
- They execute based on a when condition (before, after, async, or display)
- They can be configured to run on insert, update, delete, and/or query operations
- They can include both a condition (optional) and a script
- They have access to the current and previous objects

How Do Business Rules Work?

1. The Four Timing Options (When to Run):

Before:
- Executes before the record is saved to the database
- Used to modify field values on the current record before it is committed
- No need to call current.update() — the system handles the database write after the script runs
- Common use cases: setting default values, validating data, modifying fields automatically

After:
- Executes after the record has been saved to the database
- The record already exists in the database at this point
- Used when you need the sys_id or other committed data, or when you need to update related records
- If you modify the current record in an After Business Rule, you must call current.update() — but be cautious as this can cause recursion
- Common use cases: creating related records, sending notifications, updating parent/child records

Async:
- Executes after the record is saved, but runs in a separate scheduled job
- Runs on a scheduler worker thread, not in the user's transaction
- Used for operations that are time-consuming or not time-sensitive
- The previous object is not available in async Business Rules
- Common use cases: heavy calculations, external integrations, batch operations

Display:
- Executes when a record is loaded for display (form load), before the form is presented to the user
- Does NOT execute on list views or during database operations like insert/update/delete
- Used to calculate values or set scratchpad variables for the client
- The g_scratchpad object can be used to pass server-side data to client scripts
- Common use cases: passing server data to client scripts, calculating display-only values

2. The Database Operations:
- Insert: Runs when a new record is created
- Update: Runs when an existing record is modified
- Delete: Runs when a record is removed
- Query: Runs when the table is queried (can be used to add conditions to all queries, e.g., row-level security)

3. The current and previous Objects:

- current: Represents the record being acted upon. Contains the current values of all fields.
- previous: Represents the record's values before the current transaction. Available in Before and After rules on update and delete operations. Not available in Async Business Rules.
- You can compare current and previous to detect specific field changes: current.state != previous.state

4. Conditions and Filtering:
- Business Rules can use a condition field (point-and-click filter) and/or a script-based condition
- The condition builder is evaluated first; if it passes, the script executes
- You can also add conditions within the script itself using if-statements
- The Filter Conditions field uses the same query builder as list filters

5. Important Methods and Properties:

- current.update() — Saves changes to the current record. Should only be used in After Business Rules (and used sparingly to avoid recursion).
- current.setAbortAction(true) — Aborts the current database operation. Commonly used in Before rules to prevent a record from being saved if validation fails.
- gs.addErrorMessage() — Displays an error message to the user on the form.
- gs.addInfoMessage() — Displays an informational message to the user.
- current.setValue('field', value) — Sets a field value on the current record.
- current.field_name.changes() — Returns true if the specified field value has changed.
- current.field_name.changesTo(value) — Returns true if the field changed to the specified value.
- current.field_name.changesFrom(value) — Returns true if the field changed from the specified value.
- current.isNewRecord() — Returns true if the record is being inserted (new).
- current.isValidRecord() — Returns true if the current record is valid.
- g_scratchpad — Object available in Display Business Rules to pass data to client scripts.

6. Avoiding Common Pitfalls:

- Never call current.update() in a Before Business Rule. The system automatically saves the record after a Before rule runs. Calling current.update() in a Before rule causes the record to be saved twice and can trigger recursive Business Rule execution.
- Be careful with current.update() in After Business Rules. It triggers another update operation, which can cause infinite loops if the Business Rule's conditions are not specific enough.
- Use the setWorkflow(false) method before calling current.update() in After rules if you want to prevent other Business Rules from firing on that update.
- Async Business Rules do not have access to previous. If you need to compare old and new values, use a Before or After rule instead.
- Display Business Rules only run on form loads, not on list views or during backend operations.

7. Order of Execution:

Business Rules have an Order field (numeric value, default is 100). Rules with lower order numbers execute first. When multiple Business Rules are configured on the same table with the same timing:
- They execute in ascending order of the Order field
- If two rules have the same order, execution sequence is not guaranteed

The general execution flow for a record save is:
1. Before Business Rules execute (in order)
2. The record is saved to the database
3. After Business Rules execute (in order)
4. Async Business Rules are queued for later execution

8. Business Rules vs. Other Server-Side Mechanisms:

- Business Rules vs. Script Includes: Business Rules are event-driven (triggered by database operations). Script Includes are reusable code libraries that must be explicitly called.
- Business Rules vs. Workflows/Flows: Workflows and Flows provide visual, drag-and-drop automation. Business Rules offer more granular, script-based control at the database operation level.
- Business Rules vs. Client Scripts: Business Rules run on the server; Client Scripts run in the browser. Business Rules cannot be bypassed by the user, making them more secure for enforcing business logic.

Practical Examples:

Example 1 — Before Business Rule (Auto-set Priority):
Table: Incident
When: Before
Insert: true, Update: true
Condition: Impact is 1 - High AND Urgency is 1 - High
Script: current.priority = 1; // Set priority to Critical

Example 2 — After Business Rule (Create Related Task):
Table: Incident
When: After
Insert: true
Script: var task = new GlideRecord('task'); task.initialize(); task.short_description = 'Follow-up for ' + current.number; task.insert();

Example 3 — Display Business Rule (Pass Data to Client):
Table: Incident
When: Display
Script: g_scratchpad.isVIP = current.caller_id.vip.toString();
(The client script can then access g_scratchpad.isVIP to adjust form behavior.)

Example 4 — Abort Action (Prevent Save):
Table: Incident
When: Before
Update: true
Script: if (current.state == 7 && !current.close_notes) { gs.addErrorMessage('Close notes are required to resolve an incident.'); current.setAbortAction(true); }

---

Exam Tips: Answering Questions on Business Rules

1. Know the Four Timings Inside and Out: The exam will frequently test your understanding of when to use Before, After, Async, and Display. Remember: Before = modify current record before save; After = act on related records after save; Async = long-running operations; Display = pass data to the client via g_scratchpad.

2. current.update() Rules: If a question asks about calling current.update() in a Before Business Rule, the answer is almost always that this is incorrect/bad practice. current.update() should only be called in After (or Async) Business Rules. This is one of the most commonly tested concepts.

3. previous Object Availability: Remember that the previous object is NOT available in Async Business Rules. If a question involves comparing old and new values in an async context, that is a trap — it will not work as expected.

4. g_scratchpad is Tied to Display Rules: If a question mentions passing server-side data to a Client Script, the answer involves a Display Business Rule using g_scratchpad. This is a very common exam scenario.

5. setAbortAction(true) is for Before Rules: If you need to prevent a database operation (e.g., stop an insert or update based on validation), use current.setAbortAction(true) in a Before Business Rule. This does not work the same way in After rules because the record has already been saved.

6. Watch for Server-Side vs. Client-Side Tricks: The exam may present scenarios where a Business Rule and a Client Script could both seemingly solve a problem. Remember that Business Rules are more secure and cannot be bypassed by users. For data integrity and security enforcement, Business Rules are preferred.

7. Query Business Rules: These are less commonly tested but important. Query Business Rules run before a query returns results and can add conditions (e.g., restricting which records a user can see). They run on the query operation and are used for row-level access control.

8. Order of Execution Matters: If a question asks about controlling the sequence of multiple Business Rules, the answer is the Order field. Lower numbers run first.

9. Read Scenarios Carefully: Many exam questions describe a scenario and ask you to choose the correct type of Business Rule. Key signals:
- "Set a field value before saving" → Before
- "Create a child record after the parent is created" → After
- "Send data to an external system without affecting performance" → Async
- "Show a calculated value on the form without saving it" → Display
- "Prevent the record from being saved" → Before with setAbortAction(true)

10. Understand the Difference Between Condition and Script: The condition field is evaluated first. If the condition is false, the script does not execute. Some questions test whether you understand that conditions can be set via the condition builder OR within the script logic itself.

11. Inheritance and Table Hierarchy: Business Rules defined on a parent table (e.g., Task) apply to all child tables (e.g., Incident, Change, Problem) unless otherwise restricted. The exam may test this concept by asking whether a rule on the Task table affects Incidents.

12. Practice Elimination: On multiple-choice questions, eliminate answers that suggest client-side solutions for server-side problems, suggest calling current.update() in Before rules, or reference the previous object in Async rules. These are common distractors.

By mastering these concepts and tips, you will be well-prepared to confidently answer any Business Rules question on the ServiceNow CAD exam.