CRM Developer Guidelines

In most engineering disciplines, there exists a set of guidelines in every field that ensures a high-quality delivery and the highest resistance to unexpected failure after going live. This is evident in our attempt to set as much of a foolproof software development process as possible; e.g. DevOps. In this article, I will explore some of the most effective CRM developer guidelines based on extensive research and the best expertise in our field.

Why bother?

Imagine building a tower without any rules to ensure safety, programming an aeroplane without constraints on performance, or creating sensitive medical equipment without limits on its accuracy and precision; guidelines make for higher quality products as efficient as possible.

Same applies to software: we could build a solution, perform testing, and then find out that under a certain type of load it fails; repeat the cycle again, wasting valuable effort. Alternatively, avoid what could lead to said failures, from the start, by following a set of principles. Those principles are usually shared by experienced people who fell into those pitfalls before us.

Sample of Important Developer Guidelines

Avoid using Object Type Codes

Object Type Codes change between environments. Sure, the out-of-the-box entities stay the same, but that’s because the core DB is practically cloned on organisation creation; however, when you create a new entity and then import it into a new environment, its Code is not maintained.

Never access the DB directly

Back in CRM 2011, there used to be two tables per entity. After CRM 2013 was released, the tables were officially merged to what we see today. Just knowing this fact would drive you to be cautious about directly accessing the DB for query or manipulation. It is definitely a major headache to maintain unsupported code when Microsoft decides to modify the internal workings of CRM.

Use Source Control

Even if you are working alone, or the company policy does not enforce a Source Control, it is highly recommended to use one. It allows for experimenting, parallel development, and bookkeeping with ease.

Don’t access the DOM

The same reasoning as ‘Never access the DB directly’: avoid accessing any code/component not supported for such access by Microsoft.

Use ‘getClientUrl’ instead of hardcoding the URL in code

It is recommended to avoid hardcoding any values that might change between environments during deployment. Even more so, it is recommended not to hardcode any values into your code. The better approach is to move configurations into a separate module and fetch those values using a standardised method.

Use OData v4 (Web API) instead of OData v2 or SOAP endpoint

OData v2 and SOAP are deprecated and will be removed soon; so, it’s best to avoid those APIs to have peace of mind when upgrading/updating CRM in the future.

Don’t use class-level variables in plugins

I cannot count how many times this has caused issues in production. Under certain loads, in certain entities, variables on the level of the IPlugin class could cause unpredictable and strange errors. It’s impossibly hard to debug and trace. Moreover, it easily leads to data integrity issues.

Avoid the following:

public class MyPlugin : IPlugin
{
	private IOrganizationService service;	// bad!

	public void Execute(IServiceProvider serviceProvider)
	{
		var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
		var serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
		service = serviceFactory.CreateOrganizationService(null);
	}
}

Don’t use threading in plugins

Plugins are not thread-safe. Using ‘locks’, ‘threads’, or the like in plugins causes unexpected behaviour — similar to class-level variables.

Separate web applications from CRM’s

In old versions of CRM, there used to be a folder where ISVs could host their applications under CRM. This is not the case anymore. In addition, hosting non-CRM apps under CRM’s in IIS could cause conflicting issues that you are better off avoiding. Finally, it provides for better security.

Define the ownership at entity creation

I have seen this too many times: some developers hastily set the Ownership of the entity to Organisation instead of User/Team. Unfortunately, this cannot be modified easily, which causes a major headache later when the need arises to use user-level security. Reserve Organisation setting to only entities that will never be owned by users; e.g. Countries.

Disable all options on entity creation

Some options cannot be disabled once enabled when creating an entity. For example, if you enable Business Process Flows, it will create fields and entities that cannot be deleted later, which could clatter the system unnecessarily. Said options usually have this sign ‘†’ appended.

Assign least privileged role and minimise security privileges

From a best-practice business perspective, users should never be allowed to do more than what they are allowed to by their company role. CRM aims to automate the company’s business; so, it should be a reflection of its rules as well. Restrict users to do what they are supposed to only.

Consider that fields are accessible in Advanced Find

A solution could be locked down tight from a UI perspective on the form — locked fields and such; however, the user can work around this by searching for the record and viewing/editing it through Advanced Find. To counter this exploit, one option might be to set the field as ‘unsearchable’. If the field must be searchable, add validation in a plugin to ensure that the business rules are adhered to at all times from any access point. For even higher security, enable Field Level Security on said field.

Full Guidelines Download Links

CRM Developer Guidelines – v1.4 – Word Document

CRM Developer Guidelines – v1.3 – Excel Sheet

Inlined Table

For convenience, below is the Excel sheet linked above.

References

Reference	Link
Microsoft Dynamics CRM Implementation Guide for CRM Online and CRM 2016 (on-premises)	https://www.microsoft.com/en-us/download/details.aspx?id=50039
Microsoft Dynamics CRM Implementation Guide for CRM 2015	https://www.microsoft.com/en-ca/download/details.aspx?id=45022
Microsoft Dynamics CRM Software Development Kit (SDK) for CRM Online and on-premises CRM 2016	https://www.microsoft.com/en-us/download/details.aspx?id=50032
Microsoft Dynamics CRM 2015 Software Development Kit (SDK)	https://www.microsoft.com/en-us/download/details.aspx?id=44567
Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM 2016 Performance and Scalability Documentation	https://www.microsoft.com/en-us/download/details.aspx?id=45905
Optimizing and maintaining the performance of a Microsoft Dynamics CRM 2011 server infrastructure	https://www.microsoft.com/en-us/download/details.aspx?id=27139
Optimizing and maintaining client performance for Microsoft Dynamics CRM 2011 and CRM Online	https://www.microsoft.com/en-us/download/details.aspx?id=23261
Deploying Microsoft Dynamics CRM 2011 and CRM Online Solutions from Development through Test and Production Environments	https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=27824
Patterns and Principles for CRM Online Solution Builders	https://blogs.msdn.microsoft.com/crm/2015/04/29/microsoft-dynamics-crm-online-patterns-principles-for-solution-builders/
Microsoft Dynamics Sure Step	https://mbs.microsoft.com/customersource/Global/SureStep
Dynamics CRM Community	http://www.microsoft.com/dynamics/crm/community/default.mspx
Dynamics CRM on MSDN	http://msdn2.microsoft.com/en-us/dynamics/crm/default.aspx
Premier Field Engineering CRM in the Field blog	http://blogs.msdn.com/b/crminthefield/
Dynamics CRM Product Team Blog	http://blogs.msdn.com/b/crm/
Microsoft Dynamics CRM Online patterns & principles for solution builders white paper	http://go.microsoft.com/fwlink/p/?LinkID=533946
Best practices for developing with Microsoft Dynamics CRM	https://msdn.microsoft.com/en-us/library/gg509027.aspx
Dynamics CRM and User Experience (UX)	https://crmgiant.eu/research-and-discussion/dynamics-crm-and-user-experience-ux/