ServiceNow Business Rules: When They Run

ServiceNow Business rules

Run server-side logic when records are saved or read.

Quick answer

A ServiceNow business rule runs on the server when a record is queried, inserted, updated or deleted, so it applies whether the change came by form, import or API. Choose the when: before to set fields without a second save, after to update related records, async for heavy work. current is the record now, previous its prior state.

Key takeaways

When they run
current, previous, and change detection
Keep logic reusable
Business rule vs data policy vs flow
Common mistakes

Business rules are server-side scripts that run when records are queried, inserted, updated or deleted. Because they act at the database layer, they enforce logic no matter how the record changed, form, import or API, which makes them the workhorse of server automation. The skill is choosing the right when and current/previous semantics.

When they run

before

Modify the record before it is written, just set fields, no extra save. Validation/abort.

after

React once the record is saved, update related records, trigger events.

async

Run later via a scheduled job, heavier, non-urgent work; keeps the save fast.

display

Prepare data for the form before it loads, populate g_scratchpad for client scripts.

// before update: stamp who resolved it
(function executeRule(current, previous) {
  if (current.state.changesTo('6')) {          // Resolved
    current.resolved_by = gs.getUserID();
    current.resolved_at = new GlideDateTime();
  }
})(current, previous);

current, previous, and change detection

Inside a rule, current is the record now and previous is its pre-change state. Detect transitions precisely:

current.field.changes()

The field changed at all.

.changesTo(v)

Changed to a specific value, ideal for state transitions.

.changesFrom(v)

Changed from a value.

gs.getUserID() / gs.hasRole()

Who and what rights the current user has.

In a before rule you just set fields on current and the platform saves them, never call current.update(), which causes recursion. In an after rule you touch other records with a fresh GlideRecord.

Keep logic reusable

A business rule should orchestrate, not hold hundreds of lines. Put shared functions in a Script Include and call it from the rule, so the same logic serves multiple rules, flows and APIs.

Business rule vs data policy vs flow

For simple "make this field mandatory/read-only", use a data policy, no code, enforced everywhere. For a multi-step process with approvals and waits, use a flow. Reach for a business rule when you need real server logic: calculations, cross-record updates, conditional aborts (current.setAbortAction(true)).

Common mistakes

Calling current.update() inside a before rule, recursion; just set the field.
Heavy queries in a synchronous rule, slowing every save, move to async.
Duplicating logic across rules instead of a shared Script Include.
Using a business rule where a data policy or flow was the right tool.

Try it YourselfJavaScript

▸ Press Run to execute.

Runs in a sandbox in your browser. Mock gs and GlideRecord and sample data are provided.