Changes

Jump to: navigation, search

Template:July2023Upgrade

217 bytes added, 1 February
updated workflow change of behaviour
====Updated Workflow Behavior====
Updated the behavior of workflows to run in a linear serial, single-threaded manner where child workflows are triggered during the processing of a workflow. Previously when stepping through a workflow, if another workflow was triggered, a new thread would be created to process the child workflow simultaneously and asynchronously, as the original system thread would then return to the original workflow and continue to step through its tasks without waiting on the child workflow to complete. This could lead to inconsistent results if the system was configured to run multiple workflows against the same object, or if the order of operations of their tasks needed to be preserved, but results would vary due to race conditions of the workflows. After this upgrade the default behavior of workflows has now been changed to instead process multiple workflows in a serial synchronous fashion so that their order of generating new threads operations and behavior are more consistent and predictable. Now when a workflow triggers another workflow, the '''Run Asynchronously''' option is toggled offsystem will process all child workflows fully to completion in the original system thread rather than passing each new workflow to a new separate processing thread. This change means that child workflows will reduce be processed in a serial fashion, and their order of tasks will be preserved, before the system returns back to working on the likelihood original workflow. This may impact systems where workflows are configured to launch other child workflows, and you may now experience an increase in the runtime of two such workflows running simultaneously . If the areas in your system that trigger multiple workflows, do so with different target objects for each of the workflows, then it should be safe for you to revert back to the previous mode of operation by enabling the new [Run Asynchronously] toggle that is now available inside the configuration of a workflow, and to enable this option on the same recordinitial workflows that are instantiating child workflows. Examples and notes. After the upgrade, the task process order will be:
# If the workflow is a trigger workflow task, go to the trigger workflow
Workflow completion time may be affected and can vary depending on the configuration.
 
Previously when stepping through a Workflow, if another Workflow was triggered, it would be run in a new thread simultaneously and asynchronously, and the system would return to the original Workflow and continue to step through its Tasks. This could lead to inconsistent results if the system was configured to run multiple Workflows against the same object, and if the order of operations of their Tasks needed to be preserved due to race conditions of the Workflows.
 
After this upgrade the default behavior of Workflows has now been changed to instead process multiple Workflows in a serial synchronous fashion so that their order of operations and behavior are more consistent and predictable. Now when a Workflow triggers another Workflow, the system will process all sub-Workflows to completion in the original thread rather than starting them in a new thread. This means that sub-Workflows will be processed in a serial recursive fashion before the system returns back to working on the original Workflow. This may impact systems where you may now control this behavior with the new option '''Run Asynchronously''' that has been introduced on the Workflow configuration screen. If the areas in your system that trigger multiple Workflows, do so with different target objects for each of the Workflows, then it should be safe for you to revert back to the previous mode of operation by enabling the '''Run Asynchronously''' toggle on Workflows that trigger other sub-Workflows.
In general, "chained" workflows that are triggering against the same object should remain synchronous. For example, if the Level 1 record triggered workflow A and one of its task triggers workflow B on the same Level 1 record, then the workflows should remain running synchronously. Therefore, do not toggle on the '''Run Asynchronously''' option). However, if the Level 1 triggers workflow A and then one of its tasks is to trigger workflow B on all of the associated contacts on the Level 1, then this workflow can run asynchronously and the '''Run Asynchronously''' option should be enabled on workflow B to optimize performance.
Smartstaff, administrator
686
edits

Navigation menu