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.

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

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s