Business Rules

1 Overview

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.

Note: Business rules can make use of scripts to take actions on records in the database. However, there are several other scripting options available on the ServiceNow platform, such as client scripts and UI actions. See Differences Among Scripts to understand which scripting option is best for the actions you want to take.

2 How Business Rules Work

To configure business rules, you first need to determine when the business rule should run and what action it should take.

2.1 When Business Rules Run

Business rules run based on two sets of criteria:

• The time that the business rule is configured to run relative to a record being modified or accessed.
• The database operation that the system takes on the record.

The following options are provided to determine the time the business rule should run.

Option	When the Rule Runs
Before	After the user submits the form but before any action is taken on the record in the database.
After	After the user submits the form and after any action is taken on the record in the database.
Async	When the scheduler runs the rule. The rule is put into the scheduler's queue after the user submits the form and after any action is taken on the record in the database.
Display	Before the form is presented to the user, just after the data is read from the database.

Note: Asynchronous business rules do not have access to the previous version of a record. Therefore, these GlideElement methods do not work with async rules: changes(), changesTo(), changesFrom().

The following options are provided to determine the database operation that the system takes on the record.

Option	When the Rule Runs
Insert	When the user creates a new record and the system inserts it into the database.
Update	When the user modifies an existing record.
Query	Before a query for a record or list of records is sent to the database. Typically you should use query for before business rules. See Before-Query example.
Delete	When the user deletes a record.

This image shows when different types of business rules run.

Business rule processing flow

Note: Business rules apply consistently to records regardless of whether they are accessed through forms, lists, or web services. This is one major difference between business rules and client scripts, which apply only when the form is edited.

2.2 Business Rule Actions

Business rules can perform a variety of actions. Common types of actions are:

• Changing field values on a form that the user is updating. Field values can be set to specific values available for that field, values copied from other fields, and relative values determined by the user's role.
• Displaying information messages to the user.
• Changing values of child tasks based on changes to parent tasks.
• Preventing users from accessing or modifying certain fields on a form.
• Aborting the current database transaction. For example, if certain conditions are met, prevent the user from saving the record in the database.

Administrators can set field values, create information messages, and abort transactions without writing a script starting with the Eureka release. In versions prior to Eureka, administrators must write scripts to perform the actions that business rules take. See Creating a Business Rule for details on which options are available for your version. See Scripting in Business Rules for script examples.

3 Business Rules in Scoped Applications

Every business rule is assigned to either a private application scope or to the global scope (starting with the Fuji release). The types of business rules you can create and how you can access those rules varies depending on the scope of the business rule and the scope of the table it runs on.

Note: The term global can refer to two different aspects of a business rule—the table it runs on and the scope it runs in. Business rules can either run on specific tables or be global. In addition, they can be in the global scope or in a private application scope.

3.1 Business Rules on Specific Tables

Most business rules run on a specific table, which is defined in the Table field. You can create business rules on tables in the same scope and on tables that allow configuration records from another application scope.

For tables that are in a different scope than the business rule record, the types of rules are limited.

• You can create a rule where When is async with any of the following options:
  • Insert, Update, and Delete database operations. You cannot select Query.
  • Set field values actions and scripts (the Script field).
• You can create a rule where When is before with any of the following options:
  • Insert, Update, and Delete database operations. You cannot select Query.
  • Set field values actions only. You cannot write scripts and you cannot abort the database transaction.
• You cannot create any other types of business rules on tables in a different scope.

Business rules on specific tables cannot be accessed by other business rules or scripts.

3.2 Global Business Rules

Warning: Consider using script includes instead of global business rules. Script includes load only on request while global business rules load on every page in the system.

Global business rules are business rules where the Table field is set to Global. Global business rules may be accessible on multiple tables and from other scripts, depending on their scope protection. For a global business rule, define the scope protection by setting the Accessible from field:

• This application scope only: prevents applications in a different scope than the business rule from calling this business rule.
• All application scopes: allows any application to call this business rule.

3.3 Scripts in Scoped Business Rules

When you write a script in business rule, you can access:

• Any script includes and global business rules in the same scope as the business rule.
• Script includes and global business rules that allow applications in a different scope to call them. To call functions from another scope, you must specify the scope of the function.
• [Business rules in the global scope] The comprehensive system APIs (GlideRecord, GlideSystem, and @GlideScriptable).
• [Business rules in a unique scope] The Scoped System APIs only (ScopedGlideRecord, ScopedGlideSystem).

4 Creating a Business Rule

1. Navigate to System Definition > Business Rules.
2. Click New.
3. Fill in the fields, as appropriate (see table). Note: Some fields are only visible when the Advanced check box is selected.
4. Click Submit.

The advanced version of the Business Rule form that closes a task before the insert or update is written to the database.

Note: You might need to configure the form to see all the fields below.

Field	Description
Name	Name for the business rule.
Table	Table or database view that the business rule runs on. Note: The list shows only tables and database views that meet the scope protections for business rules (starting with the Fuji release).
Application	Application that contains this business rule (starting with the Fuji release).
Accessible from	Scope protection for a global business rule (starting with the Fuji release). Note: This field is visible only when the Table field is set to Global. It does not apply to rules that run on specific tables.
Active	Indicator of whether the business rule is active.
Advanced	Option to display the advanced section and additional fields on the form.
When to run
When	[Advanced] When the business rule should run: display, before, async, or after the database operation is complete.
Order	[Advanced] Sequence in which the business rule should run. If there are multiple rules on a particular activity, the rules run in sequence from the lowest order number to the highest.
Insert	Option to execute the business rule when a record is inserted into the database.
Update	Option to execute the business rule when a record is updated.
Delete	[Advanced] Option to execute the business rule when a record is deleted from the database.
Query	[Advanced] Option to execute the business rule when a table is queried.
Filter Conditions	Condition builder for specifying when the business rule should run based on the field values in the selected Table (starting with the Eureka release). You can also use the Condition field to build a condition with a script.
Role Conditions	Roles that users who are modifying records in the table must have for this business rule to run.
Actions
Set field values	Values for fields in the selected Table that are set when the business rule runs (starting with the Eureka release). Specify: The field. The assignment operator: To: An exact value. Same as: The value of another field. To (dynamic): A value relative to the user configuring the business rule or a user with a specific role. The value.
Add message	Message that appears when this business rule is run (starting with the Eureka release). Select the check box and enter a message.
Abort action	Indicator of whether to abort the current database transaction (starting with the Eureka release). For example, on a before insert business rule, if the conditions are met, do not insert the record into the database. If you select this option, you cannot perform additional actions on the record, such as setting field values and running scripts. You can display a message to users by selecting the Add message check box and composing the message.
Advanced
Condition	[Advanced] JavaScript conditional statement to specify when the business rule should run. By adding the condition statement to this field, you tell the system to evaluate the condition separately and run the business rule only if the condition is true. If you decide to include the condition statement in the Script field or if you use the condition builder, leave this field blank. To have the instance reevaluate the condition statement a second time before running an async business rule, add the system property glide.businessrule.async_condition_check and set the value to true. See business rules best practices for an example of how to use this field.
Script	[Advanced] Script that runs when the defined condition is true. For more information and examples, see Scripting in Business Rules.
Related list: Versions
Versions	All versions of the business rule. Use this list to compare versions or to revert to a previous version. For more information, see Versions.

5 Enhancements

5.1 Fuji

• These changes support developing scoped applications:
  • The Table field shows only tables and database views that meet the scope protections for business rules.
  • For tables that are in a different scope than the business rule record, the types of rules are limited.
  • The Application field is added on the form view.

5.2 Eureka

• Administrators can accomplish these tasks without writing a script:
  • Build conditions using the condition builder.
  • Set field values on the form specified in the rule. A set of choice lists allows administrators to set a field to a specific value, the value in another field, or a dynamic value based on the user.
  • Display an alert message. Administrators can use an HTML text field to compose a message
• The Business Rule form provides two versions:
  • A default version that provides a simplified form. On this version, administrators can create insert business rules or update business rules that run before a database change is made.
  • An advanced version that provides additional options. On this version, administrators can create any type of business rule and determine when the rule runs.