Previous post in the series: Dot-walking

---

What are Business Rules?

Business rules, in ServiceNow, are operations that take place in response to a database change. An example of this would be updating a record when another record is updated. The term business rule is one of those "business words" that have different definitions in different contexts. Often times, it's used in a situation unrelated to ServiceNow. So just keep that in mind when you hear it.

But anyway, we'll be using business rules to respond to database changes in today's lesson. We'll talk through how to create a business rule and provide a real-world example.

How to configure Business Rules

To set up a business rule, go to System Definition > Business Rules. When we're creating a new business rule, we need to know when we want the rule to fire and what we want the rule to do. Seems simple enough, right?

Let's use a real-world example to make this easier. Here's the client's requirement:

Cases for VIP users should be Critical priority

Ok... so from this statement, I can start to piece together what I want my business rule to look like. Any time we have a case (in this instance, an Incident [incident]) that is opened for a VIP user, we need to ensure it's marked as Critical priority.

So let's dive into setting up our business rule:

We're going to give this a descriptive title so we know what it does. And we'll choose Incident [incident] as our table, since we want to set the priority of these cases. (Please note that I am using incident and case interchangeably.) We've also checked the Advanced box, so we can see some extra options below. Let's jump into the When to run tab.

"When to run" tab

First, let me call your attention to the right-side of the screenshot, where we have Insert and Update checked. By checking both of these boxes, we're telling the system that any time an Incident [incident] record gets inserted into the database OR updated, we should trigger this business rule. (There's also query business rules, which can restrict a user's ability to see records. And of course, there's delete business rules, which trigger when a record gets deleted.)

Next, I'll call your attention towards the bottom of the screenshot, where we set up a Filter condition. We're adding another layer of restriction to our business rule, so now, we're only going to execute this business rule when an Incident [incident] case that has a VIP Caller is inserted or updated. So if we have a case created by an average joe, we won't have to worry about the priority getting set.

Side note: The VIP field is a field on the User [sys_user] table. To get this to display, when I chose the dropdown where VIP is selected in the screenshot, I scrolled to the bottom and selected Show related fields. This allowed me to dot-walk into the Caller field and see the VIP field. So technically, our filter condition is Caller.VIP=true.

Above our Filter condition is the When selection. Right now, we have before selected. Most business rules you create will be before rules. This configuration tells the system: right before a case with a VIP Caller is inserted or updated, execute this business rule.

Some business rules have an after configuration -- we won't go into a ton of detail on this, but you may want to use an after rule if your action is dependent on another record changing. There's also display and async business rules, but we definitely won't be going into detail on those in this course. I barely know what those are myself, and I'm the one writing this article!

"Actions" tab

The Actions tab is a user-friendly way of telling the business rule what should happen when it executes.

So, fun fact. Priority is actually controlled by what ServiceNow calls priority lookup rules (at least on the Incident [incident] table). So to automatically update our priority, we actually need to set two other fields in our actions. I only know this because I had to rewrite this article to make it work (👎). Anyway, check it out:

In the screenshot above, we are using the Actions tab to set the Urgency and Impact to High. In turn, these will update the Priority of the case to Critical.

And now that we have our When to run set up and our Actions set up, we're done. We can save our business rule and it will work.

"Advanced" tab

The Advanced tab is where you can script your conditions and actions. Often times, you'll see that developers completely neglect the Actions tab in favor of scripting the actions. This may occur because a developer needs to run additional checks in the script that check other tables.

In the screenshot above, we're using current to access the trigger case. The Urgency field is called urgency, and Impact is impact, so we can use current.urgency and current.impact to access those fields.

You may be a slightly more advanced user and notice that I'm not using current.update(). That's because I know the current record is going to be updated momentarily -- we are in a before business rule, after all -- so I want to avoid possible recursion. For more info on using current.update(), check out KB0715782.

What are some other use cases?

There's innumerable use cases for business rules in ServiceNow. There's actually a bunch that come OOTB that you probably haven't thought about:

• Adding users to groups, and updating the Group Member [sys_user_grmember] table
• Adding roles to users
• Copying info to child cases
• Updating case closure or cancellation data

But there's also use cases that may be more custom to your business. Like I said, there are innumerable use cases. Here's a few that I've seen done:

• Setting an indicator flag checkbox to true when the non-assigned to user updates the case (this is in conjunction with a field decoration)
• Updating the balance field on a case record when financial data is entered into another table
• Automatically setting the value of a field on a new case (instead of using Default value)

---

Next post in series: GlideRecords 101