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. 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:Table 1. 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, 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. The following options are provided to determine the database operation that the system takes on the record:Table 2. 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: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 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. Prevent recursive business rules 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 do not meet your requirements.