Dynamics 365 Workflow Options — Synchronous and Asynchronous
Dynamics 365 offers outstanding workflow capability which enables power users to create complex logic sequences without writing code. In the case of custom application development like asp.net or node JS, a developer needs to write many lines of code to accomplish a logic within a business process. The same can be accomplished with Dynamics 365 workflows by arranging a sequence of steps with conditional operators using a workflow configuration tool. Most of the use cases can be accomplished with out of the box features. For custom scenarios, the framework allows developers to write custom workflow steps and register it with Dynamics instance which can later be used to sequence it as a workflow step. Dynamics 365 workflows can be configured as two options: 1. Synchronous or real-time workflow 2. Asynchronous or background workflows. Often, developers end up choosing the wrong type of workflows which may lead to unresponsive UI or UI reflecting obsolete information. This article describes pros and cons of each approach and some options to overcome some limitations.
Dynamics workflows can be configured as Asynchronous(background) workflows. In this case, the workflows will run in the background and will not interrupt the main business process flow in the user interface. For instance, when there is an insert, update or delete operation on a record, a queue entry is created for the workflow to run and CRM async service picks up the queue item and executes the workflow. The Asynchronous workflows usually starts executing within few seconds after the queue entry is created. This type of workflow is useful when the workflow logic contains large number of steps and the execution time is more. The main drawback of this approach is that user interface is not refreshed with latest information until the workflow execution is complete. On top of that user must refresh the browser screen to see latest information. This drawback can be eliminated by using Synchronous workflows.
In the case of Synchronous (Real-time) workflows, workflow executes as part of the main UI thread. After the workflow execution is complete, the latest information is reflected on the UI. There are other benefits like error notification when the workflow fails. When there is an error in the workflow execution, the error message is displayed on the user interface instead of logging them silently behind the scenes. The main drawback is the UI performance. When there are lot of steps in the workflow, the workflow execution time is significant, and the UI becomes unresponsive. According to surveys, the acceptable time for page load in today’s standards is 2 seconds or less. It is imperative to keep the page load times less than 1 seconds, if not less than at least 2 seconds. What if we can get best of both worlds. Use Asynchronous (Background) workflows and refresh the latest information on the UI automatically at the same time.
Dynamics 365 Web API allows ETag to check whether the current version of a resource matches the one last received. On the forms web resources, there can be a JavaScript function which executes every 5 seconds using “setTimeout” function or similar approach. This can execute a Dynamics web API call to retrieve record information only when there is a change from an entity by passing previous ETag value to “If-None-Match” header. This approach will allow large time consuming workflows to be executed as Asynchronous workflows and refresh the UI with latest information at the same time. Use the following decision flow to choose the right workflow option based on your needs.
To conclude, use Synchronous workflows when there is a need to execute quick workflows and get real time UI refresh. Use Asynchronous workflows when there are lot of steps to execute and workflow execution time is more. When there is requirement to execute large workflows and get real time updates, use ETag approach along with Asynchronous workflows.
