Introduction

Imagine building a tower without any rules to ensure safety, programming an airplane 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.

In every engineering discipline, 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.

Dynamics 365 CRM 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 organization 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 standardized 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:

Don’t use threading in plugins

Plugins are not thread-safe. Using ‘locks’, ‘threads’, or the like in plugins causes unexpected behavior — 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 Organization 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 Organization 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 minimize 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.

References