Server Scripting · Lesson 2.2

Types of Business Rules: before, after, async and display

Beginner
15 min read
Tested on Australia
Updated 18 Oct 2026

Business Rules
GlideSystem (gs)

Quick recap

In the previous lesson, What is a Business Rule?, you saw that a Business RuleA server-side script that runs automatically when a record is displayed, inserted, updated, deleted or queried.Learn more runs automatically when something happens to a RecordOne single entry in a table, like one specific incident such as INC0010023.Learn more , and that its When field asks one key question: at which moment should this code run?

There are four possible answers, and each one is a type of Business Rule. Choosing the right type is one of the most important decisions a ServiceNow developer makes, and it is a favourite interview question too.

The four types at a glance

Type	When it runs	Use it to
before	Before the record is saved to the database	Check or change fields on the same record
after	Right after the record is saved	Update other records, or fire events
async	After the save, in the background	Do slow work the user should not wait for
display	Before the form is shown to the user	Send extra server data to the form

Watch a record go through all four types

Reading about the four types is one thing; seeing them in order makes it click. Follow one incident from the moment an agent opens it to the moment the last background job finishes. Press Play, or step through it yourself with Next, and watch the record card change.

InteractiveWatch one incident pass through all four types

Step 1 of 6 · Display
An agent opens the incident
Priya opens INC0010023. Before the form appears on her screen, every display Business Rule on the Incident table runs. Here, one checks whether the caller is a VIP and puts the answer in g_scratchpad for the form to use.
```
g_scratchpad.isVipCaller = current.caller_id.vip == true;
```
Number
INC0010023
Category
Network
Priority
3 - Moderate
Assignment group
(empty)
Saved in database
Yes
Step 2 of 6 · Form
She edits it and clicks Save
The form is now in her browser. She raises Impact and Urgency to High, so Priority becomes 1 - Critical, and clicks Save. Nothing is written to the database yet: her changes travel to the server first.
Number
INC0010023
Category
Network
Priority
1 - Critical
Assignment group
(empty)
Saved in database
Not yet
Step 3 of 6 · Before
Before Business Rules run
On the server, before rules run first. The record is still open, so they can change it. One notices the Network category with no team and fills in the assignment group, with no update() call needed.
```
current.assignment_group.setDisplayValue('Network');
```
Number
INC0010023
Category
Network
Priority
1 - Critical
Assignment group
Network
Saved in database
Not yet
Step 4 of 6 · Database
The record is saved
ServiceNow writes the record to the database in one go, including the change the before rule made. From this moment, the new values are official.
Number
INC0010023
Category
Network
Priority
1 - Critical
Assignment group
Network
Saved in database
Yes
Step 5 of 6 · After
After Business Rules run
Right after the save, after rules run. The record is already stored, so they react to the change instead of editing it. Here, one fires an event so a notification can email the caller.
```
gs.eventQueue('incident.priority.critical', current, current.caller_id, '');
```
Number
INC0010023
Category
Network
Priority
1 - Critical
Assignment group
Network
Saved in database
Yes
Step 6 of 6 · Async
Async Business Rules run in the background
Priya's form has already reloaded and she is back at work. Meanwhile, the scheduler picks up the async rule and alerts the external paging system. If that call is slow, nobody has to wait for it.
```
var request = new sn_ws.RESTMessageV2('Paging system', 'Send alert');
request.execute();
```
Number
INC0010023
Category
Network
Priority
1 - Critical
Assignment group
Network
Saved in database
Yes

Type 1: Before Business Rules

A before rule runs after the user clicks Save, but before the record is written to the DatabaseWhere ServiceNow permanently stores every record. Saving a record writes it to the database.Learn more . At this moment the record is still “open”, so any change you make to it is saved together with everything else. This makes before rules the right choice whenever you want to fill in, correct or check fields on the record being saved.

Inside the script, the record being saved is available as currentIn a server script, the record being worked on right now, including any new values.Learn more . When you change a FieldOne piece of information on a record, like an incident's Priority or Short description.Learn more on current, you do not need to save it yourself. ServiceNow saves it for you a moment later.

Here is a real example. When an incident’s category is Network and nobody has chosen a team yet, set the Assignment groupThe team responsible for working on a task, such as the Network team for a network incident.Learn more to the Network team automatically:

// When: before | Insert: true | Update: true | Table: Incident
(function executeRule(current, previous /*null when async*/) {
    if (current.category == 'network' && current.assignment_group.nil()) {
        current.assignment_group.setDisplayValue('Network');
    }
})(current, previous);

Line by line: the if checks two things: the category is “network”, and the assignment group is empty (nil() means “has no value”). If both are true, setDisplayValue('Network') picks the group whose name is Network. That is the whole rule. There is no save call, because the record is about to be saved anyway.

Type 2: After Business Rules

An after rule runs right after the record has been saved to the database. The record is already stored, so this rule is not the place to change it. Instead, after rules are for reacting to the change: updating other records, or letting other parts of ServiceNow know that something happened.

A common way to do that is to fire an EventA named signal raised by a script (for example with gs.eventQueue) that notifications and other scripts can listen for.Learn more . An event is a named signal; a NotificationAn email or message ServiceNow sends automatically when something happens, such as an event being fired.Learn more can listen for it and send an email.

Example: when an incident is resolved, fire an event so a notification can email the caller.

// When: after | Update: true | Table: Incident
(function executeRule(current, previous /*null when async*/) {
    if (current.state.changesTo(6)) { // 6 = Resolved
        gs.eventQueue('incident.resolved.custom', current, current.caller_id, '');
    }
})(current, previous);

changesTo(6) is true only when the state has just become Resolved in this save, not every time a resolved incident is edited. gs.eventQueue then fires the event, passing the incident and its caller, so the notification knows who to email.

Type 3: Async Business Rules

An async rule also runs after the record is saved, but not immediately. ServiceNow puts it in a queue, and the Scheduler (background jobs)ServiceNow's background job system. Async Business Rules wait here and run shortly after the record is saved.Learn more runs it in the background a few moments later. The user’s screen does not wait for it.

That makes async rules perfect for slow work, especially talking to other systems over the internet. If such a call took five seconds inside an after rule, the user would stare at a frozen screen for five seconds after clicking Save. As an async rule, they never notice.

Example: when a priority 1 incident is created, alert an external paging system. (Paging system here is a REST Message you would set up first; we cover those in the integrations module.)

// When: async | Insert: true | Table: Incident | Condition: Priority is 1 - Critical
(function executeRule(current, previous /*null when async*/) {
    var request = new sn_ws.RESTMessageV2('Paging system', 'Send alert');
    request.setStringParameterNoEscape('number', current.getValue('number'));
    request.execute();
})(current, previous);

Type 4: Display Business Rules

A display rule runs when someone opens a record on a FormThe screen that shows one record and lets you view or edit its fields.Learn more , just before the form appears on their screen. Its job is to collect information on the server and hand it to the form.

Why is that needed? Code that runs in the browser, like a Client ScriptA script that runs in the user's browser when a form loads, a field changes or the form is submitted.Learn more , cannot freely look things up in the database. A display rule can, and it passes what it finds through a special object called g_scratchpadAn object a display Business Rule fills with server data, so Client Scripts on the form can use it.Learn more , which the form’s Client Scripts can then read.

Example: show a message on the incident form when the caller is a VIP. First, the display rule checks the caller on the server:

// When: display | Table: Incident
(function executeRule(current, previous /*null when async*/) {
    g_scratchpad.isVipCaller = current.caller_id.vip == true;
})(current, previous);

Then an onLoad Client Script reads it in the browser and shows the message:

// Client Script | Type: onLoad | Table: Incident
function onLoad() {
    if (g_scratchpad.isVipCaller) {
        g_form.showFieldMsg('caller_id', 'This caller is a VIP', 'info');
    }
}

How to pick the right type

When you are unsure, ask yourself what your code needs to do:

Change a field on this same record? Use before.
Change other records, or fire an event? Use after.
Do something slow, like calling another system? Use async.
Send extra data to the form for Client Scripts? Use display.

Practice: which type would you use?

Time to test your instincts. These are the kinds of situations you will meet on real projects, and in interviews.

PracticeWhich type of Business Rule would you use?

Read each scenario and pick the type that fits. On a computer you can also drag a scenario onto a type.

When a new incident is created, copy the caller's location into the incident's Location field.
Answer: before. You are changing a field on the same record that is being saved, so a before rule can set it and ServiceNow saves it with the record.
When an incident is resolved, close all of its open child tasks.
Answer: after. The child tasks are other records. Update them once the incident itself is safely saved, in an after rule.
Send every new Priority 1 incident to an external monitoring tool over REST.
Answer: async. Calling another system can be slow. An async rule does it in the background, so the agent never waits.
Show a warning on the incident form when the caller already has three or more open incidents.
Answer: display. Counting open incidents needs the database. A display rule counts them on the server and passes the result to the form through g_scratchpad.
Stop the save and show an error if the Short description is empty.
Answer: before. Only a before rule runs early enough to stop the record from being saved at all.
Fire an event so a notification emails the caller when their incident is reopened.
Answer: after. Fire events once the change is saved, so the notification never goes out for a save that later failed.
Rebuild a heavy monthly statistics record every time a change request is closed.
Answer: async. Heavy calculations should not slow down the person closing the change. Run them in the background.
Pass the caller's manager name to the form, so a Client Script can display it.
Answer: display. The manager lives on another record. A display rule looks it up on the server and hands it to the Client Script through g_scratchpad.

Quick check

You need to set a field on the same record just before it is saved. Which type of Business Rule do you choose?

Show answer

Before

A before rule can change current, and ServiceNow saves that change together with the record, with no extra update() call needed.

Was this lesson helpful?

Spotted a mistake, or a step that looks different in your instance?