Default behavior for Async Business Rules : Run During UpgradeBackground In the "advanced" section of a business rule is a field called "when". One option in this selection is a choice called "async". What async means is that you want your business rule to run "at some time after" the record action completes. There is a general expectation, however, that this will run fairly soon after. Generally this is the case, with the exception of during an upgrade. In existing releases, while an upgrade is in process, business rules marked as async are not run. What is Changing? With the Rome release and beyond, all new business rules set to run "async" will run during an upgrade. Existing (pre-Rome) async business rules will not be changed automatically, and will continue to run as they have. The old async behavior is being deprecated and it is recommended that application development teams migrate to the new behavior (see Migration Notes for Developers below) as part of their standard development, testing, and release process. Why is it changing? There are async business rules that run as part of a primary user workflow; meaning a user performs an action and that user (or another user) is expecting the result of that action in order to continue. Not running these in a timely manner breaks that workflow. From discussions, it seems the primary reason async business rules are not currently run during upgrade is simply because it was built on the scheduled job system (sys_trigger) and the default value for its “upgrade_safe” flag is false. There is no indication that any special coding or consideration is necessary in the vast majority if not all async BRs in order to make them safe to run during upgrades. However, we cannot change this default behavior in bulk for all existing async business rules since this behavior has been around in the system for some time, and workarounds or other assumptions may be in place for existing async BRs. How is it changing? Core Platform has made the following changes for Rome release in order to retain the existing behavior for all existing async business rules but change the default behavior for all newly created async business rules. This involves two changes to the choices for the "when" field. Retire existing "async" We have renamed the label for the previous choice “when”: “async” Label : “async (deprecated: not run during upgrade)” We have set the field "Inactive" to remove this option from choice lists This results in the old behavior NOT being selectable when creating new business rules, but still showing when editing existing async business rules: Create a new "async" We have created a new choice for “when” : "async_always" Label “async” Value “async_always” The execution engine implements the new “async_always” choice by creating sys_trigger with “upgrade_safe” : “true” When will this change? This has changed for the Rome release and applies to any release after as well (San Diego, Tokyo, Utah, etc). Migration Notes For Developers There is NO action required by customers. Instances upgraded to Rome or beyond will not automatically change any existing business rules or their behavior. Post Rome, the label on the existing async choice has been re-labeled as "deprecated" however they will continue to function exactly as they have before. Development teams are strongly encouraged to review existing async business rules they own and update them to the new value. This will increase availability of this functionality during upgrade. One side-effect of retiring the old async value, is that finding existing ones becomes a little more tricky as the filter option no longer has the right choice (since "async" is the new async). An unexpecting user might create a new filter for "When : async" and see their list empty. In order to find the "legacy" async business rules, you need to do a "is not one of" filter and mention all of the available choices: Once identified, the existing value can be switched to the new async value simply by editing the record. Special Note on Rome+ async BRs applied to Pre-Rome instances Some customers will upgrade their dev or test sub-production instances to Rome or beyond, potentially several months prior to upgrading their production instance. During this time it is possible that a new async business rule is created in the Rome+ sub-prod, and added to an update set which is then applied to a pre-Rome instance. In this case, in order to prevent breakage, the business rule will be "downgraded" to the pre-Rome behavior when the update set is applied. The IDs of any business rules affected by this will be added to a Glide property called glide.async.br.reverted.ids. Once the instance has upgraded to Rome, this property can be used to identify any async Business Rules which should be updated.