Options: Plugin, Workflow or Dialog

Our guest blogger today is Gonzalo Ruiz who is a CRM consultant for Avanade Canada.

This post is inspired by a popular article by my ex coworker Humberto Lezama G. regarding when to use plugins or workflows for implementing custom logic in Microsoft Dynamics CRM 2011. I have expanded the matrix to add additional criteria and more details about how each plugin vs. workflow handle different types of requirements. Additionally, I have added the new “dialogs” as an alternative in the chart.

Use Plugin
Use Workflow
Use Dialog
Needs custom logic to execute synchronously.
Plugins support synchronous execution.
Dialogs always execute synchronously.
The logic needs to be executed while offline
Only plugins are supported offline.
Needs elevation of privileges (impersonation)
In the plugin step, you can select the user under which the plugin will execute by setting the impersonating user id in the plugin step.
In some cases you can control under which user the workflow will execute by assigning the workflow to that user. See more details here.
Needs to execute on events other than assign, create, update and set state
Can be registered on a large list of sdk messages. See more details here.
The process/logic may take a long time to complete or will be a persistent process (multiple long running steps)
Workflows have no limit on the length of time they can take to complete execution. They can also persist (pause) and resume at a later date. Plugins have a time limit of a couple of minutes to complete (even asynchronous plugins).
Needs to execute asynchronously
Plugins support asynchronous execution
Workflows support asynchronous execution
End users will need to modify the process logic
Processes can be modified using the CRM process designer in the application and does not require IT administrators to re-compile and deploy a plugin assembly.
Child sub processes will be triggered
CRM processes support executing child processes
Needs to read configuration parameters for execution
You can make use of the configuration and secure configuration settings in the plugin step. These values will be passed to the plugin constructor and can be easily updated.
Dialogs cannot be configured with configuration parameters but they can retrieve configuration information from user responses / interactions.
Need to execute logic on-demand
Workflows and dialogs can be executed on-demand. Plugins can only be triggered as a result of a specified action to which the plugin step is configured.
Needs to roll back transaction in case of error (useful for validation)
Plugins can be registered in-transaction so they are able to roll-back the main operation if the plugin fails. Workflows are executed post-transaction so they cannot roll back the main operation.
The plugin/workflow logic is not possible to implement by using the CRM process designer
Plugins are written in .NET and this supports any action that can be achieved using the CRM SDK.
You can extend workflows/dialogs by creating a custom workflow activity which is also written in .NET calling any method from the CRM SDK. However, this is not supported in CRM Online yet.
Interaction with user is required to execute the custom logic
CRM dialogs support the execution of a process which dynamically takes input from question asked to the user.
Need custom logic to execute before the main operation
Only plugins can be registered to execute pre- main operation.
Need to gather data from the entity pre-image (image of the entity before the main operation)
You can register pre-images for plugin steps.
Pre-image is available only from custom workflow activities (not supported in CRM Online)
Need to gather data from the entity post-image (image of the entity after the main operation)
You can register post-images for plugin steps.
Post image is available from the process designer in the CRM application.
Needs to be packaged into a solution
Plugins and processes are solution aware
Need to use variables to store temporary data
Use the SharedVariables collection to store variables that can be passed to other plugins.
Use the SharedVariables collection to store variables that can be passed to other workflow steps. These variables do not survive persistence and can only be used from custom workflow activities. Not supported in CRM Online.
Dialog support variables of type string, int and float that can be passed from one step to another. For other types, SharedVariables can be used from custom workflow activity.


Gonzalo Ruiz

Comments (7)

  1. Pascal Alderweireldt says:

    And what about CRM Online versus CRM On-premise? Can plugins be used in both deployments?

  2. Shan McArthur says:

    Yes, plugins, workflows, and dialogs can be used in all CRM deployments.  The only restriction is that you can not deploy a custom workflow activity to CRM Online.  That said, you can use a plugin to meet the same requirements using what is known as the 'command pattern'.

  3. Gonzalo says:

    All the options above can be used in both deployments (except the ones in yellow which are not supported in Online). If you are in CRM Online you would have to register your plugin in sandbox isolation mode.

  4. Siva Polisetty says:

    Good Article Gunzalo, easy and handy for decision making.

  5. pablop says:

    Si quieres ver este artículo en español, el mismo está disponible en elblogdeDynamicscRM.com! aqui:


  6. Srini says:

    Very usefull article. Thanks for posting.

  7. Avidian.com says:

    Very usefull article. Thanks for posting.

Skip to main content