Business rules in ServiceNow Development

Business rules

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

Quick answer

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.

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.

Practice challenge

+0 XPStreak ×0

Question 1 of 3

A business rule runs on the...

Frequently asked questions

What does the term Business rules refer to in ServiceNow?

What is the practical takeaway on Business rules?

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

What is worth remembering about Business rules in practice?

A business rule should orchestrate, not hold hundreds of lines.

What tends to go wrong with Business rules?

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.