Plugins in Dynamics CRM

Basic Concepts of Plugins

Plugins are one of the most widely used components during customization that enable us to write custom code to enhance or modify the out of the box CRM functionality. For example, automatically populating fields from another entity, creating or updating related records, preventing record from saving or modifying based on certain rules, generating SQL Server reports behind the scenes and emailing them to specific people, or automating any kind of supported functionality when a record is created or modified.

A Plugin is written by creating a “Class Library” project in Visual Studio and using a .Net language like C# and Microsoft Dynamics CRM SDK assemblies, the most common among which are Microsoft.Crm.Sdk.Proxy.dll, Microsoft.Xrm.Client.dll and Microsoft.Xrm.Sdk.dll (Microsoft.Xrm.Client.dll is not available with CRM 2016 SDK).


Figure 1: Visual Studio Class Library Project


Figure 2: CRM SDK assemblies

After compiling the plugin, the resultant project assembly is deployed to CRM using the Plugin Registration Tool.

Figure 3: CRM 2011 Plugin Registration Tool

CRM 2016 SDK Plugin Registration Tool looks like the following:


Figure 4: CRM 2016 Plugin Registration Tool

Although the Plugin Registration Tool is available with each release of CRM SDK, I still find the 2011 version to be the most helpful as it also saves the list of all the previous organizations where I have deployed the plugin and makes it easy to connect with them in future.

Once the Plugin is deployed, we need to create Steps that allow the assembly or our custom code to execute when a record is created, modified, activated, deactivated, retrieved, assigned, deleted or any other event that takes place in CRM.


Figure 5

When a Step is created, we need to specify the Entity name, Message (event) name and whether the plugin should execute before or after the record is created/modified. For one assembly, we can create one Step on one entity and another or more Steps on different entities. We just need to handle different entities inside our plugin code but the Plugin Registration Tool will not stop us from creating a Step on any entity.

You will also encounter the concept of synchronous and asynchronous plugins during customization. Plugins are by default synchronous, meaning that our custom code will execute immediately when a record is created or modified. This can create a problem when we have a long running operation inside a plugin which will have a negative impact on the user due to slow response time. Moreover, the plugin times out if the operation takes more than two minutes. In such a situation, consider using Workflows that are asynchronous by default and you can also write your custom code inside a workflow just as you write inside a plugin.

You can configure both Plugin and the Workflow to be synchronous and asynchronous. As a rule of thumb, use Plugins for short lived synchronous operations where the immediate feedback about the changes should be visible to the user, and use Workflows for long running asynchronous tasks or operations that do not require immediate feedback to the user such as sending emails or populating related entity that is not visible on the page.

I the next article, we will see how to create a simple plugin. Stay tuned….