Working as a CRM developer for many years I have learned a lot about creating, maintaining, and deploying Microsoft CRM Plugins. I know that there is a ton of information on how to build your first plugin. Even if you don’t plan on coding a plugin yourself, this will help you understand the technical ins and outs of Dynamics CRM Plugins.
So what exactly is a Dynamics CRM Plugin? A Dynamics CRM Plugin provides the ability to create custom logic within the Dynamics CRM platform. Plugins are custom code that attaches to CRM’s built-in event pipeline. This allows developers to extend the default behavior of CRM so they can tailor it exactly to your specific organizational needs.
How does a Microsoft Dynamics CRM Plugin work?
The basic principle is that every time you perform an action in Microsoft CRM there is a process running behind the scenes known as the event execution pipeline. A plugin is just a piece of code that tells CRM to do something extra that it doesn’t already do when a certain action occurs.
So let’s take a simple example to illustrate this idea even further.
When you log in to CRM and do a simple action let’s take something we all have done in CRM. Creating a new account. When you start creating an account a form pop in a new account you are performing actions in the UI, but nothing has happened yet with a plugin until you hit the save button.
Events
When you hit the save button this fires an event and that tells CRM that you are in the process of saving a new account.
Events are how plugin code is fired. You register your custom plugin logic within CRM to events and types of records in CRM. Microsoft CRM will then listen each time those events occur and will run your code along with whatever the default process is that you are tied to.
Here are just a few examples of common events in CRM:
- Save – saving of a record
- Create – the creation of a new record
- Update – update of an existing record
- Assign – assignment of a new/existing record
- Delete – removal of an existing record
What is the CRM Event execution pipeline, and how do you use it with CRM plugins?
It is the job of the CRM event execution pipeline to manage when the default unchangeable code of CRM runs, and when your custom plugin code will run. Essentially the pipeline ensures that important system functions do not overrun each other in the process.
Stages
You tell CRM what events to run your plugin code in, but also in which stage is appropriate for your custom plugin.
Let’s explain. When you hit the save button on a new account record you create in CRM there are actually 3 primary stages of the event execution the save process will go through before it is completed.
The first stage is the pre-validation stage, in this stage CRM is ensuring that information is entered correctly on the record before continuing. So if you have additional validation you need to perform this stage will be useful for your plugin.
The second is the pre-event/pre-operation stage. This is the stage that happens right before the data you entered on the record is committed into the database. This is also the stage you most likely want to register to if you need to change values before the information is stored in CRM.
Lastly is the post-event stage. This is the stage that happens right after the commit of the information into the CRM Database.
You tell CRM which of these stages best fits the needs of your plugin. So why would you want your plugin to run in a specific stage?
For example, if you wanted to grab the ID of your newly created account record you would want to register your code on the post-stage event.
Why? This is because the save has already happened of your new record into the CRM database. If you run the plugin in another stage you cannot get back the record id that was created because the action hasn’t actually been performed yet.
So, how do you upload the Dynamics CRM plugin code into your CRM environment?
This is done using the Dynamics CRM plugin registration tool. This tool does not come pre-installed in CRM but rather is in the SDK for your particular release of Microsoft CRM. You can download the SDK toolkit directly from Microsoft for free.
When you have downloaded and installed the CRM SDK you will find the plugin registration tool under the SDK > Tools > Plugin Registration folder.
When you start the tool you must choose a Dynamics CRM instance to connect to (on-premise or hosted in the 365 cloud).
Once connected you will be able to upload your custom plugins through a process known as registration. This is where you are uploading your custom code created from your favorite development tool (most likely visual studio) into CRM.
Your custom code will also be validated before the registration process is completed. Once you have registered your plugin code you can then tell CRM exactly when your custom Dynamics CRM Plugin should fire, on what events, and what stage in the execution pipeline.
In the image below I am telling CRM I want to fire my custom code when new accounts are created. But I want it to wait until the account has finished saving and I am choosing to run this synchronously (immediately).
Why choose a Dynamics CRM Plugin over Business logic or built-in Workflows
Business logic, javascript, and workflows all have their place within the Microsoft Dynamics CRM platform but plugins can handle more complex needs since plugins are only bound by the limits of the .NET platform.
You have to remember that CRM itself is built on the .NET platform so plugins can be extremely flexible and serve a wide range of use cases that workflow, javascript, and business logic simply cannot handle.
What language are Dynamics CRM Plugins written in?
Dynamics CRM Plugins are written using C# .NET.
What do I need to create a plugin that can be used in Microsoft Dynamics CRM?
You can use any edition of Microsoft Visual Studio to get started writing your custom plugins. You can download a free release of Visual Studio, or use VS Code. Just as long as the IDE you choose provides the ability to compile the C# plugin code you are good.
What are the differences between running synchronous and asynchronous Dynamics CRM plugins?
If you are writing a plugin and you would like for the user to be notified throughout the process you would choose to run synchronously. This means when the task of the plugin is completed the user can be prompted, or if an error occurs they will receive a notification on the screen.
There may be times however that you want to run your plugin asynchronously, which means the process will start and finish in the background.
Running the plugin in this way will not limit the user from performing their normal processes and any errors will be logged in the background and not displayed down to the user.
Is there a limit to how long my Dynamics CRM plugin can run?
Yes, the maximum amount of time that a plugin can run is 2 minutes. This limit is true even if the plugin is registered to run asynchronously in the background. If you need a much larger time frame to run then a plugin may not be a great fit for and you may be better off with a custom workflow that accomplishes the task you are trying to accomplish.
Should I choose to write my plugins with an early or late-bound code strategy?
This depends I have used both and there are pros and cons to each approach, and sometimes you will change your mind later on so let’s get into the specifics of why you would choose one or the other.
Early Bound Plugin Code
When you take the early bound approach, for example, it is much easier to determine the exact type of attributes that you need to populate for a given record type. This makes development a bit quicker at times especially for other team members who are not as familiar with the CRM datatypes and specifics of the CRM objects.
The primary danger of going the early bound route that I have seen is that you could find that your Dynamics CRM plugin becomes bloated or very large from the generated user classes that are created and appended which allows you to support all the validation and IntelliSense upfront.
It is for this reason in a large CRM deployment with many custom entities, I usually choose a late-bound strategy for my plugin development needs.
Late Bound Plugin Code
If you use a late-bound approach the end result requires that you know a little more about the record and datatype you are working within your plugins but will be a bit faster and if you have a lot of plugins then you will also be able to stay under the max size limitations easily.