ServiceNow Business Rules

Business Rules are server-side JavaScript scripts that run automatically when a record is inserted, updated, deleted, or queried. They enforce business logic, validate data, update related records, and trigger other processes — all on the server, invisible to the end user. Business Rules are one of the most powerful automation tools in ServiceNow development.

Why Business Rules Run on the Server

ServiceNow separates automation into server-side and client-side scripts. Business Rules run on the server (ServiceNow's cloud infrastructure). Client scripts run in the user's browser. Server-side execution has two advantages: the logic runs even if the user has JavaScript disabled, and the script has full access to the database through the GlideRecord API.

Business Rule Triggers: When Do They Run?

Each Business Rule specifies when it fires based on a combination of When and Operation:

When (Timing)

Before: Runs before ServiceNow saves the record. Use this to validate data or modify field values before they reach the database.
After: Runs after ServiceNow saves the record. Use this to update related records or trigger other processes.
Async: Runs after saving, in a background queue. Use this for non-urgent work that shouldn't slow down the user's save action.
Display: Runs when the form loads (read operation). Use this to pre-populate variables for client scripts to use.

Operation

Insert: Fires when a new record is created.
Update: Fires when an existing record is changed.
Delete: Fires when a record is removed.
Query: Fires when records are read from the table.

The current Object

Inside a Business Rule script, the current object refers to the record being processed. Every field on the record is accessible through current.fieldname. This is how scripts read and modify record data.

// Business Rule: Auto-assign based on category (Before Insert)
if (current.category == 'network') {
    current.assignment_group.setDisplayValue('Network Support');
}
if (current.category == 'hardware') {
    current.assignment_group.setDisplayValue('Desktop Support');
}

The previous Object

On Update operations, the previous object holds the record's field values from before the update. Comparing current and previous lets scripts detect exactly what changed.

// Business Rule: Log when priority changes (After Update)
if (current.priority != previous.priority) {
    gs.log(
        'Incident ' + current.number + 
        ' priority changed from ' + previous.priority.getDisplayValue() +
        ' to ' + current.priority.getDisplayValue()
    );
}

Conditions: Limiting When a Business Rule Fires

Every Business Rule has a condition field that acts as a gate. The Business Rule only runs its script when the condition is true. Using conditions efficiently prevents unnecessary script executions and improves platform performance.

Business Rule Configuration:
─────────────────────────────────────────────────────
Table:      incident
When:       before
Operation:  update
Condition:  current.state.changesTo(6)  ← Only when resolving
                                          (State changes TO Resolved)
Script:     // Require resolution notes before resolving
            if (current.close_notes == '') {
                current.setAbortAction(true);
                gs.addErrorMessage('Resolution Notes are required.');
            }
─────────────────────────────────────────────────────

current.setAbortAction(true)

This powerful method cancels the save operation entirely. When called inside a Before Business Rule, ServiceNow stops saving the record and displays an error message to the user. This enforces data quality rules — preventing records from being saved in an invalid state.

gs.addErrorMessage() and gs.addInfoMessage()

These methods display messages to the user at the top of the form after a save attempt:

gs.addErrorMessage('text'): Shows a red error banner. Often paired with setAbortAction to explain why the save was blocked.
gs.addInfoMessage('text'): Shows a blue informational banner. Used to confirm that an automated action ran (without blocking the save).

Updating Related Records from a Business Rule

Business Rules commonly update records in other tables when triggered. When an Incident is resolved, an After Business Rule might close all related tasks. When a Change is approved, a Business Rule might notify affected users. GlideRecord queries inside Business Rules handle these cross-table updates efficiently.

// After a Problem is Resolved, update all linked incidents
var inc = new GlideRecord('incident');
inc.addQuery('problem_id', current.sys_id);
inc.addQuery('state', '!=', 7);  // Not already closed
inc.query();
while (inc.next()) {
    inc.state = 6;  // Set to Resolved
    inc.close_notes = 'Resolved via Problem ' + current.number;
    inc.update();
}

Business Rule Best Practices

Always add a clear, meaningful name that explains what the rule does.
Use the Condition field to narrow when the rule fires — avoid running scripts on every save when conditions limit it to relevant situations only.
Prefer "Before" rules for validation and "After" rules for related record updates.
Avoid making Business Rules that trigger other Business Rules in a long chain — this creates hard-to-debug "cascade" behavior.
Use "Async" for any operation that does not need to complete before the user's save returns — long-running scripts in synchronous rules slow the user experience noticeably.

Previous lesson

Back to course

Next lesson