Criteria
|
Use Plugin
|
Use Workflow
|
Use Dialog
|
Needs custom logic to executesynchronously.
|
Plugins support synchronous execution.
|
Dialogs always execute synchronously.
| |
The logic needs to be executed whileoffline
|
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.
| |
Needs to execute onevents other than assign, create, update and set state
|
Can be registered on a large list of sdk messages.
| ||
The process/logic may take a long time to complete or will be a persistentprocess (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 executeasynchronously
|
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 processeswill be triggered
|
CRM processes support executing child processes
| ||
Needs to readconfiguration 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 logicon-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 asolution
|
Plugins and processes are solution aware
| ||
Need to usevariables 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.
|
Exploring CRM 2011
Thursday, May 9, 2013
Plugin, workflow, dialog in CRM 2011 - When to use what
Thursday, April 11, 2013
Difference between CRM 2011 Plug-In and Workflow
Difference between CRM 2011 Plug-In and Workflow
Criteria
|
Plug-in
|
Workflow
|
Execution before or after the core
platform operation (Create, Update, Delete, and so on)
|
Executes immediately before or after the
core operation (synchronous).Can also be queued to execute after the core
operation (asynchronous).
|
Queued to execute after the core
operation (always asynchronous).
|
Performance impact on the server
|
Synchronous plug-ins can increase the
platform’s response time because they are part of the main platform
processing.Asynchronous plug-ins have less impact on server response time
because the code is run in a different process.
|
Less impact on server response time
because the code is run in a different process.
|
Security restrictions
|
To register a plug-in with the platform
requires a System Admin or System Customizer security role and membership in
the Deployment Administrator group.
|
Users can interactively create workflows
in the Web application.However, to register a custom workflow activity, the
deploying user must have the same security roles as those required for
registering plug-ins.
|
Microsoft Dynamics CRM version (SKU)
support
|
Supported in Microsoft Dynamics CRM
Online when registered in the sandbox. May be supported in partner-hosted
installations at the discretion of the partner.
|
Workflows without custom workflow
activities are supported by all product versions. Custom workflow activities
are not supported on Microsoft Dynamics CRM Online.
|
Length of processing time
|
A plug-in registered for synchronous or
asynchronous execution is restricted to complete its execution within a 2
minute time limit.
|
Works well for either short or long
processes.
|
Works when the Microsoft
Dynamics CRM for Outlook client is offline
|
Both online and offline are supported.
|
Workflows do not execute when offline.
|
Process and data persistence
|
Plug-ins execute to completion. Plug-ins
must be written to be stateless where no in-memory data is persisted.
|
Workflows can be paused, postponed,
canceled, and resumed through SDK calls or by the user through the Web
application. The state of the workflow is automatically saved before it is
paused or postponed.
|
Impersonation
|
Plug-ins can perform data operations on
behalf of another system user.
|
Workflows cannot use impersonation.
|
Subscribe to:
Posts (Atom)