Today’s CRM Success blog entry will focus on when to use Workflows with Custom Workflow Activities (AKA Workflow Assemblies) and when to use Plug-ins when registering .NET assemblies to help facilitate business processes in CRM.

Workflows with Custom Workflow Activities vs. Plug-ins in Microsoft Dynamics CRM 4.0

We will start with high-level guidelines of when to use each tool and then get into the specifics of how the tools work within the Microsoft Dynamics CRM 4.0 Execution Pipeline with regards to the synchronous and asynchronous processing of events in a later blog post. We will not get into definitions of Custom Workflow Activities and Plug-ins or provide code samples since these are accessible from the CRM SDK documentation (click links to view).

As described in an earlier post “Custom Extensions Discussion - Intro”:

The best way to approach the custom extension capabilities of Microsoft Dynamics CRM 4.0 is to first fully understand your business processes, specifically which parts of those processes are causing you pain or costing your business money. The next step is to build those processes into CRM using the base CRM functionality and then re-examining your system to see which pain points remain. Then, with a good working understanding of all the ways you can extend Microsoft CRM, design your custom extensions to relieve the remaining pain points while taking into account the pros and cons of each custom extension approach.

Creating workflows through the CRM client (without calling custom assemblies) is a powerful way to improve business process facilitation. Basic workflow provides many benefits: no need for .NET expertise to develop, easy to modify (no code changes required), and you can export and import them like customizations. However, basic workflow also has its functional limitations. Fortunately, Microsoft Dynamics CRM 4.0 supports Custom Workflow Activities and Plug-ins for calling custom .NET assemblies to extend beyond basic workflow limitations. Given their similarities, it can be difficult to decide which method to use. Below are guidelines to consider when choosing your extension tool.

High-level Usage Guidelines

1. Custom Workflow Activities can only execute.NET assemblies asynchronously, while Plug-ins can execute .NET assemblies both synchronously and asynchronously. If you have already decided that your extension needs to execute synchronously, the choice is simple: Plug-ins are the only way to go. Synchronous and asynchronous event execution will be covered in detail in a following post with a description of the Execution Pipeline Synchronous vs. Asynchronous and examples.
2. If your .NET assembly is one step in a multi-step workflow, use Custom Workflow Activities. Workflow maintenance is simplified when all of the processing logic is in one place. This is especially true if a business process requires a mix of basic steps and Custom Workflow Activities to occur in a specific order. If you instead put your basic steps in a workflow and register you custom code as an asynchronous Plug-in, you’d have two places to maintain the processing logic and you would not be able to control the order in which the plug-in and workflow execute.
3. If you want to track a history of when your .NET assembly was run against an entity, use Custom Workflow Activities. Otherwise, use Plug-ins. Each time a workflow runs, a record of it is audited in CRM. This can be useful in some cases and distracting or unnecessary in other cases.
4. If you want the flexibility to easily disable or change what triggers a .NET assembly without changing code, use Custom Workflow Activities. Using Custom Workflow Activities within a workflow gives you the flexibility to publish and un-publish changes to the “Start when:” settings on the workflow form. It also allows users to run .NET assemblies against records as an on demand workflow.  The ability to quickly remove or add in custom logic to a workflow that business users can control can be very helpful especially with processes that are either dynamic or will be changing frequently.
5. If none of the above applies, it comes down to personal preference. We suggest Plug-ins. Generally speaking, it simplifies business logic maintenance to manage most of your .NET assemblies in the same place. Since Plug-ins can do both synchronous and asynchronous processing, and there is a good chance your system will require synchronous plug-ins at some point, it makes sense to register the asynchronous .NET assemblies as Plug-ins as well.

Conclusion

To close, there are quite a few things to consider when deciding when to use Workflows with Custom Workflow Activities and when to use Plug-ins. If you intend to register your .NET assembly synchronously or you don’t intend to leverage any of workflow’s basic functionality, use a Plug-in. If you’re ok with asynchronous processing and your .NET assembly is a sub-process in a contiguous workflow, you want an audit history, or you want to ease event trigger administration, use a Custom Workflow Extension.

- Phil Edry & Hoss Hostetler