🧠 Mastering Business Rules in ServiceNow: Types, Use Cases & Best Practices

[Bhavesh Patil]

Hey #ServiceNowCommunity 👋

If you've ever customized logic in ServiceNow on record creation, update, or retrieval—chances are you've already worked with Business Rules.

In this post, we'll deep-dive into Business Rules: what they are, the different types, how they're executed, and where they shine best in real-world use cases.

---

✅ What is a Business Rule?

A Business Rule in ServiceNow is a server-side script that runs when a record is inserted, updated, deleted, or queried. It's designed to enforce business logic on data stored in ServiceNow tables.

They are executed on the server, meaning they do not directly manipulate the client UI, but they can shape what data is fetched, updated, or how operations are handled in the background.

---

🧩 Types of Business Rules

ServiceNow supports four main types of Business Rules, triggered at different points in the record lifecycle:

Type	Trigger Point	Common Use Case
Before	Before a record is saved	Modify data before insert/update
After	After a record is saved	Trigger events, logging, etc.
Async	After commit (in background)	Long-running processes like notifications
Display	Before form is loaded	Pass data from server to client using g_scratchpad

---

🧪 Business Rule Types with Examples

🔹 Before Business Rule : 
Before business rules execute after the form submission and before the record update or save in the database.

🧠PRO TIP : In Before BR no need to use current.Update() method. Because it executes before the database operation.

Use to set default values or clean data before saving.

// Example: Set priority based on impact & urgency
(function executeRule(current, gForm, gUser, gs) {
    if (!current.priority) {
        current.priority = calculatePriority(current.impact, current.urgency);
    }
})(current, gForm, gUser, gs);

---

🔹 After Business Rule

After business rules execute after the form submission and after the record update or save in the database. It runs After the database operation.

🧠PRO TIP : It's recommended to avoid using current.update() in After Business Rules to prevent potential recursive execution of Business Rules
In rare situations, where the standard "Before" and "After" Business Rule guidelines don't meet your needs, you might need to use current.update() in conjunction with setWorkflow(false) to control when and how Business Rules are triggered. 

Used to initiate actions post data commit like sending emails or creating audit logs.

// Example: Send notification after incident is created
(function executeRule(current, previous) {
    gs.eventQueue("incident.created", current, current.assigned_to, gs.getUserID());
})(current, previous);

---

🔹 Async Business Rule

Async Business Rules run after records are inserted or updated. Async and after Business Rules works similarly the only difference is async runs asynchronously as Scheduled Jobs. & After business rule runs synchronously. So this is the basic difference between them.

🧠PRO TIP : Whenever we don’t want instant/ immediate results or records then at that time we should prefer to use Async BR.

Executes in the background—useful for heavy logic that shouldn't block the user.

// Example: Call external API after record insert
(function executeRule(current, previous) {
    new GlideHTTP().get("https://external.api/notify?id=" + current.sys_id);
})(current, previous);

---

🔹 Display Business Rule
Display BR runs while form is ‘loading’& Just after the data is read from the database.

Runs before a form loads and is used to send server-side data to the client using g_scratchpad.

// Example: Send approval status to client script
(function executeRule(current, gForm, gUser, gs) {
    g_scratchpad.isApproved = current.approval == "approved";
})(current, gForm, gUser, gs);

---

🕵️‍♂️ Before Query Business Rule

A special type of Before Business Rule that runs when a query is made on a table (e.g., list view, reference field).

Enable it using the checkbox: When to Run → Advanced → Query checked.

// Example: Restrict access to incidents based on location
(function executeRule(current, gForm, gUser, gs) {
    current.addQuery("location", gs.getUser().getLocation());
})(current, gForm, gUser, gs);

🟡 Note: This doesn’t restrict access like ACLs but filters data visibility in queries.

---

⚔️ Difference Between Before Query BR and ACL

Feature	Before Query BR	ACL
Purpose	Filter data on query	Enforce security at table/field level
Execution	On GlideRecord queries	On every access (read, write, create)
Bypassable?	Yes, via direct GlideRecord	No (hard security)
Where Used?	List views, reference fields	Everywhere (UI, API, script, export)

✅ Use ACL for security, Before Query BR for filtering results.

---

📤 Display Business Rule & g_scratchpad : 

A Display Business Rule is the only Business Rule that can communicate server-side data to client-side scripts using g_scratchpad.

📌 Use Case: Send calculated values, flags, or user roles to client scripts without an extra AJAX call.

g_scratchpad.isVIPUser = gs.hasRole("vip_user");

Then in Client Script:

if (g_scratchpad.isVIPUser) {
    g_form.setDisplay('vip_message', true);
}

---

🧠 Best Practices for Business Rules

✅ Keep logic simple and focused
✅ Use Async for long-running actions
✅ Avoid current.update() inside BRs
✅ Never use BRs for client-side UI changes
✅ Prefer Display BR + g_scratchpad over GlideAJAX when possible
✅ Avoid unnecessary BRs—use Flow Designer or Script Includes when applicable
✅ Use naming conventions for maintainability (BR - <table> - <type> - <description>)

---

💡 5 Real-Time Use Cases of Business Rules

1. Auto-assign incidents based on category using a Before BR.

2. Trigger events to notify stakeholders when a change request is approved (After BR).

3. Call 3rd-party APIs to sync user info post user creation (Async BR).

4. Restrict records shown in related lists to user’s department (Before Query BR).

5. Set approval visibility flags on form load using Display BR + g_scratchpad.

---

🚀 Final Thoughts

Business Rules are powerful tools in the ServiceNow platform that can transform data behavior, trigger workflows, and control system logic behind the scenes. Understanding their types and proper usage is critical for any ServiceNow Developer aiming to build scalable and maintainable solutions.

💬 Have a unique Business Rule use case or challenge? Let’s discuss it in the comments!

 **Please mark it as *Helpful* or *Correct* — it really means a lot!**