--- sourceDocument: Brazil Build workflows sourceDocumentLink: https://www.servicenow.com/docs/r/build-workflows Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil Build workflows ft:clusterId : - crworkflow bundleId : - crworkflow 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. They enable automation by running based on specific server-side conditions related to database operations. While business rules are a traditional automation method relying on scripting, ServiceNow recommends using Workflow Studio for new automations for better extensibility and maintainability. However, understanding and managing existing business rules remains important for many organizations. Show full answer Show less ## When Business Rules Run Business rules run according to two main criteria: * **Timing relative to database operations:** They can run **before** (pre-database action), **after** (post-database action), **asynchronously** (after submission via scheduled jobs), or on **display** (before the form is shown). * **Record operations they apply to:** These include **insert** , **update** , **query** , and **delete** operations. Note that asynchronous business rules have limitations, such as no access to previous record versions, and their execution order is not guaranteed which can cause update conflicts. Also, business rules execute consistently across forms, lists, and web services, unlike client scripts which only run during form editing. ## Business Rule Actions Business rules can perform a range of actions including: * Changing or setting field values on records, with values derived from static values, other fields, or user roles. * Displaying informational messages to users. * Updating related child tasks based on parent task changes. * Restricting user access to certain fields. * Aborting database transactions to prevent saving records under specific conditions. Administrators can perform common actions without scripting, but scripting enables more complex automation. ## Best Practices and Considerations * Avoid using `current.update()` inside business rules to prevent recursive loops and performance issues; changes in before business rules are saved automatically. * Use `setWorkflow(false)` cautiously to prevent recursive rule execution only when necessary. * Business rules respect Access Control Rules (ACLs) only when explicitly configured. * Business rules are scoped either to private application scopes or the global scope, impacting their visibility and reuse. ## Integration with Client-Side Scripts Implementing business rules alongside client scripts helps ensure proper field value control across both forms and lists, providing real-time updates and validation for users. ## Specialized Business Rules * **Display business rules:** Run when forms are requested to prepare data for display. * **Task Active State Management:** Adjusts the active field based on state changes in task records. * **Installation settings:** Global business rules used to dynamically determine access and roles just before record display. ## Practical Use for ServiceNow Customers Understanding classic business rules is essential for managing existing automations effectively, troubleshooting issues related to record processing, and ensuring consistent data integrity across your ServiceNow instance. By configuring when and how business rules run, you can automate complex business logic server-side, improve system performance by avoiding recursion, and seamlessly integrate with client-side logic for optimal user experience. 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/avUoNf_rN0_6cpDRhvb8vg "Events are special records that the system uses to log when certain conditions occur and to take some kind of action in response to the conditions.") 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/yWClB8IUaH6pvSlhlth~QQ)** 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/8vesE4YxwZBfiqLGgmRTbA)** 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/So5qwZVSMY1uMRZeRxVOFg)** Predefined global variables are available for use in business rules. * **[Control field values using business rules and client scripts](https://www.servicenow.com/docs/KeyfzE6ybtGFzUhh9e8e2g#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/m6Er2LV9vEHfJ1NsC1B70g)** Display business rules are processed when a user requests a record form. * **[Task Active State Management business rule](https://www.servicenow.com/docs/u3blEQXvrqYMQa9x4Xv8fQ)** 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/3cdXLEMb7fSndtaOtyMiqQ)** 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/UxykeWXh5x0g3AlbEmAWqg#business-rule-examples)** Find an example business rule script that helps you with a requirement of your organization.