Customization Best Practices for Dynamics CRM

Create custom attributes for existing entities instead of creating a new entity.

Rename existing entities to make the entities more meaningful.

When to use plug-ins vs. 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).

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


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.


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


4 thoughts on “Customization Best Practices for Dynamics CRM

  1. Brad January 4, 2016 / 3:51 am

    Your blog layout is messed up. Cannot read most of article as your righthand sidebars overlap (both in Chrome and IE).


    • Mandar Joshi January 4, 2016 / 3:01 pm

      Thank you for letting me know Brad. I’m working on fixing this.


    • Mandar Joshi January 13, 2016 / 3:05 pm

      Hi Brad,
      The issue is fixed now. Please check. Thanks!


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s