The When field on the Business Rule form is one of the most important fields when creating a business rule. It controls when the business rule will be run. The options available are described here, along with some use cases:

• Before: One of the most widely employed options when creating a business rule, along with After. It can be used for cases where we want to create server-side controls to override field values, perform checks or validations, and/or abort operation based on a certain condition. The execution of the business rule happens before the database operation is performed, thus it can be used for many different use cases, such as the ones we just mentioned. However, it is not recommended when the execution of the business rule takes a long time as it can delay the output to the end user, thereby impacting the overall experience of the platform.
• After: The execution of the business rule happens after the database operation is completed, and thus does not really work as expected when trying to abort the operation. After business rules are useful for executing post-database operation scripts that involve GlideRecord operations on related objects that need to be displayed immediately. Similar to Before business rules, After rules should not be used to execute very large scripts.
• Async: Business rules that execute Async can be used to execute large scripts, and are also useful for executing scripts that involve GlideRecord operations of related objects that do not need to be displayed immediately. Async is very useful for calculating SLAs, validating information from remote systems, triggering web service calls, and other scripts that may take more time than usual to execute. The execution of Async business rules happens in parallel to the database operation, and thus the previous object is not available during the execution and it cannot abort the operation.
• Display: The Display rules are executed when a record is queried and shown in a form. Display can be very useful in providing client-side scripts access to data that is not part of the form, such as values in columns that are not part of the form view, any server-side calculated values, or records stored in other tables. It utilizes a shared scratchpad object that is sent to the client along with the form. An example of the display business rule script that utilizes the scratcpad object, g_scratchpad, is shown here:

        //display business rule example  
        g_scrathpad.someVariable = "some value"; 
        g_scratchpad.secondVariable = "another value"; 
       //we can also pass column values that are not part of the form 
        g_scratchpad.lastUpdatedOn = current.sys_updated_on;