Business Rule Types Explained: Before, After, Async, and Display

Choosing the wrong Business Rule type causes subtle, hard-to-debug problems. A Before rule that should be Async will slow down form saves. An After rule that should be Before will run too late to affect the current record. Here is exactly when each type fires.

Before Business Rules

Before rules run before the record is saved to the database. The current object contains the new values being saved — you can still modify them.

Use Before rules when you need to: modify field values before they are saved, validate data and abort the save if invalid, set audit or computed fields.

(function executeRule(current, previous) {
    // Set resolved_at when state changes to Resolved
    if (current.state == 6 && previous.state != 6) {
        current.resolved_at = new GlideDateTime();
    }
})(current, previous);

Important: In a Before rule, call current.update() only if you need to save additional changes beyond what the triggering save will already commit. Usually you just set values on current and the platform saves them automatically.

After Business Rules

After rules run after the record has been saved to the database. current still has the values, but modifying it requires an explicit current.update().

Use After rules when you need to: create or update related records after the primary record saves, send notifications based on the saved state, trigger integrations.

(function executeRule(current, previous) {
    // Create a task when an incident reaches In Progress
    if (current.state == 2 && previous.state == 1) {
        var task = new GlideRecord('task');
        task.parent = current.sys_id;
        task.short_description = 'Review incident ' + current.number;
        task.insert();
    }
})(current, previous);

Async Business Rules

Async rules run after the record saves, but in a separate thread — they do not block the user waiting for them to complete. They are queued and run by the scheduler.

Use Async rules for: expensive operations (complex queries, large updates), sending emails or notifications, calling external systems, anything where a slight delay is acceptable.

(function executeRule(current, previous) {
    // This runs asynchronously - user doesn't wait for it
    var result = callExternalAPI(current.sys_id);
    gs.log('External call result: ' + result);
})(current, previous);

Critical: In Async rules, current.update() causes an additional save — be careful to avoid loops. Async rules also cannot modify the record that triggered them without calling update.

Display Business Rules

Display rules run when a record is loaded in the form view, before it renders. They are the only server-side rule that can send data to client scripts via g_scratchpad.

(function executeRule(current, previous) {
    // Send data to the client without GlideAjax
    g_scratchpad.is_vip = (current.caller_id.vip == true);
    g_scratchpad.group_count = getGroupCount(current.caller_id);
})(current, previous);

Client Script then reads: var isVip = g_scratchpad.is_vip;

Use Display rules to pre-load data you will need client-side, avoiding a GlideAjax round-trip when the form loads.

Quick decision guide

  • Modify the current record before save → Before
  • Create related records after save, user waits → After
  • Expensive work, user should not wait → Async
  • Send data to Client Scripts → Display

Want the complete reference?

This article is part of the NowSpectrum knowledge library. Browse all products for cheat sheets, interview prep, and deep-dive reference guides.

Browse All Products →