When to use plug-ins vs. workflow?


As a developer who is interested in extending or customizing Microsoft Dynamics CRM, you can choose from several methods to perform your tasks. In addition to adding client-side JavaScript code to a form or adding custom ASP.NET pages, you can write a plug-in or create a custom workflow by using the web interface that calls a custom workflow activity. How do you decide when to use a plug-in and when to use a workflow? The technology that you use depends on the task that you have to perform and who will author the customization.
For example, you must use a synchronous plug-in real-time workflow if you want to execute custom code immediately before or after the core platform operation executes and before the result of the operation is returned from the platform. You cannot use an asynchronous workflow or asynchronous plug-in in this situation because they are queued to execute after the core operation finishes executing. Therefore, you cannot predict when they will run. If you want to add custom functionality to Microsoft Dynamics CRM Online, workflows and plug-ins are supported, but custom workflow activities are not.
Evaluate these technologies and select the one that best suits your business objectives after you consider the deployment, performance, and maintenance concerns of your plug-in or workflow solution.
The following table summarizes the characteristics of plug-ins and workflows.

 

CriteriaPlug-inWorkflow
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).
Asynchronous workflows are queued to execute after the core operation.
Real-time workflows have similar characteristics to plug-ins.
Performance impact on the server
Synchronous plug-ins can increase the platform 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.
Asynchronous workflows have less impact on server response time because the code is run in a different process.
Real-time workflows have similar performance characteristics to sandboxed plug-ins.
Security restrictions
To register a plug-in with the platform requires a System Administrator 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 are supported by all CRM deployments. Custom workflow activities are supported in the sandbox of Microsoft Dynamics CRM Online, and in or outside the sandbox for on-premises/IFD deployments.
Length of processing time
A plug-in registered for synchronous or asynchronous execution is restricted to complete its execution in a two-minute time limit.
Works well for either short or long processes. However, each activity in a workflow cannot take longer than two minutes to complete.
Works when the 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 until they are completed. Plug-ins must be written to be stateless where no in-memory data is persisted.
Asynchronous 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.
Real-time workflows cannot have any wait states. They must execute to completion just like plug-ins.
Impersonation
Plug-ins can perform data operations on behalf of another system user.
Asynchronous workflows cannot use impersonation, while real-time workflows can. Real-time workflows can execute either as the owner of the workflow or as the calling user.
Authoring
Software engineers or programmers can author plug-ins.
Anyone, including an end user, business analyst, or administrator can author workflows if they have the proper permissions.
There is no significant performance impact on the server between an asynchronous plug-in and a workflow.

What type of workflow is better?

From a performance perspective, is it better to create a single long workflow or is it better to have multiple child workflows and call them in one parent workflow? The child workflow approach achieves lower throughput, but it is more manageable if you frequently change your workflow definition. Compilation overhead is not a major concern because the workflow is compiled only during publishing. However, Microsoft Dynamics CRM incurs overhead when it starts each workflow instance. The overhead occurs when all entities that are used in the workflow are retrieved and the child workflow is started in a two-step process that includes a 'Workflow Expansion Task' and the actual workflow instance. Therefore, for maximum throughput, use a single long workflow.

How should you mark your custom workflow activity as completed?

The return value from the Execute method is used by the workflow runtime to mark the activity as “completed.” You should use return base.Execute(executionContext) unless the activity bypasses base class functionality. Avoid returning ActivityExecutionStatus.Closed. More information: ActivityExecutionStatus Enumeration

How should you report exceptions in custom workflow activities?

You should throw an InvalidPlugInExecutionException in your code. This error will be shown in the workflow instance form.

Can you define custom entities that are specific to business units?

Custom entities have privileges for each security role but not for each business unit. To define custom entities that are visible only to specified business units, you must create different security roles for each business unit and grant privileges to the custom entity in the appropriate role.

Comments

Post a Comment

Hi,

If any one want to give the stagnation and change its most welcome.

Thanks!!
Rajesh Singh.

Popular posts from this blog

Many to Many Relationship in Dynamics CRM 2011.

Image
I get asked about many-to-many (a.k.a. N:N) relationships more than just about any other single topic, so here’s a summary of how they work in Dynamics CRM 2011. I’ll review both “native” and “manual” N:N’s, using a simple Association to Contact relationship to illustrate. This is a classic many-to-many: each association should be able to have multiple contacts associated with it, and each contact should in turn be able to be associated with many associations. Native N:N Relationships With native N:N relationships, you open up an entity for customization, click the N:N relationships link, and click the  New Many to Many Relationship  button and select the entity to create the relationship to. For the Association to Contact N:N relationship, I’ll start from the Association entity: In the previous figure, notice that Do no Display is selected in the Display Option for each side. I only show that to illustrate a point: what this will do is prevent the relationship from being displ
Read more

Create a Custom Workflow Activity...

Image
Required Software and Assemblies To develop Windows Workflow Foundation 4 custom activities, you must develop them on Microsoft .NET Framework 4. If you plan to register your custom workflow activities with Microsoft Dynamics CRM Online, you must build them using the Microsoft .NET Framework 4  PU3  (platform update 3) or a later version, such as .NET 4.5. The following assemblies must be added as references in your project. They can be found in the  SDK\Bin  folder in Microsoft Dynamics CRM SDK. Microsoft.Xrm.Sdk.dll Microsoft.Xrm.Sdk.Workflow.dll Use the CodeActivity Workflow Base Class To create a custom workflow activity, create a class that inherits from the  CodeActivity  workflow base class. This class is available in the  System.Activities namespace. Activities that inherit from the  CodeActivity  class can override the  Execute  method to produce custom functionality. To create a custom activity that inherits from CodeActivity Start Microsoft Visual Stud
Read more

Difference between CRM Discovery Service and CRM Metadata service?

CRM service - when we need ORG related information like ORG name, Properties, CRM service path for this ORG -- then we use CRM discovery service. This is only to get the ORG related information Metadata service - we use this when we need to interact with the CRM records – create, update or delete anything-- it is very specific to the CRM records. When we need to interact with the CRM entity and attribute - like create an entity (not record) or attribute -- add a value to pick list-- retrieve the pick list value retrieve the entity properties-- attribute property and all we need Meta data service.
Read more