Learn in detail how business rules work and what they mean to ServiceNow development.
Event Driven
Business rules run when a ServiceNow form is displayed, or when the update, save, or delete operations occur. They are "event-driven". When they do execute, Business Rules can set field values, add a message, or run a script.
From the ServiceNow Wiki on Business Rules:
A business rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried. Use business rules to accomplish tasks like automatically changing values in form fields when certain conditions are met, or to create events for email notifications and script actions.
Even though there are now other scripting methods besides using Business rules, there are likely 1500+ business rules existing in your ServiceNow instance.
Why use Business Rules?
Business rules are fast. They are server-side and run much faster than other types of scripting in ServiceNow.
Here is an old article, while still relevant, that discusses the difference between client and server side programming: Client and Server side Programming
It is my advice to use Business Rules and Workflow as much as possible. Avoid using client scripts, except for Catalog Client Scripts (which are unavoidable). This is due to performance reasons and browser issues that client scripts can introduce.
Business Rules are now even creatively use the scratchpad object to blur the line between server and client programming: Scripting with Display Business Rules.
Advantages of Business Rules
Performance. When running code on the server, it often has a faster load time and processing time than a client script
Not affected by type of browser
Can perform complex database lookups
Can dot-walk many levels, however three levels is often a recommend maximum
Disadvantages of Business Rules
Not as interactive as client scripts, needs an event like save, delete, or display to run
How Business Rules work
The ServiceNow wiki includes a Business Rules Best Practices article that is worth checking out. I'll try to expand upon that article with a couple of my thoughts.
Caller Close Business Rule
When Field
The when field on a business rule is very important. Most business rules run "before", which means before save. However, occasionally you will use an "after" business rule to update a related table, which is purely for performance reasons.
Using display business rules is more popular now due to the new trick, Scripting with Display Business Rules. To be honest, I very rarely I use async rules.
Say when
display - Use to provide client scripts access to server-side objects. For more information, see Scripting with Display Business Rules.
before - Use to update information on the current object. For example, a business rule containing current.state=3; would set the State field on the current record to the state with a Value of 3.
after - Use to update information on related objects that need to be displayed immediately, such as GlideRecord queries.
async - Use to update information on related objects that do not need to be displayed immediately, such as calculating metrics and SLAs.
Advanced
You don't have to use scripting in Business Rules anymore. You can just use Filter Conditions, Role Conditions, and Actions to accomplish what you need instead.
I am from a older time when that functionality was not included in business rules. To get to the "old way" or "advanced", click that Advanced checkbox. When you click Advanced, you get the advanced tab and can begin scripting.
Caller Close "Advanced" tab
Condition
The condition field indicates when the business rule should run. ServiceNow evaluates the condition separately from the script. So if you use a limiting condition, you can improve performance by not having the script section run.
It is easier to debug business rules when you can see which one meet a particular condition and which do not.
Scripts and Scripting
For scripts, I thought I would include some important concepts:
#1 Prevent Recursive Business Rules
Avoid using current.update() in a business rule script. The update() method triggers business rules to run on the same table for insert and update operations, leading to a business rule calling itself over and over.
Business Rules run before, after, and display of a record. When you use current.update() in a business rule, that will cause a "double update" of a record or worse.
Here are some examples of the chaos this can cause:
before Business rule and current.update(): Business rule runs, current.update() saves the record, remaining business rules run and record will saved again. This results in duplicate operations such as duplicate notifications and updates.
after Business rule and current.update(): Record saves. after Business rule runs, current.update() saves the record again. This results in duplicate operations such as duplicate notifications and updates.
async Business rule and current.update(): Record saves. async Business rule runs later on, current.update() saves the record again. This results in duplicate operations such as duplicate notifications and updates with a gap of time in-between.
display Business rule and current.update(): display Business rule runs every time the form is displayed and the form attempts to save due to current.update(). User might not have filled out the form all the way and it is an annoying experience to the user.
Don't use current.update() in a business rule! There are certain situations when it is ok, but very rarely. Same goes with using g_form.save() in a client script.
#2 Enclose Code in Functions
You should always enclose your scripts in a function. When code is not enclosed in a function, variables and other objects are available to all other server-side scripts. This availability can lead to unexpected consequences that are difficult to troubleshoot.
ServiceNow now includes IFFE scripts when you start writing your business rule, so this is taken care for you now.
#3 Use Small and Specific Business Rules
By using small and specific business rules, they are easier to debug and maintain than a large and complex business rule.
It is tempting to make big business rule, but that will often hinder performance or make it difficult to evaluate.
#4 Learn Glide Record Queries
The most common scripting technique in ServiceNow is GlideRecord queries. Learn how to use them. Here are some examples to get you started: Five Different GlideRecord Queries