Understanding workflow in Dynamics 365.

Hello Guys,

In our previous blog we have learnt about client API model in D365. Today we going to explore Workflow.

Do follow us to know more about Dynamics and Power Platform. Also if you like our blog then please comment and share this blog with your friends.

Dynamics 365 workflows consists of a series of steps and rules that serve to automate a business process. You can create workflow for both OOB tables and custom tables using OOB functionalities or by writing .NET code. Workflows can be triggered based on specific condition or can be started by manually by users. Workflow can be run either in the background(asynchronous) or can be run as real time(synchronous).

Configuring a workflow has the following major parts(in sequence)

• Configure the table on which the workflow will run.
• Configure whether the workflow will run synchronously or asynchronously.
• Configure the message(event) on after which the workflow will run.
• Configure the scope in which the workflow will run.
• Configure the stages and steps(actions) of the workflow.

When you create a workflow, you will see the option of Run this workflow in the background (recommended) which determines whether the workflow will run in real-time (synchronously) or in background (asynchronously).

Asynchronous workflows in Microsoft Dynamics 365 uses windows service to act as a host application for the workflow engine to work. This Asynchronous workflows must be running ton the Windows CRM server, otherwise the workflow won’t execute.

Real-time workflows in Dynamics 365 are also known as Synchronous workflows. These are defined using the workflow entity records and specifically designed for non developers. They execute using the Event Execution Pipeline, much like plug-ins, and they can be executed pre-operation, post-operation, or during the core operation. Also, as with plug-ins, you cannot execute a real-time workflow before the Create operation or after the Delete operation.

Real-time Workflows cancel and roll back the core platform operations.

Real-time Workflows can be converted to Asynchronous workflows and vice-versa.

However, the recommended approach is to run the workflows in the background since they use system resources as and when available. However, you can always switch back from a real-time workflow to background workflow and vice versa.

Workflows can be registered on specific events as follows:

• When a record is created.
• When a record status changes.
• When a record is assigned.
• When a record field value changes.
• When a record is deleted.

Workflow allows you to set the scope in which the workflow will run.

• User :- Workflow will run only on the records owned by the same user as the workflow user
• Business Unit :- Workflow will run on the records owned by the users of the business unit same as the workflow user.
• Parent Child Business Units :- Workflow will run on the records owned by the users of the business unit same as the workflow user as well as any child business units.
• Organization :- Workflow will run on records owned by any user in CRM.

Difference between Plugin and Workflows

Although plugins and workflows both can be used to run synchronous as well as asynchronous logic, plugins are generally preferred for  synchronous logic while workflows for asynchronous logic.

Generally, to implement complex business logic plugins are preferred over workflows. Workflows are preferred when you want to achieve relatively easier functionalities such as sending email, assigning records etc.

Workflows can be created through end user and non-developers on the server where as plugins can be created through software engineer or developer only.

While creating workflows no special security access is required outside the CRM where as plugin can be registered using user who is having System Admin or System Customizer security role.

Workflows can be created without code except custom workflow where as for plugin we have to write code.

Custom workflows are .NET classes which are inheriting CodeActivity class where as Plugins are .NET classes which are inheriting IPlugin interface.

Workflows can be called through actions or plugins but plugins can not be called through workflows.

Workflows can run as child workflow but plugins can not run as child plugin. However plugins can call each other and can trigger each other execution.

Plugins can execute both online and offline where as workflows can execute only online.

Workflows work well for either short or long process with use of wait step in the background. However wait step is not available in real time workflow. Plugins are having time limit of 2 mins.

In case of infinite loop, workflow can run up to maximum 16 times where as plugins can run up to 8 times before platform stops their execution forcefully.

Workflow can run on demand. Hence, if there are requirements where the user wants to run some logic manually, workflows would be better choice. In case of plugins, something needs to trigger the plugin to run.

Plugins are having stages like pre events and post events where as workflow is not having stages. It runs at CRM core operation i.e. stage 30.

Concept of Images like pre and post images are available with plugins where as workflow is not having any images.

You can read secure and unsecure configuration using plugins where as you cant read secure and unsecure configuration using workflows.

Plugin runs in the context of calling user or impersonation user where as workflows run in the context of the owner who initiates the workflow.

Async workflow are queued to execute after core operation where as async plugins can execute immediately after the core operation.

There are lots of events available to register the plugin where as workflow can be triggered by few event like create, assign, status change, field change and delete.

Workflows are more suitable when:

you want to achieve simple tasks faster, such as sending an e-mail or creating / updating assigning records. These actions can be set up very quickly with a workflow without any need of writing code.

you want to allow an advanced user to make changes to logic. As using the integrated workflow designer is user-friendly, an advanced user would be able to edit an existing workflow and change some rules according to business changes.

Plug-ins are more suitable when:

You need to manipulate data before is saved.

You need to make validations before submitting the operation.

You want to be able to cancel an operation based on your validations.

Immediate response to the user is needed.

You need retrieve values and/or take actions after operation has been completed (i.e. getting and autogenerated id)

Hope it helps...