Please use docs.servicenow.com for the latest documentation.
This site is for reference purposes only and may not be accurate for the latest ServiceNow version
| Note: This article applies to Fuji and earlier releases. For more current information, see Business Rules at http://docs.servicenow.com
The ServiceNow Wiki is no longer being updated. Visit http://docs.servicenow.com for the latest product documentation.
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.|
How Business Rules Work
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 scheduled job created from the business rule. The system creates a scheduled job from the business rule 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.
|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.|
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.
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.|
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.
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.
|Note: Global business rules do not support domain separation.|
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).
Creating a Business Rule
- Navigate to System Definition > Business Rules.
- Click New.
- Fill in the fields, as appropriate (see table). Note: Some fields are only visible when the Advanced check box is selected.
- Click Submit.
|Note: You might need to configure the form to see all the fields below.|
|Name||Name for the business rule.|
|Table||Table or database view that the business rule runs on.
|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).
|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||Option to execute the business rule when a record is deleted from the database.|
|Query||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.|
|Set field values||Values for fields in the selected Table that are set when the business rule runs (starting with the Eureka release). Specify:
|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.
|Script|| [Advanced] Script that runs when the defined condition is true. The system automatically populates this field with a function name that matches the When value.
|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.|
- 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.
- 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.