ServiceNow Certification Mock Exams
Click To View Now
Welcome to the complete guide for business rules in ServiceNow! Whether you're new to ServiceNow development or looking to brush up on your knowledge, we've got you covered in the guide below.
As a ServiceNow developer, it is important to understand how to create and utilize business rules. You may be given a requirement to automatically close child tasks when a parent record is cancelled, or to create an event that triggers an email notification when a record moves to a certain state. Business rules are one of the tools used to accomplish these things. Business rules allow you to define what happens within ServiceNow when some database action occurs to a record. The use cases for business rules are seemingly endless, which is why it is critical for developers to understand how they work. In this article we will dive into what a business rule is, how to use them, and other helpful tips to help developers unleash the power of the business rule.
Business rules are server-side code that execute in ServiceNow when a specific action is performed on a record. A business rule can be configured to run for one or more of the following database operations: Insert, Update, Query, and Delete. Basically, they are a way for developers to automate what happens to a record when one of the above actions occurs. Business rules don’t necessarily need scripting, however in most cases you will find that scripting is required in order to get the desired results. Business rules have access to many server-side APIs, including the GlideSystem, GlideDateTime, and GlideRecord classes. For developers to use business rules to their full potential, it would be wise to familiarize yourself with these APIs.
NOTES: Insert links to the cheat sheets for GlideSystem, GlideDateTime, GlideRecord is we have them.
A business rule can be configured to run at different “times” in relation to the action performed on the record. This can be achieved using the When field.
The When field is a select box that contains 4 different options: Before, After, Async, and Display. Each business rule is configured with only one of these options. Let’s discuss further what each of these options actually means.
Before business rules will execute after a record is saved/submitted/updated and before a database operation is performed.
After business rules will execute after a record is saved/submitted/updated and after a database operation is performed.
Async business rules work in a similar way to After, however Async rules will execute asynchronously (hence the name) meaning that they will not run immediately after the record is submitted. Rather, ServiceNow will create a scheduled job which will run when the system has bandwidth. Most of the time users will not be able to notice the difference between After and Async, but there are some performance implications to be aware of where sometimes using Async is the better option.
Finally, Display business rules execute before a record is displayed to an end user. Display business rules can be used along with the g_scratchpad object to send data from the server to the client. You could then utilize that g_scratchpad object in a client script (typically an onLoad) to access data that normally would not be available client-side.
The When field works along with the database operations discussed in the previous section to specify exactly when a business rule will execute. One example of this is a business rule can run after a record is inserted or updated. Another example is a business rule that runs before a record is queried. As we can see, there can be only one value for When but you can have multiple database operations selected. Being aware of this will allow you to get the most out of your business rules.
There is one more thing to mention about When. The Advanced checkbox must be selected on the business rule form in order for the When field to be visible. Then you will be able to make changes to the field. If the value for this field is not changed, then the business rule will be a before business rule by default.
Now let’s take a look at the business rule form and discuss how to configure it. The following screenshot is a business rule form without the Advanced checkbox selected.
Notice that the When field is not visible, and that there are two tabs available (When to run and Actions). The next screenshot shows the form with the Advanced checkbox selected.
With the Advanced checkbox selected there are more options available to configure on the form. On the When to run tab there are two new fields visible: When and Order. There is also a new tab on the form labeled Advanced.
Let’s point out some important fields on the business rule form. Besides Advanced, in the top section we see several fields including Name and Table. It is always a good idea to give your business rule (or anything really in ServiceNow) a name that will indicate what the functionality of the rule is. The Table field defines which table the business rule will execute on.
On the When to run tab we have several key fields for business rules. The majority of these we discussed in detail previously. Here we see the When field which contains the four options of Before, After, Async, and Display.
This business rule is populated with the default value of before. On the right-hand side we see four checkboxes where we can specify the database operations Insert, Update, Query, and/or Delete. As previously mentioned, you can select one or more of these options. Filter Conditions allow you to add more granular conditions to specify when the business rule will run. If you are using a filter condition, it must evaluate to true for the business rule to execute.
The Actions tab has a few useful fields as well, especially if you want to create a business rule that doesn’t use scripting. Set field values allows you to set as many field values as you wish without the use of scripting.
If the Add message checkbox is selected, another field will appear which will allow you to enter a message that will be displayed to the user at the top of the screen when the business rule executes.
The Abort action checkbox is useful if you wish to abort the database operation when the conditions of the business rule are met. This field can be used along with a message to cancel an operation and let the user know why the action was aborted.
The final tab on the business rule form is the Advanced tab. This is where all the scripting for a business rule takes place. In the Condition field you can use JavaScript to define a more complex filter condition for the business rule. Just like the Filter Condition field, the Advanced Condition must evaluate to true for the business rule to execute. This field can also be used along with the Filter Condition field mentioned earlier.
It is important to note that the Filter Condition will be evaluate before the Advanced Condition, and if you are using both, both must evaluate to true for the business rule to run.
The Script field is where you can write code using JavaScript to define the functionality of the business rule. The Script field has access to the current and previous objects. Developers will need to use scripting for any functionality that cannot be achieved using the available fields on the business rule form. We will look at an example of this next.
Let’s say we are given the requirement that when a requested item is moved to a state of Closed Incomplete, all the open catalog tasks associated with that requested item should also be closed with a state of Closed Incomplete, and a work note is added to the task stating it was automatically closed. The following example shows how to accomplish this using a business rule.
The above screenshot shows the conditions for which this business rule will run. As we can see this business rule had been configured to run on the Requested item table with the Advanced checkbox selected. This business rule will execute after a record is inserted or updated. We’ve also added a filter condition where this rule only executes when state the changes to Close incomplete.
This screenshot shows the contents of the script field. The script contains a GlideRecord query where we look up all active child catalog tasks for the current requested item that triggered this business rule. Next, we loop through the matching records, set the state of the catalog task to Closed incomplete, and add a message in the work notes.
It is important to take note of the line that contains grTask.update(). The update() method is needed whenever you are updating records that are NOT the record that fired the business rule. If you forget to do this, the intended updates to the other records will not happen.
There are several best practices around business rules. One best practice to keep in mind is to avoid using Before business rules when updating records on a different table. In the example above, our script was updating catalog task records when a change occurred on the requested item table. If this was a Before business rule, ServiceNow would have updated the child records (catalog task) before the parent (requested item) was submitted to the database. Sometimes this can cause issues. Once the current (requested item) record is updated, there may be other rules triggered that effect the same child (catalog tasks) records. This can yield unexpected (and confusing) results such as looking like your code never executed when it actually did but was overridden by some other rule. It’s always a good idea to use an After business rule when making changes to records a table besides the current one.
Another best practice is do NOT use current.update() in a business rule script. This should be avoided as it is not necessary and can cause issues in the system. A scenario where developers typically think they need this is in a Before business rule to commit the updates to the current record in a script. However, the current record will be updated automatically when the business rule executes, making current.update() redundant. Additionally, depending on the type of business rule configured, using current.update() could create an infinite loop, generate errors in the system, and cause other sorts of performance issues. Simply do not use current.update() in any business rule and you’ll be fine.
One last thing to note - if you notice that your business rule isn't triggering, this may be due to a script using setWorkflow. If there is another script using setWorkflow(false), then it could be preventing your business rule from running.
Configuring business rules is an essential skill for a ServiceNow developer. This article touched upon the basics in order to get you started. There are countless use cases and topics for business rules to add to your developer toolkit. As always, we encourage you to continue learning and expand your knowledge. Happy coding!
