ServiceNow is a powerful platform that helps organizations streamline IT services and business operations. One of its core features is Business Rules—server-side scripts that run when records are inserted, updated, deleted, or queried.In this blog, we’ll break down what Business Rules are, why they matter, and how you can write your own using simple code snippets. Whether you’re new to ServiceNow or brushing up your skills, this post aims to be both practical and beginner-friendly.

What Is a Business Rule?

In ServiceNow, a Business Rule is a piece of JavaScript code that executes on the server when certain conditions are met. These are mostly used to enforce data consistency, automate tasks, or perform complex validations.

Key things Business Rules can do:

Modify record data before it’s saved

Stop a record from being saved if certain conditions fail

Trigger other scripts or workflows

Automatically fill or adjust field values

Types of Business Rules

There are four main types of Business Rules in ServiceNow:

Before – Runs before a record is saved to the database

After – Runs after the record is saved

Async – Runs after the record is saved but asynchronously

Display – Runs when a form is loaded (before it’s displayed to the user)

Let’s see how they work in action.

Example 1: Auto-Populate a Field with a “Before” Rule. Let’s say we want to automatically fill the short description field in an incident if it’s left blank.

(function executeRule(current, previous) {    
if (!current.short_description) 
{        
current.short_description = "Auto-generated description for incident: " + current.number;    
}
})(current, previous);

Explanation: This is a Before Business Rule.We check if short_description is empty.If it is, we populate it using the incident number.

Example 2: Prevent Record Submission with an Error Message. Let’s stop an incident from being submitted if the impact is high but no urgency is selected.

(function executeRule(current, previous) {    
if (current.impact == 1 && !current.urgency) 
{        
gs.addErrorMessage("Urgency is required when impact is High.");        current.setAbortAction(true);    
}
})(current, previous);

Explanation: gs.addErrorMessage() shows a message to the user.current.setAbortAction(true) cancels the save action.

Example 3: Use an “After” Rule to Log Changes. Maybe we want to log every time a Priority 1 (P1) incident is created.

(function executeRule(current, previous) 
{    
if (current.priority == 1) 
{        
gs.log("P1 Incident Created: " + current.number);    
}
})(current, previous);

Explanation: This rule runs after the incident is saved.It logs a message in the system logs (not visible to end users).

Example 4: Async Rule for External Integration. Use Async Business Rules when calling external APIs or doing performance-heavy tasks.

(function executeRule(current, previous) 
{    
var request = new sn_ws.RESTMessageV2();    request.setEndpoint("https://api.example.com/end-point");    request.setHttpMethod("POST");    
request.setRequestHeader("Content-Type", "application/json");    request.setRequestBody(JSON.stringify(
{        
number: current.number,        
description: current.short_description    
}
));    
var response = request.execute();
})(current, previous)

Note: Since it’s async, it won’t delay the user action, which is great for API calls.

Example 5: Display Rule for Client-Side Info. A Display rule lets you send server-side data to the client form.

(function onDisplay(current, previous) 
{    
g_scratchpad.isVIP = current.vip;
})(current, previous);

On the client side (Client Script), you can then use:

var isVIP = g_scratchpad.isVIP;
if (isVIP) 
{    
alert("VIP User!");
}

Tips for Writing Better Business Rules

Use conditions wisely: Don’t run code when it’s not needed. Use conditions in the Business Rule configuration (not just in the script).

Avoid long scripts: If your logic is complex, move it into a Script Include and call it.

Async vs Sync: Always prefer Async for time-consuming tasks.

Don’t duplicate logic: Try to centralize validations in one place (e.g., Script Includes or Data Policies).

When Not to Use a Business Rule

For client-side UI interactions, use Client Scripts.

For form field requirements, prefer UI Policies or Data Policies.

For scheduled actions, use Scheduled Jobs or Flow Designer.

Wrapping Up

Business Rules are a powerful feature in ServiceNow for handling server-side logic. With a few lines of JavaScript, you can automate processes, enforce data integrity, and even integrate with external systems.Whether you’re writing a simple validation or designing a multi-step workflow, understanding Business Rules is essential for effective ServiceNow development.

If you’re interested in a follow-up post on best practices or advanced use cases like Script Includes, Flow Designer integration, or GlideRecord usage in Business Rules, let me know! Happy scripting!