Difference between After vs Async Business Rules in ServiceNow: The Complete Guide

adityahubli · yesterday

If you're working with ServiceNow Business Rules, you've probably encountered both After Business Rules and Async Business Rules. They might seem similar since both execute after a record is saved, but they work very differently under the hood.

Understanding these differences is crucial for building efficient workflows and avoiding common pitfalls—especially when dealing with notifications.

Let's break it down.

1. Execution Style: Synchronous vs Asynchronous

After Business Rule → Runs Synchronously

Waits for the previous step to complete before moving to the next
Executes step-by-step in sequence
The user must wait until all operations finish

Async Business Rule → Runs Asynchronously

Does NOT wait for the previous task to complete
Runs in the background
The user gets an immediate response while tasks continue processing

2. Transaction Handling: Same vs Separate

What is a Transaction?

A transaction is a set of actions executed together and treated as one single operation. If one part fails, the entire transaction can be rolled back.

After Business Rule → Uses the Same Transaction

All steps are part of one transaction
Each step depends on the previous one completing successfully
Ensures strict order and data integrity

Async Business Rule → Uses a Separate Transaction

Runs in a separate background transaction (queued)
Independent from the main transaction
Doesn't block the user interface

3. Real-World Examples

Example 1: After Business Rule

Use Case: After saving a parent task, a child task should get updated.

Since After BR runs synchronously in the same transaction, it ensures the child task update happens immediately and in the correct order.

Example 2: Sending Notifications

Use Case: Send a notification after a record is saved.

Here's where things get interesting. Let's say you're working with a Problem record and need to:

Steps:

Create Problem
Create Problem Task
Create relationship (link Problem and Problem Task)
Send Notification

4. Why After BR Can Cause Issues with Notifications

With After Business Rule (Same Transaction):

Since After BR uses the same transaction, the execution flow looks like this:

i.   Create Problem      
         ↓ (wait...)
ii.  Create Problem Task    
        ↓ (wait...)
iii. Create Relationship (link Problem and Problem Task)     
       ↓ (wait...)
iv.  Send Notification

The Problem:

Until step iii (creating the relationship) is fully executed and completed, step iv (send notification) will NOT execute.

Why This Matters:

If step iii takes time or encounters an error, the notification gets delayed or may not send at all
Users experience slower response times
The entire transaction is blocked until every step completes

This is why After BR is NOT recommended for sending emails or notifications.

5. Why Async BR Is Perfect for Notifications

With Async Business Rule (Separate Transaction):

Async BR uses a separate transaction that runs in the background queue. Here's how it works:

i.   Create Problem      
           ↓
ii.  Create Problem Task      
          ↓
iii. Create Relationship (executes in background)      
         ↓
iv.  Send Notification (starts immediately, doesn't wait for step iii)

The Advantage:

Step iii executes in the background
Step iv (notification) starts executing immediately
User doesn't experience any delay
Notification is sent without waiting for the relationship creation

Quick Comparison Table

Aspect After BR Async BR

Execution	Synchronous (waits)	Asynchronous (background)
Transaction	Same transaction	Separate transaction
Speed	Slower	Faster
Dependency	Sequential (one after another)	Independent
Best For	- Updating child records - Data validation - Field calculations	- Sending notifications - API calls - Heavy background tasks

When to Use Each Type

Use After Business Rule When:

You need strict sequential execution
Child records must be updated immediately after parent
Data integrity is critical
Operations depend on each other

Use Async Business Rule When:

Sending emails or notifications
Making API calls
Running heavy background processes
User response time is important
Operations can run independently

Key Takeaway

For notifications and emails → Always use Async Business Rules

Why? Because Async BR:

Uses a separate transaction
Doesn't wait for previous steps
Ensures fast and reliable notification delivery
Provides better user experience