ServiceNow Business Rules: Best Practices for Using After Business Rules

Business Rules in ServiceNow are essential scripts that execute on the server-side when records are inserted, updated, or deleted. Among these, "After" Business Rules are commonly employed for updating related records after a database transaction completes. However, improper use of 'After' Business Rules—especially calling current.update()—can lead to severe performance issues, including unintended recursion and system slowdowns. This article explains why this practice causes problems, offers verified troubleshooting solutions, and provides best practices to optimize your ServiceNow instance.

Understanding the Problem: Recursive Calls in After Business Rules

A common error in ServiceNow development occurs when developers use the current.update() method inside "After" Business Rules. Such use inadvertently triggers the same Business Rules repeatedly, creating an infinite recursive loop. ServiceNow detects and halts these recursive calls, but not before negatively affecting performance and system stability.

For instance, consider a scenario:

• A document record is created, and the approver field is filled.

• An "After" Business Rule executes to update the document stage from "draft" to "in progress."

• If incorrectly implemented, the Business Rule uses current.update(), causing itself to trigger again repeatedly.

  
  

Best Practices for Preventing Recursive Business Rules

1. Avoid Using current.update() in After Business Rules

The primary rule is straightforward: never call current.update() in an "After" Business Rule. Changes to the current record should typically occur in a "Before" Business Rule, where updates naturally commit to the database without explicit calls.

2. Using Conditions to Prevent Recursion

If updating fields must occur after a transaction, ensure your "After" Business Rules use clear conditions to avoid recursion:

• Example Condition:

if (current.state == 'draft' && current.approver.changes()) {
	current.setValue('state', 'in progress');
	// Directly modifying the field avoids explicit update() calls.
}

Here, the condition ensures the Business Rule executes only once when the state is "draft," preventing multiple recursive calls.

3. Leverage Asynchronous Business Rules When Appropriate

Async Business Rules run independently in the background and do not delay user interactions. They are ideal for tasks that aren't required immediately, such as logging activities, SLA updates, or integrations with third-party services.

• Example Use Case:

  • Triggering a customer satisfaction survey after resolving an incident.

  • SLA updates

  • Integration with external systems

    
    

4. Utilize Script Includes Instead of Global Business Rules

Instead of global Business Rules that load system-wide, employ Script Includes. Script Includes only execute when explicitly called, significantly reducing overhead.

• Example Implementation:

// Script Include 
var AssignmentGroupUtils = Class.create(); 
AssignmentGroupUtils.prototype = { 
	initialize: function() {}, 
	getUserGroups: function(userId) { 
		var groups = []; 
		var gr = new GlideRecord('sys_user_grmember');	
         gr.addQuery('user', userId); 
         gr.query(); 
         while (gr.next()) { 
            groups.push(gr.group.toString());
         } 
		return groups;
	}, 
	type: 'AssignmentGroupUtils'
}; 
// Call Script Include 
// var userGroups = new AssignmentGroupUtils().getUserGroups(current.assigned_to);

5. Keep Business Rule Logic Within Scoped Functions

Always wrap your Business Rule logic in a scoped function to prevent conflicts and global variable issues.

• Correct Implementation:

(function executeRule(current, previous) { 
	var grInc = new GlideRecord('incident'); 
	grInc.addQuery('active', true); 
	grInc.query(); 
	while (grInc.next()) { 
		// Processing logic here 
	} 
})(current, previous);

This approach restricts variable scope, reducing potential interference from other scripts.

6. Optimize Database Operations with GlideAggregate

Replace inefficient GlideRecord operations for counting records with GlideAggregate, which is optimized for database operations.

• Example:

// Before
var gr = new GlideRecord('incident');
gr.query();
var count = 0;
while (gr.next()) {
    count++;
}
gs.log("Total incidents: " + count);

// After
var agg = new GlideAggregate('incident'); 
agg.addAggregate('COUNT'); 
agg.query(); 
if (agg.next()) { 
	var count = agg.getAggregate('COUNT'); 
	gs.log("Total incidents: " + count); 
}

Conclusion

Proper use of Business Rules, especially "After" Business Rules, significantly enhances ServiceNow's performance and reliability. Always avoid recursive pitfalls by preventing the use of current.update() within "After" Business Rules. Utilize conditions, async Business Rules, Script Includes, and scoped functions strategically to optimize your system.

• Avoid calling current.update() in "After" Business Rules.

• Define clear conditions to prevent unnecessary executions.

• Use asynchronous (Async) Business Rules when appropriate.

• Avoid global Business Rules and utilize Script Includes instead.

• Use scoped functions to prevent variable conflicts.

• Optimize database queries to improve performance.

  
  

Next Steps

• Audit existing "After" Business Rules in your ServiceNow instance.

• Replace current.update() calls with appropriate conditional logic or async operations.

• Implement Script Includes to centralize reusable logic.

• Continually monitor system logs to identify recursive or inefficient Business Rules early.