With this feature, you can specify dynamic shares for a table to replicate the record before any action is taken on the record in the database or after action is taken. The default value is after.
Sharing a record using the “before” option will allow you to share the record with journal fields as part of the record's XML. For example, if you share an incident record and specify “before”, the record will come with both the comments and work notes in the incident record's XML.
If you share the record with the “after” option, the comments and work notes will not be part of the record's XML but instead will be records in the sys_journal_field table (ServiceNow upon saving a record into the database will separate journal fields from the record and save them into the sys_journal_field and sys_audit tables which is why you want to subscribe to the sys_journal_field and sys_audit tables when subscribing on a ServiceNow instance).
Using the “before” option will cause the record to be shared before any “after” business rules are run. For example, if you have an after business rule that runs to update the record's state based on a specific condition, the “after” option will share the record out with the updated state whereas the “before” option will share it with the previous state
The option to run as “async” has been added in version 3.10.0.
Note that when running as async records will be sent out as “.bulk” since the records are shared in the background and we will not be able to determine if the record was an insert or update at that point.
As well, there is no dependency on “current” or “previous” in the Before Share script (such as checking for a condition where a field “changes”) and the “sequence” of other records being replicated cannot be guaranteed. So a change created when an incident is created where both have dynamic shares may result in the change being shared out before the incident is).
In v3.16.0, dynamic share records “.bulk” when “business rule when” is set to async, so the trigger condition “Update or Insert” will be activated.
Also with async dynamic share, “deletes” will not work as the record is deleted by the time the Business Rule runs so the “delete” trigger condition is now disable when “async” is selected.