Business Rules


In this video, we look at the features you
can use to configure business rules. Business Rules provide business logic to automate
processes in your ServiceNow instance. All business Rules run on the server side, but most run before or after a user submits or updates a form. What can you do with a Business Rule? You can automatically set field values dynamically. Like this business rule that sets the value
of the company field to the company of the caller… …generate in-platform messages, … …or abort an action, to enforce your process and workflow. Now let’s look at three notable properties
of Business Rules. First, Business Rules applied to a parent table automatically propagate to all child tables as well. For example, the Task table is the parent table to the incident, problem and change tables. So a business rule on the Task table will also affect these child tables. Business rules can also reach fields of referenced records. A reference field stores a reference to a
record in another table. For example, the Caller field on the Incident table is a reference to a record in the User table. A Business Rule running on the Incident table
could access any field of Caller… … or of any other record referenced by Caller,
for example the Caller’s Manager, who’s also a User. The third notable property of business rules is that they allow you to run arbitrary server side scripts including script includes, other glide records, start workflows, trigger integration logic, etc. Now let’s look at how business rules are
configured to execute. Insert only runs once when the record is initially created. Update runs each time the record updates. Insert and Update run when the record is initially
created, and each time the record updates. Regardless of how a business rule is configured to execute, the conditions defined in the business rule must all be true for it to run. Conditions can consist of Filter Conditions
defined here in the condition builder… … which look at field values, and Role conditions, which look at the role of the user who triggered the change. You also have the option of setting conditions
by enabling the Advanced option. You can enter a condition in the Condition field, or integrate the condition within a script, here. If you decide to include the condition statement in the Script field or if you use the condition builder, leave this field blank. Let’s look at an example. In this business rule, … …notice that there’s no filter conditions
set in the condition builder. But in the Advanced tab, … …we can see that a Condition has been defined,
which controls whether the business rule runs. Now let’s look at how to find the existing
business rules in the platform. Navigating to System Definition>Business Rules allows
you to view and access all business rules in the system. You can also access business rules that affect
a specific table from a form. Here, we open an incident form to access the business rules that apply to the Incident table. Business rules that are inherited from the Task parent table are also included in the list, as shown in the breadcrumb link. If you’re building scoped applications, all business rules associated with the scoped application will be listed in the application explorer in Studio. Let’s look at modifying a business rule. This business rule sets the Company field to the company of the caller, unless the user manually enters a value. The conditions required for the business rule to set this value are that the Caller field has a value and the Company field is empty. And this business rule runs on both insert
and update. Let’s add a new incident to see how it works.
We add a caller, but leave the company field empty. When we save the incident, … …the Company field is now populated with
the caller’s company. What if we wanted to notify the user that
the Company field has been set automatically? We could add a message to the Business Rule
that displays after the record has been saved. When we create a new incident… … the message displays after we save it. Now we need to create a new Business rule, to escalate new incidents to high when the caller is a VIP. Note that the table is already set to Incident. In the When to run tab, we set the business
rule to run on Insert… …and create a Filter Condition that the
Caller must be a VIP. The only option we have in the list is the Caller field – so how do we access the VIP field? We can access the related field on the User table by scrolling to the end of the menu, and selecting Show related fields. The list refreshes, and we
can select Caller User fields. The list refreshes again, and from that list we select VIP. Finally, we set VIP to True. In the Actions tab, we create an action to
set the Escalation to High… … and we submit the business rule. To test this business rule, we create a new
incident, and set the caller to a known VIP. The incident is automatically escalated to high. You can also take advantage of advanced configuration options for business rules. See the Product Documentation for details. For more information, please consult our product
documentation, knowledge base, or podcast. Or ask a question in the ServiceNow Community. For cost effective training solutions, contact ServiceNow Education Services.

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Post navigation

One thought on “Business Rules

Leave a Reply

Your email address will not be published. Required fields are marked *