In Dynamics 365 and Power Apps, Workflows, Plugins and Actions are used to automate business processes.They allow businesses to hook onto events that occur in the system. Here we will look at the differences between the two and when to use which one.
Let’s summarize with the table below:
| Type | Triggers | Synchronous and/or Asynchronous | Tool |
| Workflow | Create, Fields Change, Status Change, Record Assigned and Deleted | Asynchronous (background) or Synchronous (real-time) | Process designer |
| Custom Workflow Activity | From Workflow or Action | Depends on where called | Visual Studio CodeActivity |
| Plugin | Many available through Plugin Registration Tool | Pre-Validation is Synchronous Pre-Operation is Synchronous Post-Operation is Asynchronous or Synchronous | Visual Studio IPlugin |
| Action | Triggered through code | Depends on where called | Process Designer, can be used with Plugin for Visual Studio development |
Let’s create a simple Workflow vs Plugin example.
Looking in Dynamics CRM in our default solution, we see Processes and Plug-in Assemblies.
Processes are where our workflows are located (and also in Settings->Processes), along with actions and business process flows.
You can see there are several processes below:
Let’s take a look at one of these – Auto Response Email for Case:
As can be seen, this workflow will run on the Case entity when a record status is changed, and it will run in the background. The logic says:
- If the case status is resolved, send a new email message and stop the workflow
- Otherwise, stop the workflow
Opening the first step, we can see we have an email template, where we can add the from and to as dynamic values from the case itself. The message of the email allows for text and dynamic values as well.
Note the workflow was activated. If we disable the workflow by pressing Disable, we will be able to edit the workflow. We can add more steps to the workflow.
For example, if we wanted to update another record as a result of the case being resolved, we could add a “Update Record” step. We could also run a child workflow or perform an action.
You can see workflows are useful for tasks such as updating data, and can be triggered when you save/delete/update records and fields.
The workflow is set to run in the background:
What this means, is the workflow will run asynchronously. If this box was unchecked, the workflow would run synchronously and the system would wait for its completion. You can also convert to a real-time workflow by clicking a button:
The scope of the entity defines who can run the workflow. If you want your workflow to run on any record in the organization you would set it to Organization.
Workflows are also triggered off certain events:
Workflows do not run offline. I.e. if you are using the CRM Outlook Client in offline mode, workflows won’t run until you come back online as they need to access the CRM server.
A key thing to note is that the workflows described above do note require development. A business user can go in and set up a workflow.
Now let’s discuss Plugins.
Plugins are different from workflows in CRM. Here you can see we have some plugins registered in the system:
Plugins are .NET code that is written by developers. As such, there is a lot you can do with a plugin, such as integrating with different systems. Plugins can run synchronously or asynchronously.
Plugins are written in Visual Studio and then deployed using the Plugin Registration Tool. This is located in the CRM SDK in the SDK\Tools\PluginRegistration folder.
You register the assembly created in Visual Studio and then register a step that defines what happens. Here you define which assembly the plugin should fire on (primary and secondary entities) and on what event (the message). Events include Assign, Create, Delete, Retrieve, Retrieve Multiple, Update, GrantAccess, RetrievePrincipalAccess, SetState and more. You can see there are more events available that workflows.
Check out this link from Microsoft for more information: https://msdn.microsoft.com/en-us/library/gg328576.aspx
One of these events will need to run in order for the plugin to fire, i.e. there is no “on demand” running like there is with workflows.
When registering the plugin, you have several options:
You can see here, you can define when the plugin should run. The options are:
- Pre-validation. Runs before anything else
- Pre-operation. Runs after validation and before committing to the database
- Post-event. Runs after record committed to the database
A main advantage with plugins is that they work in an offline environment, which is different from workflows which cannot.
Both plugins and workflows work in an on-premise and online environment.
In summary, when to use a workflow or a plugin depends on requirements.
I AM SPENDING MORE TIME THESE DAYS CREATING YOUTUBE VIDEOS TO HELP PEOPLE LEARN THE MICROSOFT POWER PLATFORM.
IF YOU WOULD LIKE TO SEE HOW I BUILD APPS, OR FIND SOMETHING USEFUL READING MY BLOG, I WOULD REALLY APPRECIATE YOU SUBSCRIBING TO MY YOUTUBE CHANNEL.
THANK YOU, AND LET'S KEEP LEARNING TOGETHER.
CARL
