Tuesday, June 14, 2011

Plugin, workflow or dialog in CRM 2011?

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 CRM. 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.


  1. brilliant post, keep up the good work sir.

    I could have done with this when I got asked a similar question in an interview

  2. excellent post, great blog.