---
sourceDocument: Brazil API Reference
sourceDocumentLink: https://www.servicenow.com/docs/r/api-reference

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil API Reference

ft:clusterId :

    - crapiref

bundleId :

    - crapiref

workflow :

    - Creator


---

# Classic Business rules

# Classic Business rules {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Classic Business rules

Classic Business Rules in ServiceNow are server-side scripts that execute automatically when records are displayed, inserted, updated, deleted, or queried in the database.
They enable automation based on database operations and conditions, helping to enforce business logic consistently across forms, lists, and web services.
Although Business Rules are a traditional scripting method, ServiceNow recommends using Workflow Studio for new automation projects to improve extensibility and maintainability.
This guide is primarily designed to help customers work with existing Business Rules in their environments.
Show full answer Show less  

## When Business Rules Run

Business Rules run based on two key criteria:

* **Timing relative to database operations:**
  * **Before:** Runs after the user submits a form but before the record is saved.
  * **After:** Runs after the record is saved.
  * **Async:** Runs asynchronously after a scheduled job triggers it, useful for background processing but with no guaranteed execution order.
  * **Display:** Runs before a form is shown to the user, immediately after data is read from the database.
* **Applicable record operations:**
  * **Insert:** When a new record is created.
  * **Update:** When a record is modified.
  * **Query:** When records are queried, generally used in before rules.
  * **Delete:** When a record is deleted.

Note that Business Rules run consistently regardless of how records are accessed (forms, lists, APIs), unlike client scripts, which apply only during form editing. Also, asynchronous rules do not have access to previous record versions, limiting capabilities of certain GlideElement methods.

## Business Rule Actions

Business Rules can perform various actions to enforce business logic, including:

* Modifying field values dynamically based on user input or roles.
* Displaying information messages to users.
* Updating related child tasks when parent tasks change.
* Restricting access or modifications to fields on a form.
* Aborting database transactions to prevent saving records under certain conditions.

Administrators can set field values, show messages, and abort transactions through configuration without scripting.

## Best Practices and Considerations

* **Avoid recursion:** Using `current.update()` inside Business Rules can cause recursive loops and performance issues. Instead, update related records in after rules or use the `setWorkflow(false)` method cautiously to prevent recursion.
* **Async Rules:** Be cautious with async Business Rules as multiple updates can execute out of order, potentially causing inconsistent data.
* **Access Control:** Business Rules do not inherently enforce Access Control Rules (ACLs) unless explicitly configured.
* **Scope:** Business Rules function within application scopes, either private or global, allowing modular and secure customization.

## Practical Usage for ServiceNow Customers

ServiceNow customers can create Business Rules to automate and enforce backend logic efficiently. Understanding when and how Business Rules execute helps in maintaining data integrity and user experience. Combining Business Rules with client scripts allows for both server-side enforcement and client-side responsiveness, ensuring fields behave correctly in forms and lists.

Examples such as the Task Active State Management Business Rule and Installation Settings demonstrate common use cases for dynamic field management and programmatic configuration.

While Business Rules remain essential in many production environments, customers are encouraged to consider Workflow Studio for new automations to benefit from improved manageability.  
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.  
Business rules are scripts that run when certain server-side conditions are met. Business rule conditions include when to run a business rule in relation to a database operation, and what record operations the business rule applies to. There are other scripting options available on the platform for client-side conditions, such as client scripts and UI actions.  
Note:  
Business rules are a classic automation solution that rely on scripting. Use Workflow Studio for any new process automation to create automations that are easier to extend, reuse, understand, and upgrade. As many organizations have business rules in production, use this documentation to learn how to work with existing business rules.

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

## When business rules run {#c_BusinessRules__section_ezw_cgn_rjc}

To configure business rules, you first need to determine when the business rule should run and what action it should take.  
Business rules run based on two sets of criteria.

* When to run the business rule in relation to a database operation.
* What record operation the business rule applies to.

{#c_BusinessRules__ul_q43_4h3_bp}The following options are provided to determine when the business rule should run.{#c_BusinessRules__table_w2s_1k3_bp__entry__2}

| 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 | After the user submits the form and after 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 but before any action is taken on the record in the database. Note: Newly created business rules will run during upgrades. If a record has an asynchronous business rule that makes decisions based on the data in the record, multiple updates to the record in quick succession can cause the business rule to execute out of order or incorrectly. If multiple async business rules update the same record, the updates performed by one script could be overwritten by another script or made in an unexpected sequence because the order of execution isn't guaranteed. You can use the After option for business rules or [System Events](https://www.servicenow.com/docs/access?context=events&version=brazil&pubname=brazil-build-workflows&ft:locale=en-US) as an alternative in these situations. |
| Display | Before the form is presented to the user, just after the data is read from the database. |
[Table 1. When the business rule should run]

{#c_BusinessRules__table_w2s_1k3_bp}  
Note:  
* Asynchronous business rules do not have access to the previous version of a record. Therefore, the changes(), changesTo(), and changesFrom() GlideElement methods do not work with async rule script. However, the condition builder and condition field (advanced view) both support the changes(), changesTo(), and changesFrom() methods.
* Business rules do not honor ACLs until you want them to be honored. For more information, see [Relationship between Business Rules and Access Control Rules (ACLs)](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0656366)
{#c_BusinessRules__ul_r2y_x2k_5tb}  
The following options are provided to determine what record operations the business rule applies to.{#c_BusinessRules__table_p2x_rk3_bp__entry__2}

| 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 | When the user queries for a record or list of records. Typically you should use the query operation for before business rules. Only query business rules on the table queried are executed---not query business rules on the tables of reference fields. |
| Delete | When the user deletes a record. |
[Table 2. What record operation the business rule applies to]

{#c_BusinessRules__table_p2x_rk3_bp}  
Note:  
Business rules only run record operations when called from the GlideRecord API. Some applications intentionally bypass business rule processing to perform record operations directly. In addition, business rules ignore API calls run with the setWorkflow() method set to false.  
This image shows when different types of business rules run:Figure 1. 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.

## Business rule actions {#c_BusinessRules__section_fzw_cgn_rjc}

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.
{#c_BusinessRules__ul_yvs_fm3_bp}Administrators can set field values, create information messages, and abort transactions without writing a script.

## Prevent recursive business rules {#c_BusinessRules__section_gk5_ykj_ccb}

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. Changes made in before business rules are automatically saved when all before business rules are complete, and after business rules are best used for updating related, not current, objects. When a
recursive business rule is detected, the system stops it and logs the error in the system log. However, current.update() causes system performance issues and is never necessary.

You can prevent recursive business rules by using the setWorkflow() method with the false parameter. The combination of the update() and setWorkflow() methods is only
recommended in special circumstances where the normal before and after guidelines mentioned above don't meet your requirements.
* **[Business rules in scoped applications](https://www.servicenow.com/docs/YE8WHgXexIjgUThIkMrXqw)**   
  Every business rule is assigned to either a private application scope or to the global scope.
* **[Create a business rule](https://www.servicenow.com/docs/K56wwChLxihtNpbgGKcBJw)**   
  You can create any type of business rule to run when a record is displayed, inserted, updated, or deleted, or when a table is queried.
* **[Global variables in business rules](https://www.servicenow.com/docs/zZPo0AkD3pBAdAe2DTIRBg)**   
  Predefined global variables are available for use in business rules.
* **[Control field values using business rules and client scripts](https://www.servicenow.com/docs/ihpTlspeoPcFa0~AOoBk7Q#r_BsnsRlClntScptsCntrlFldVl)**   
  Implement both business rules and client scripts for a field to enable users to set record values properly using both forms and lists, and to see immediate changes to the values in forms as edits are made.
* **[Display business rules](https://www.servicenow.com/docs/boMjdQAa~hub4gl6XEh8fA)**   
  Display business rules are processed when a user requests a record form.
* **[Task Active State Management business rule](https://www.servicenow.com/docs/qXOIwZCpAgdazCg750g5ug)**   
  The Task Active State Management business rule determines whether the active field value needs to change based on changes to the State field.
* **[Installation settings](https://www.servicenow.com/docs/1Sx8nbkR7a~WVH73DFszfQ)**   
  Installation settings are global business rules with calculated names. Installation settings are calculated just before a record is displayed and facilitate dynamic determination of access and roles. Installation Settings permit the programmatic determination of a setting.
* **[Example business rule scripts](https://www.servicenow.com/docs/1fSFl3w1b4_KVJkcVyNkaQ#business-rule-examples)**   
  Find an example business rule script that helps you with a requirement of your organization.

**Related tasks**   

* [Create a business rule](https://www.servicenow.com/docs/K56wwChLxihtNpbgGKcBJw "You can create any type of business rule to run when a record is displayed, inserted, updated, or deleted, or when a table is queried.")