Delaying Business Rule Execution in ServiceNow

Are you looking to control the timing of your ServiceNow business rules? Perhaps you need a delay before a script runs, especially when integrating with external systems. Understanding how to manage business rule execution order and timing is crucial for building robust and efficient ServiceNow applications. This article will explore the reasons for delaying business rules and provide verified methods to achieve this, helping you optimize your ServiceNow workflows.

Understanding the Need to Delay Business Rules in ServiceNow

By default, ServiceNow business rules execute immediately when a record is updated and the defined conditions are met. However, there are scenarios where delaying the execution is beneficial or even necessary. A common use case is when integrating ServiceNow with external systems via web services or SOAP.

Consider this scenario: A record is inserted into ServiceNow, triggering an update to an external system. Immediately after, the user might approve the record, leading to another update being sent to the same external system. If the initial update is still in progress, the second update might cause conflicts or errors. Delaying the second update by a few seconds can prevent these issues by allowing the first process to complete. This type of situation requires careful timing and execution control.

Verified Methods for Delaying Business Rule Execution

Here are verified and safe methods for delaying the processing of business rules in ServiceNow. It's important to note that delaying server-side scripts can impact system performance, so carefully consider the implications before implementing these solutions.

1. Using Asynchronous Business Rules:

The most recommended and safest way to delay a business rule is to configure it as an "async" business rule. Asynchronous business rules are placed on the event queue and executed by a background process, allowing the current transaction to complete without waiting for the business rule to finish.

Steps to create an Async Business Rule:

1. Navigate to System Definition > Business Rules.

2. Click New to create a new business rule.

3. Fill in the required fields like Name, Table, etc., based on your specific requirements.

4. Under the When to run section:

   • Select async under the "When" options

   • Define your conditions as normal.

5. Write your script in the Advanced tab.

6. Click Submit.

   
   

By setting the business rule to "async," you effectively delay its execution until the system resources are available to process it in the background. This prevents immediate execution and allows other processes to complete first. The actual delay time will depend on system load and the priority of other queued jobs.

2. (Generally NOT Recommended) Using gs.sleep() (Use with Caution)

The gs.sleep() function pauses the execution of the script for a specified number of milliseconds. While this provides direct control over the delay, it is strongly discouraged in most production environments. This is because gs.sleep() blocks the server thread, potentially impacting performance and responsiveness for all users.

If you must use gs.sleep(), keep the delay as short as possible and thoroughly test its impact on system performance.

Example:

// Delay for 15 seconds (15000 milliseconds)
gs.sleep(15000);

Important Considerations for gs.sleep()

• Performance Impact: Excessive use of gs.sleep() can severely degrade ServiceNow performance.

• Alternatives: Explore alternative solutions like async business rules or scheduled jobs before resorting to gs.sleep().

• Global Scope: gs.sleep() only works when the Business Rule is executing in the Global Scope, or the same scope the GlideSystem API is defined in.

  
  

3. (Generally NOT Recommended) Implementing a Custom Pause Function (Use with Extreme Caution)

Another method involves creating a custom function that pauses the script execution using a loop and GlideDateTime. Like gs.sleep(), this method consumes server resources and can negatively impact performance. Therefore, it should only be used as a last resort and with extreme caution.

Example:

function pause(time) {
  var t1 = new GlideDateTime().getNumericValue();
  var t2 = new GlideDateTime().getNumericValue();
  var duration = t2 - t1;
  while (duration < time) {
    t2 = new GlideDateTime().getNumericValue();
    duration = t2 - t1;
  }
}

// Delay for 15 seconds (15000 milliseconds)
pause(15000);

Important Considerations for Custom Pause Function

• Resource Intensive: This method consumes significant CPU resources.

• Accuracy: The actual delay might vary slightly due to system load and other factors.

• Not Recommended: This method is generally not recommended for production environments.

  
  

Choosing the Right Approach

Selecting the appropriate method depends on your specific requirements and constraints. Here's a quick guide:

• Prioritize Async Business Rules: For most scenarios, using asynchronous business rules is the preferred and recommended approach.

• Avoid gs.sleep() and Custom Pause Functions: These methods should only be used as a last resort when other options are not feasible. If you use it, consider the impact.

• Scheduled Jobs: If a longer delay or scheduled execution is required, consider using a scheduled job instead of a business rule.

  
  

Delaying business rule execution in ServiceNow requires careful consideration of the available methods and their potential impact on system performance. While options like gs.sleep() and custom pause functions provide direct control over the delay, they are generally not recommended due to their resource-intensive nature. Async business rules offer a safer and more efficient alternative for most scenarios. By understanding the trade-offs and choosing the appropriate method, you can effectively manage business rule timing and optimize your ServiceNow workflows.

Next Steps

1. Analyze your specific use case and determine the most appropriate method for delaying business rule execution.

2. If possible, always use asynchronous business rules for delay purposes.

3. Thoroughly test any changes in a non-production environment before deploying them to production.

4. Monitor system performance after implementing any delay mechanisms to ensure they do not negatively impact responsiveness.