ServiceNow Best Practices: How Business Rules Work: A Guide for ServiceNow Developers

Bill Martin · ‎01-30-2025

Business Rules are one of the most powerful tools in ServiceNow, allowing developers to control and automate business processes by interacting with data before or after records are saved.

Understanding the execution lifecycle of ServiceNow Business Rules is essential for designing efficient and effective automation within your instance.

In this article, we will cover:

What Are Business Rules?
Types of Business Rules
Business Rule Execution Flow
Order of Execution
Best Practices for Using Business Rules

1. What Are ServiceNow Business Rules?

A Business Rule is a server-side script that runs when a record is inserted, updated, deleted, or queried. Unlike Client Scripts that run on the user’s browser, Business Rules operate on the server, making them ideal for complex data processing and ensuring data integrity.

2. Four Types of ServiceNow Business Rules

ServiceNow provides four types of Business Rules based on when they execute:

Before: Executes before a record is saved to the database
After: Executes after a record is saved to the database
Async (Asynchronous): Executes after a record is saved but in a separate process, allowing faster user interaction
Display: Executes when a record is queried from the database, before it is sent to the client

Each type serves a specific purpose. For example, Before rules are often used for data validation, while After rules handle notifications, logging, or integrations.

3. ServiceNow Business Rule Execution Flow

The lifecycle of Business Rule execution is straightforward but follows specific stages depending on the type. Let’s break down each stage.

Before Insert, Update, or Delete

Before Business Rules execute when an event occurs (e.g., form submission or script action). Use this stage to manipulate field values or validate data before the database is updated.

Database Update

ServiceNow writes the record changes to the database once all Before Business Rules have completed.

After Insert, Update, or Delete

After Business Rules trigger after the record is saved. This is useful for sending notifications or updating related records.

ServiceNow Asynchronous Processing

Async Business Rules run in a separate thread after the record is saved, without delaying the user interaction. This is ideal for long-running operations such as integrations with external systems.

Display (On Query)

Display Business Rules are triggered when a record is fetched from the database. They can be used to provide dynamic information to the form or set default field values before the record is displayed.

4. ServiceNow Business Rule Order of Execution

The execution of server-side operations in ServiceNow follows a defined order:

Before Business Rules execute first
The record is inserted/updated/deleted in the database
After Business Rules are executed
Any Async Business Rules are queued for background execution
Display Business Rules run when a record is queried

Additionally, ServiceNow processes other elements such as:

Access Control Rules (ACLs) – Checked before records are queried or modified
Script Includes and Data Policies – Depending on your configuration, these may also influence record updates

5. ServiceNow Best Practices for Using Business Rules

To ensure optimal performance and maintainability, follow these best practices.

Minimize Database Operations
Avoid querying large data sets or performing heavy operations within a single Business Rule.

Use Async Rules for Long-Running Tasks
Offload time-consuming tasks like sending emails or calling APIs to Async Business Rules to avoid slowing down the user experience.

Avoid Overlapping Business Rules
If multiple Business Rules affect the same table and fields, ensure they don’t conflict with each other.

Test with Different Scenarios
Test Business Rules with both valid and edge-case scenarios to ensure data integrity is maintained.

Leverage Current and Previous Objects
Use the current and previous objects to compare and track changes in field values.

Conclusion

Business Rules play a vital role in automating processes and enforcing business logic within ServiceNow. By understanding when and how they execute, you can design more efficient and maintainable scripts. Always test thoroughly and follow best practices to ensure your Business Rules function as intended without impacting performance.

Got questions? Share your thoughts and experiences with Business Rules in the comments below!

Would you like to explore more about Business Rules or other topics? Check out my YouTube channel where I dive into ServiceNow development fundamentals!

Bill Martin · 2 weeks ago

Hi @apurva3 ,

Since you cannot use setWorkflow(false) due to compliance and auditing, you need to shift the synchronization logic away from synchronous processing to prevent hitting the transaction time limit.

Here are a few standard strategies to handle this:

1. Shift to an Async Business Rule

If you are currently using a Before or After Business Rule to sync the records, it runs on the user's thread and will easily timeout if there are many child records.

Change the Business Rule to Async.
This pushes the execution to the background (via the sys_trigger queue). It frees up the user session immediately and gives the system more processing time, all while maintaining the full audit trail and triggering necessary engine workflows.

2. Use a Scheduled Job with Batching

If the volume of parent-child records is exceptionally high, even an Async rule might time out if it tries to do everything at once.

Create a Scheduled Script Execution (Scheduled Job) that runs periodically.
Update your parent record to flip a custom flag (e.g., u_sync_needed = true).
Have the Scheduled Job query for records where u_sync_needed == true, process them in smaller chunks/batches (using glidrecord setLimit()), and flip the flag back to false once done.

3. Flow Designer (Asynchronous Action)

If you prefer a low-code approach, you can move this logic to Flow Designer.

Trigger the flow when the parent record is updated.
Use the For Each logic to update child records. Flows inherently execute asynchronously in the background, keeping the user interface fast and preserving the audit data logs.

4. Check for Infinite Loops

Double-check that your synchronization logic isn't accidentally re-triggering itself. If a parent updates a child, and a child business rule updates the parent back, you will hit the time limit due to a recursion loop. Ensure your Business Rule conditions are specific (e.g., use current.<field name>.changes()) so they only run when absolutely necessary.

View solution in original post

apurva3 · 2 weeks ago

The volume is not fixed some time it can be 1000+ child, i use count to divide loops, use updateMultiple() and event+ script action(for chunk) in after BR.

apurva3 · 2 weeks ago

Can Flow Designer support 1000+ volume?