12/17/2019
By Nikhil Rajendran | Reading time 6 mins
In any Microsoft Dynamics CRM instance, there are functionalities requested by the stakeholders which go beyond the functionalities offered by the Out-of-the-Box CRM instance.
To deliver these functionalities we often need to write plugins. As a developer, if you have coded long enough on a project and know the CRM instance well, it is very easy to get complacent. It could also be that you’re tired. You need to just get the functionality out of the way and go home.
It is during these times that we just throw the best practices out of the window. When we do that, it eventually comes back to you in some way or the other. I have experienced this! So it is better to just get it right the first time.
Let us look at some of the best practices while writing plugins in Dynamics CRM.
15 Questions to Identify the Gaps in Your CRM
Retrieve:
Always retrieve only the columns (fields in Dynamics CRM) which are needed. There might be an instance where you’re retrieving the fields of a custom entity. This entity could be a small entity with very few custom fields.
You might need all the custom fields of that entity. At that time, we tend to write the following:
Entity localEntityName = crmService.Retrieve(“entityLogicalName”, “entityGUID”, new Columnset(true));
The above method is definitely bad practice. The reason is, though you might need all the custom fields, there are some out-of-the-box fields for an entity that we tend to forget. For example, in the above scenario, you might need all the custom fields of the entity.
However, you might not need the out-of-the-box fields like “createdon”, “modifiedon” etc. These fields will also get retrieved if you use Columnset(true).
Therefore, it is better to specifically mention the fields which needs to be retrieved. The following is best practice.
Entity localEntityName = crmService.Retrieve(“entityLogicalName”, “entityGUID”, new Columnset(“field1_logicalname”,” “field2_logicalname”,” “field3_logicalname”…));
Update:
In the above example, let’s assume that you retrieved ALL the fields of the entity. That is, you followed the bad practice. Once you have retrieved it, you need to read the values, perform some data validation, and based on that you need to update just a couple of fields in the retrieved record.
At that time, we tend to write the following:
localEntityName[“field1_logicalName”] = “value”;
localEntityName[“field2_logicalName”]= “value”;
crmService.Update(localEntityName);
The above method is something that should be avoided when writing plugins. There are a few reasons why they are considered to be bad practice.
It creates unnecessary auditing records. When the above method is used to update ALL fields of the entity is updated. The reason is you are updating the “localEntityName” entity.
This entity contains all the fields of the entity. When we write crmService.Update, all the fields of the entity are updated even if you did not explicitly mention a new value for each field. When you did not explicitly mention a value, the old value is again updated to the field.
It creates a record in the Database which is similar to the following:
The audit table is one of the largest, if not the largest database in a CRM organization. It is important that we do not create unnecessary audit logs like the above because of the way we have written code.
Have you experienced any random SQL errors in your CRM organization? Well, that’s probably because of your organization’s Audit table!
- As mentioned, all fields are getting updated. You might have a workflow that is running on the trigger of update of one of the fields which you did not mean to update. This workflow will be triggered when it is not supposed to be and cause errors in the system. It will also create unnecessary load on the organization’s Microsoft Dynamics Asynchronous Server (which is responsible for running the processes). If there is a lot of load of the async server, it will require a frequent restart.
In the above scenario, say you want to update two fields only. The following is the best practice to update those two fields.
Entity updateEntityLocalName = new Entity(“logicalname”);
updateEntityLocalName.Id = localEntityName.Id;
updateEntityLocalName[“field1_logicalName”] = “value”;
updateEntityLocalName[“field2_logicalName”] = ”value”;
crmService.Update(updateEntityLocalName);
So in the above example, only the fields which are needed to be updated are updated. There are no unnecessary audit logs created in the Database as well.
Author’s bio:
Nikhil has been with AhaApps since 2017 as a Microsoft Dynamics CRM Developer. He is a driven CRM expert who is ready to fight off the challenges in the Dynamics world with his technical know-how and prowess. He is a sports enthusiast and loves to play tennis when he gets time. He is also a voracious reader and enjoys reading philosophical books.
Javascript Coding Best Practices For Dynamics 365
Javascript is fairly unreliable. Unless you know a few best practices.