Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
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.
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”…));
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”;
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!
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”;
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.
Connect with us to know more about Microsoft Dynamics 365 and how it can help your business transform.
Download our eBook “15 Questions to Identify the Gaps in Your CRM”
The post Plugin Coding Best Practices In Microsoft Dynamics CRM appeared first on CRM Software Blog | Dynamics 365.
Business Applications communities