Business Rules

This article is a supplement to the ServiceNow documentation. For full documentation please refer ServiceNow official website

Checkout our NEW Video Channel you can like and subscribe too!

Introduction

Business Rule is a piece of JavaScript configured to run when a record is displayed, inserted, updated, deleted, or when a table is queried.

A Business Rule can be set to run before or after the database action has occurred. Unlike UI policies, Business Rules do not monitor fields on a form

Each Business Rules includes what table to run against and timing (before or after insert and more), what condition to evaluate, what script to run based on the evaluation, and if it is client-callable.

Business Rules run on the server, but can be client callable. If the Client callable setting is checked, the client can use AJAX to call the Business Rule.

Business Rules are consistently applied to records regardless of how they are accessed-through forms, lists, or Web Services. This is one major difference between Business Rules and Client Scripts,

Business Rules are not real-time:
	They do not monitor filed on a form
	They monitor records as there are inserted or updated.

When Do Business Rules Execute?

The When setting lets you select when the Business Rule should execute:

After a record is saved to the database.Business Rules execute after form submission and after the record update in the database.Cascade changes made to approval filed of service catalog request to the RITMs attached to the request.

Before a record is saved to the database.Business rules execute after form submission and before the record update in the database. Example: Calculation of priority based on impact and urgency

Before Query Before query Business Rules execute before a query is sent to the database. When a user is not authorized to see all records in a list, the “Number of row removed by security constraints” message appears. Before query Business Rules act like ACL and prevents users from seeing certain records. When access is controlled through a before query Business Rule ,the “Number of row removed by security constraints” message is not displayed and the user does not know access is restricted.

Async(queued) Async Business Rules run after records are inserted/modified/queried.Run asynchronously asScheduled Jobs.Async Business Rules are queued by the scheduler to run as soon as they can be fit in.This allows the current transaction to finish without waiting for the rule.

SLA calculation are another example of Async Business Rules.

Caution: if using the Delete action on Async Business Rule, the record will not exist when the script runs.

We can see Async Business Rule queued up for execution as below

System Scheduler >Scheduled Jobs>Scheduled Jobs

Asysnc Business Rules appear with their names prepended with ASYNC. async business rules241120191.JPG

Example:

SLA calculation Notify CI owner if a CI is added as an Configuration Item to an Incident

Try to use Async Business Rule instead of After Business Rule when immediate response is not required.

Example:

Problem Statement:

Notify CI owner if a CI is added as an Configuration Item to an Incident

Solution:

Create a event in Event Registry Named “notify.ci.owner”
Create a notification named “Notify CI Owner”
Create a Async Business rule “Call event “notify.ci.owner”” to call event “notify.ci.owner”

Event Registry

Notification

Business Rules async business rules241120192.JPG

Go to Incident table and update CI of one incident async business rules241120196.JPG

Go to email log and check async business rules241120194.JPG

display before the record is displayed (this can utilize a scratchpad area to access server data).Display Business Rules run after the data is read from the database and before the form is presented to the user.Display Business Rules execute when a user requests a record form. Data is read from the DB. The display rules are executed and finally the form is presented to the user.

g_scratchpad is like global variables that can be populated by a Display Business Rule.
this object is then passed to client side.

For example, sys_created_by field is not part of incident form. To access the value from client script we have to make a server call. Server calls are expensive so it is advices to load populate this value using Display Business rule and pass it to the client.

Example:

Manager field in the Incident Form should be only visible to the user if user is member of service Desk group.

Business Rules:

Then we will write one onload client script and pass the g_scratchpad.AnyValue

Steps to create Business Rules

To create Business rules in left navigation pane write Business Rules. Business Rules comes under system definition
Click on New button to create a Business Rules.
If we select the advanced button, we will get the advanced tab to write a script.
If you want to create a record or update a record in incident table, then if you want to run script before or after the creation /updating the record you can use the business rules.

Examples of Business Rules

If the attachment is duplicate in service portal's catalog item then we can use the below BR

(function executeRule(current, previous /*null when async*/) {
	var gr =new GlideRecord('sys_attachment');
	gr.addQuery('table_name','LIKE','sp_portal');
	gr.addQuery('file_name','=',current.file_name);
	gr.orderBy('table_sys_id');
	gr.orderByDesc('sys_created_on');
	gr.query();
	
	//gs.addInfoMessage("current filename"+current.file_name);
	//gs.addInfoMessage("current datetime"+current.sys_created_on);
	//gs.addInfoMessage("current sys_id"+current.table_sys_id);
	
	while(gr.next()){
		
		//gs.addInfoMessage("IN TABLE"+gr.file_name);
		//gs.addInfoMessage("IN TABLE"+gr.sys_created_on);
		//gs.addInfoMessage("IN TABLE"+gr.table_sys_id);
		
		if(gr.table_sys_id==current.table_sys_id){
			gr.deleteRecord();
		}
	}
	
})(current, previous);

Update Assignment group in Request table from SCTASK using BR

(function executeRule(current, previous /*null when async*/) {
	
	// Add your code here
	var sctask = new GlideRecord('sc_task');
	sctask.addQuery('number', current.number);
	sctask.query();
	//sctask.setWorkflow(false);
	if (sctask.next()) {
		
		//gs.print(sctask.u_primary_affected_site);
		//gs.print("SC_TASK" + sctask.number);
		//gs.print(sctask.assignment_group.getDisplayValue());
		//gs.print(sctask.request_item.getDisplayValue());
		
		
		var ritm = new GlideRecord('sc_req_item');
		
		ritm.addQuery('sys_id', sctask.request_item);
		ritm.query();
		//ritm.setWorkflow(false);
		if (ritm.next()) {
			
			//gs.print("RITM" + sctask.request_item.getDisplayValue());
			//gs.print("REQ" + ritm.request.getDisplayValue());
			ritm.assignment_group = sctask.assignment_group;
			var req = new GlideRecord('sc_request');
			req.addQuery('sys_id', ritm.request);
			req.query();
			//req.setWorkflow(false);
			
			if (req.next()) {
				req.assignment_group = sctask.assignment_group;
				req.update();
				
			}
			
		}
		
	}
	
})(current, previous);

Update RITM field from Catalog item Variables(entered by user when filling catalog form)

Here OPCO is a field in catalog Item

We need to update OPCO value in “Primary affected site”(u_primary_affected_site) in RITM

(function executeRule(current, previous) {
	
	//gs.addInfoMessage("opco..........................."+opco);
	
	var opco="";
	var ritm = new GlideRecord('sc_req_item');
	ritm.addQuery('number', current.number);
	ritm.query();
	//ritm.setWorkflow(false);
	if(ritm.next()){
		
		//gs.addInfoMessage("opco..........................."+opco);
		var gr = new GlideRecord('sc_item_option_mtom');//this tables hold all user entered data in variables of catalogItem
		gr.addQuery('request_item', ritm.sys_id);
		gr.query();
		//gr.setWorkflow(false);
		while (gr.next())
			{
			if(gr.sc_item_option.item_option_new.getDisplayValue()=="OPCO")
				{
				gs.print(gr.sc_item_option.value);
				opco = gr.sc_item_option.value;
				
			}
		}
		
		ritm.u_primary_affected_site = opco;
		ritm.update();
		
	}
})(current, previous);