Business Rule Actions & Basic Script Execution

Now that we know the basics of business rules and how they are created, it is time to understand the ways to enforce them. 

In this topic, we will be focusing on ServiceNow Business rule actions and business rule scripts. 

What are ServiceNow Business Rule Actions?

Business Rule actions in ServiceNow are low-code responses for database events. They allow admins to automate multiple tasks, including setting field values, stopping database operations, or displaying messages on screen without complex code.

These can be configured in three ways: 

• Set field values: The Set field values option allows setting field values without scripting.
• Add a message to a form: Use the Add message field to add a message to the top of a page.
• Abort the Business Rule execution: The Abort action option stops execution of the Business Rule and aborts the database operation.

How to write a business rule?

Authoring a Business Rule in ServiceNow requires configuring both its execution parameters and the logic it enforces. The following steps outline the standard development process.

Step 1: Access the Business Rule Form

Navigate to System Definition → Business Rules and select New to open a blank Business Rule record.

Step 2: Define the Core Properties 

• Name → A clear and descriptive identifier.
• Table → The target database table to which this rule applies.
• Active → Must be enabled for the rule to participate in transaction processing.
• Advanced → Must be enabled to author custom server-side JavaScript logic

Step 3: Configure the Execution Timing

The When field governs the point within the database transaction at which the rule executes:

• Before → Executes prior to the record being committed to the database. Recommended for field validation and value manipulation.
• After → Executes following the database commit. Recommended for operations on related records.
• Async → Executes asynchronously in a background thread after the commit. Recommended for resource-intensive or non-time-critical operations.
• Display → Executes before the form is rendered on the client. Used to pass server-side data to client scripts via the ‘g_scratchpad’ object. 

Step 4: Specify the Database Operation

Select one or more operations that will trigger rule execution:

• Insert → Triggered when a new record is created
• Update → Triggered when an existing record is modified
• Delete → Triggered when a record is removed from the database
• Query → Triggered when a record is retrieved or displayed

Step 5 – Define Filter Conditions

Filter Conditions restrict rule execution to specific scenarios, reducing unnecessary processing and improving platform performance. Conditions should be defined wherever possible to ensure the rule fires only under the intended circumstances.

Example: Execute only when the State field changes to Resolved.

Step 6: Author the Script

With Advanced mode enabled, business logic is implemented within the standard executeRule function using server-side JavaScript.

Step 7: Save and Activate

Select Submit to persist the configuration. Confirm that the Active checkbox is enabled prior to saving to ensure the rule is included in transaction processing.

How to test business rule in servicenow?

Thorough testing is essential to confirm that a Business Rule executes under the correct conditions, produces the intended data outcomes, and does not introduce unintended side effects such as recursive execution or degraded performance. ServiceNow provides several testing mechanisms suited to different validation requirements. There are different ways to test a business rule, including: 

Method 1: Direct Record Testing

The most straightforward approach involves manually triggering the rule by performing the associated database operation on a test record.

1. Navigate to the target table (e.g., open an Incident record)
2. Perform the operation that satisfies the rule’s trigger conditions (e.g., modify the State field and select Update)
3. Confirm that the expected field changes, messages, or behaviors are reflected on the record.

(Suitable for rapid validation of simple, low-risk Business Rules in a non-production environment.)

Method 2: Runtime Logging via gs.log() and gs.addInfoMessage()

1. Logging statements can be embedded within the script to surface runtime values and confirm execution flow.
2. Log output is accessible via System Logs → Application Logs.
3. Recommended when verifying the state of current and previous object values at the time of execution.

Method 3: Background Script Execution

1. The Scripts – Background module allows developers to execute isolated server-side logic without modifying live records, making it a safe environment for pre-deployment validation.
2. Navigate to: System Definition → Scripts – Background
3. (Recommended for safely isolating and validating Business Rule logic prior to deployment.)

Method 4: Business Rule Debugger

ServiceNow’s built-in Business Rule Debugger provides transaction-level visibility into all rules that are executed during a given operation, including their sequence, duration, and any errors encountered.

1. Create Breakpoints from where, till where you want the debugger to execute. 
2. After adding breakpoints, Use Script Debugger. 
3. Now, Execute the Business Rule, You will notice that the Debugger started the execution of the Script line by line. 

Objects used in Business Rules

1. Current: The current object’s properties are all the fields for a record and all the GlideRecord methods. The property values are the values as they exist in the runtime environment.
2. Previous: The previous object’s properties are also all fields from a record and the GlideRecord methods. The property values are the values for the record fields when they were loaded from the database and before any changes were made.

Conclusion

Business rules in servicenow are server-side scripts used to enhance the way a table or record is assisted for when searched. There are different ways to create business rule and add them to your instance. 

The chapter focuses on the creation of business rules and ways to test business rules. In the next chapter we will be focusing on the notifications and events in ServiceNow.