Imagine this: Two airline passengers, John and Mary, log in to an airline's seat reservation webpage to select their seats. A query business rule determines which seats were available to each passenger—based on factors such as their airfare and frequent flyer status—and then the system displays the same seating chart to both of them. They both select the same seat and submit the form, but Mary's reflexes are a little faster than John's, and she hits Submit a fraction of a second before he does.
If the system didn't double-check and discover that the seat was no longer available when John clicked Submit,...
...there could be an awkward situation at boarding time.
Fortunately, a before business rule checked for data that may have changed during the time lapse between John's filling in the form and submitting it. So the database was not updated to assign John the same seat that Mary had secured just a millisecond earlier, and they won't have to fight over the seat. Thanks to this business rule, an awkward situation was avoided!
In this installment of our best practices series, we look at what business rules are, and how they run.
What is a business rule?
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. Common uses are to check for data that may have changed during the time lapse between filling in a form and submitting it, as in the example above, or to automatically change values in form fields when certain conditions are met.
When business rules run
Using business rules at the right point in the business rule processing flow helps prevent unpredictable results and performance issues related to those rules.
This flowchart illustrates when business rules run, relative to database operations on the record—such as the system displaying the form, the user updating the form, and the database being updated. In general, business rules apply consistently to records regardless of whether they're accessed through forms, lists, or web services. However, display business rules are only used by forms—not by lists or web services.
The When field on the Business Rule form, shown here, indicates the point at which the business rule script runs, relative to database operations shown in the flowchart above. To display the When field on the form, the Advanced check box must be selected. This business rule runs before the current object is saved to the database.
Here's a list of base system business rules. You can view business rules in your own instance by navigating to System Definition > Business Rules. In this case, the list is personalized to display the When column. The most commonly used business rules are before and after rules.
This table explains when business rules run and provides example use cases.
| When value | When the rule runs | Example use case |
|---|---|---|
| display | Before the form is presented to the user, just after the data is read from the database. | To provide client scripts access to server-side objects. |
| before | After the user submits the form but before any action is taken on the record in the database. | 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 whose numeric Value is 3. |
| after | After the user submits the form and after any action is taken on the record in the database. | To update information on related objects that need to be displayed immediately, such as GlideRecord queries. |
| 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. | To update information on related objects that do not need to be displayed immediately, such as calculating metrics and service level agreements (SLA). |
You can often use an async business rule in place of an after business rule. Async business rules are similar to after rules in that they run after the database commits a change. Unlike after rules, async rules run in the background simultaneously with other processes. Async business rules allow the system to return control to the user sooner but may take longer to update related objects.
Business rule examples
Here are examples of a before and an after business rule.
Business rule that runs before database update
The insert_incident business rule runs before the database is updated:
When this rule runs, the current.number variable is assigned the next available incident number, and a message is displayed to the user:
Business rule that runs after database update
The SNC - ITIL - Close Related business rule for the Change Request table runs after the database is updated:
When this rule runs, it closes all related child change tasks and related problems:
To learn more about configuring business rules, check out this video on our NOWSupport YouTube Channel:
For more information, see:
- Business rules
- How business rules work
- Display business rules
- Async business rules
- Execution order of scripts and engines
--
Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you'd like us to cover in this series, please let us know in the comments below.
To access all of the blog posts in this series, search for "nowsupport best practices series."
7 Comments
