I am asked frequently about the process of creating plugins use on the Common Data Service (CDS), CRM on-premise, or for use within CRM 365 Online.

The great news is that the plugin coding, for the most part, is going to be identical across these deployments. There are some differences, but it depends on the the clients needs as to why they are usually running one version of CRM or another.

What is a plugin?
In case you have never built a custom plugin put simply, it is one of the most sustainable ways to develop your code long term on the Dynamics platform. It allows you to write custom functionality in CRM that can be shared across CRM deployments.

Plugins allow you to write your own custom functionality on top of Microsoft’s event-driven dynamics platform for just about any process you can imagine.

Here are some of the top things I have learned from many years of custom CRM development.

Make sure you have leveraged the built-in platform options first
First and foremost, make sure that this functionality doesn’t already exist in the platform. I know that this may seem like complete nonsense, but you would be surprised at the types of customization in CRM that exist out there in the wild.

Many of these customizations were put in place by a developer that decided the only answer required a custom plugin. In many cases, a simple workflow, business logic or even a simple JS script could have been used to solve the use case.

In short make sure a plugin is actually needed for the use case at hand, and don’t be afraid to use the OOB Tools, they are actually pretty good.

2.) Don’t reinvent the wheel with your plugins
Ok… I have to say it, but how many times do we need to build an auto increment number plugin for your instance? Make sure that you have leveraged the marketplace as there are sometimes solutions that exist out there for free!

Remember you are a CRM Developer (in most cases) if you are reading this article so you get paid to solve problems.

As a CRM Developer, you love to build things, but at the same time, you should focus your time and energy solving solutions that can’t be solved with a free off the shelf plugins.

3.) Make sure that the Entity supports the Event you are after
CRM, CDS and CRM 365 are extremely flexible and lend itself to just about any scenario you could possibly need. When you perform your discovery make sure that the entity supports what you are trying to do. Not when you have reached the plugin registration process on your Test environment for the customer. That is not the time to realize the option isn’t available for the entity in question.

4.) Mock up the plugin functionality- pseudo-code is your friend!
Make sure that you have spoken to either the project manager, team lead, or in some cases the actual user and walked them through what is going to happen, cover when/how the plugin is triggered, and explain the process that follows.

I have found that a simple workflow diagram, pseudo-code, or even just commenting it all out in the plugin will help with this process. It will help you as the developer to cement the workflow that they are trying to achieve with the solution.

When you start coding you will have all the discovery that can be broken up into small blocks of functionality (methods). Then you just work one block at a time to handle the requirements efficiently.

You should strive for clean, self-documenting code, but don’t worry about suing a comment here and there. Remember, you are going to most likely be the person reviewing this code later on so don’t over complicate it for yourself later on.

6.) Use the built-in CRM Plugin Trace Functionality
So, I still cringe a little when I see a custom log file being generated from the plugin that writes to the physical server. My best example of this was a developer who built a custom plugin to call a web service outside of CRM to log any issues with the plugin.

Then there was a custom Tibco integration that ran at scheduled intervals that pulled the details back into CRM into a custom entity so it could be seen by the users of the organization. In short, don’t be like this CRM Developer, this is code that was eliminated from the scope very quickly.

7.) Make sure that you are using the Remote Debugging capabilities
It is a horrible existence to try and approach custom CRM plugin development without stepping through the deployment and your code when things go wrong.

The debugging may sometimes give you an exact line, but in many cases, it isn’t going to help. Especially if you are going to be creating a custom entity in the plugin. Most of the time you will get the failure at the entity and it will not give you a great clue about what happened.

8.) Know your required entity fields and attribute types
So this goes for whether you are going to be creating new entities inside your plugin programmatically, or if you are planning on updating an existing entity in CRM. Knowing what is required and in what format the data should be will help tremendously for your coding efforts in the platform.

You can always head out to the documentation of your specific version of Dynamics CRM in order to view the entity and what fields are required. The documentation will additionally show what type of attribute is expected EntityReferences, DateTimes, OptionSets, etc. so you will be able to make sure and pass the correct structure to CRM.

9.) Use the Sandboxes – (CRM Online) | Dev/Test Instances (CRM On-Premise)
This seems to go without saying that for proper development you should adhere to the best practices for your code. Having a development, testing, and a production site is essential to the life-cycle of your custom code in CRM.