Plug-ins vs. Workflows in Microsoft Dynamics CRM

Today’s guest blogger is programmer and CRM aficionado Pablo Peralta.

I frequently get this question: When should I write a plug-in in Microsoft Dynamics CRM versus a workflow ? This dilemma is faced whenever custom logic must be executed in a pre and/or post operation.

Peter Hecke of Microsoft created this decision table on MSDN. Here is another pretty cool matrix done by Humberto on how to choose between these options: http://blogs.msdn.com/lezamax/archive/2008/04/02/plug-in-or-workflow.aspx. Additionally, I would like to point out some stuff that could also help when making up your mind.

First of all, remember than both workflows and plug-ins can attach to exactly the same events. Well, plug-ins have available a couple of more events but essentially both work on top of the same event model.Remember also that workflows always run asynchronous and hence, the Asynchronous Processing Service must be running on the server in order to run.

Workflows are more suitable if:

• you want to achieve simple tasks faster, such as sending an e-mail or creating / updating assigning records. These actions can be set up very quickly with a workflow without any need of writing code.
• you want to easily scale things to managers (if they were setup for user records), as it is possible to assign records to them.
• you want to allow an advanced user to make changes to logic. As using the integrated workflow designer is user-friendly, an advanced user would be able to edit an existing workflow and change some rules according to business changes.
• the logic should be available to be run on demand. I mean, when you are within an entity and navigates to “workflows” option in the left pane, all workflows marked as available to run on demand can be executed making them independent of an event trigger.
• you want to send emails making use of templates and attaching files.

Workflows also allow running child workflows which may make a lot of sense in some scenarios. Nevertheless, be careful if you need the child workflow results in order to make decisions on your main workflow, as child workflows always run asynchronous, which means that it will trigger the child workflow and continue. If you need your primary workflow to wait until child ends, you will need to write a custom activity.

On the other hand, plug-ins are more suitable if:

• you need to manipulate data before is saved.
• you need to make validations before submitting the operation.
• you want to be able to cancel an operation based on your validations.
• immediate response to the user is needed.
• you need retrieve values and/or take actions after operation has been completed (i.e. getting and autogenerated id)

It is important to note that since Dynamics CRM 4, plug-ins can also be configured to run asynchronous (Mode attribute while registering plug-in). Nevertheless, pre-event asynchronous plug-ins are not supported. In this case, you will have to set it up as synchronous mode.

Another important thing about plug-ins is the Deployment option which says if the plug-in is going to be executed on the server and/or Outlook client. If both executions are set up and client goes offline and online, plug-in calls are triggered after synchronization so be prepared in this case to execute your code twice!

Regarding to security:

• Workflows triggered automatically will run under the security context of the workflow owner. On the contrary, if executed on demand, the security context of the user who executed the workflow will be used.
• Plug-ins execute under the security context of the CRM Web application pool identity (typically NETWORK SERVICE). As this account typically maps to generic CRM SYSTEM user this typically works fine.

However, within plug-ins you can make use of impersonation to work under the credentials of the user who is making the request. For doing so, you just need to pass True to the CreatCrmService method under the context object.If you need to always impersonate with a specific user, you can do that by passing True as above and setting impersonatinguserid attribute while registering the plug-in.It is important to know that plug-in impersonation does not work offline. The logged on user credentials are always used in this case.

Hope it helps to clarify this dilemma and make better decisions.

Pablo Peralta

[In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at twitter.com/pabloperalta]