Customization Best Practice

A cleaver developer thinks configuration first before customization

Although Dynamics CRM provides flexibility to customize the solution, we need to be very cautious customizing the CRM objects. A cleaver developer chooses configuration first instead of customization. So always think twice if a specific task can be configured first than you go for customization.

Follow the below points for better customization practice.

Use Custom Attribute not Entities

• Always focus to save server space. Use existing entity and add custom attributes to achieve a specific task as much as possible.
• Rename existing entity to make the entities more meaningful to fit the business requirement.

Use Meaningful Attributes & Entities

• Create custom attributes with meaningful Display Name and Schema Name.
• Avoid changing the Form label of attributes very frequently.
• Keep Display Name, Schema Name, Form Label Name & Logical Name same.

Use Searchable & Requirement Level Wisely

• While adding new custom attribute do not leave the searchable and requirement level property as default. Set these values as per proper business requirement.
• Set the field’s Searchable file as “NO” if you don’t want to show this field in Advance Find Query.
• While creating fields mention a meaningful description for all fields without being lazy.

Use Existing Entities to Avail Built-in functionality

• Customize a system entity, such as the opportunity entity, instead of replacing it with a new custom entity so that you can use the many built-in features in an existing entity.
• For example, the opportunity and case entities have lookup fields to associate customers. Customers may be accounts or contacts. You cannot create a custom entity that has the same type of lookup. You can change the display name of a system entity to make it more meaningful to your business.

Don’t Customize Default Solution

• Using “Solution” we can package all customizations which gives a flexibility in distributing the customization to other environment or to marketplace or to other organizations.
• Always create custom solution and add all components to that solution.
• Do not customize the default solution. Decide how to manage the custom solution and export it as Managed or Un-managed solution.

Don’t Customize Directly in Production

• As a software development best practice there should be different environment for solution deployment like: Development (DEV), System Testing (ST), System Integration Testing (SIT), User Acceptance Test (UAT), Training, Pre-Production (PRE-PROD) and Production (PROD),.
• Do all development activities, customizations in DEV environment. Never ever customize the CRM directly in production.
• This is a quick intention to change directly in target environment for a quick fix but please avoid this activity.

Decide when to Use Plugins V/s Workflows

• There are various ways to customize a CRM system. Like Java script, Plugins, Custom Work-flow Activities, custom .aspx web pages etc.
• When to use a Plugin or workflow depends on the business requirement and the customizer as well.
• If you want to execute custom code immediately before or after the core platform operation executes and before the result of the operation is returned from the platform, then you must use a synchronous plug-in or real-time workflow. You cannot use an asynchronous workflow or asynchronous plug-in in this situation because they are queued to execute after the core operation finishes executing. So, you cannot predict when they will run.
• Plugins are targeted to run within 2 minutes otherwise it will throw time out exception rolling back the functionality. So here for this case also we need to very sure to use correct way of process.
• Analyse these techniques and choose the one that best suits your business objectives after you consider the deployment, performance, and maintenance concerns of your plug-in or workflow solution.
• Check out the characteristics and differences between Plug-in and Workflow to decide which is the best option for your requirement.

Use Single Workflow instead of Multiple Child Workflow

• The child workflow approach achieves lower throughput, but it is more manageable if you frequently change your workflow definition. Compilation overhead is not a major concern because the workflow is compiled only during publishing.
• However, Microsoft Dynamics CRM incurs overhead when it starts each workflow instance. The overhead occurs when all entities that are used in the workflow are retrieved and the child workflow is started in a two-step process that includes a ‘Workflow Expansion Task’ and the actual workflow instance. Therefore, for maximum throughput, use a single long workflow.

Mark custom workflow activity as completed

• The return value from the Execute method is used by the workflow runtime to mark the activity as “completed.” You should use return base.Execute(executionContext) unless the activity bypasses base class functionality.
• Avoid returning ActivityExecutionStatus.Closed.

Use Exception Handing in Custom Workflow Activities

• You should throw an InvalidPlugInExecutionException in your code. This error will be shown in the workflow instance form.

Do not Interact with DOM elements using Javascript

• This very much allowed to use DOM (Document Object Model) elements in javascript and as Microsoft Dynamics CRM is a web application so these techniques works, but they are likely to break during an update because the names of the elements they reference are subject to change at any time.
• So every time we have to revisit our scripts to check if a specific DOM code that we have written is compatible with latest version or not which is really a boring re-work job to clean these code by alternative codes.
• Do not use JQuery in Form customization as this is not recommended. Only use JQuery in HTML web resources.

Never ever change the files in the Dynamics CRM application folder

• As Microsoft Dynamics CRM(On-Premise) is a web application so it is hosted in IIS and the files,folders are stored in selected drive on installation.
• Do not change the default web pages or any files from this folder as this will cause unexpected errors in CRM

Do Not Manipulate Data Directly in CRM Org SQL DB

• As Dynamics CRM uses SQL Server as its Database, so it is obvious that we can use asp.net application to retrieve data from CRM database with out calling CRM SDK.
• But this is strictly denied as direct database query by passes the security infrastructure of CRM which is the heart of CRM.
• The recommended practice is to use special filtered views to retrieve the data. This will apply the calling user’s security so that they can only see data that they should see.
• You can perform updates on the CRM data directly in the database tables. But the risk with this approach is that you can set invalid data that can break the application. Developers should always use the APIs(CRM SDK) provided with the application platform web services to update data.

Consideration Changing the DB tables, SProcs and views

• If you have Microsoft Dynamics CRM on-premises you can use database tools to change the database. The only direct database changes that are supported are adding or updating indexes. You should use the customization tools to add any new entities or entity attributes.
• This is the only supported way to apply changes to these parts of the database. Any direct changes you make risk breaking the application or your ability to apply update rollups. Any changes you apply may be destroyed when you apply an update or during an upgrade and any data that you may have included in custom database table columns will be lost.

Avoid Record Reference in Workflow Design

• While creating workflows try to avoid using any reference to any record of the system as the record depends on primary key and when the solution will be deployed in other environment the record ID will be changed which will break the reference in the workflow.
• If there is a requirement to do this then always import the referenced record with Record ID in target environment first so that the reference will not break.

Do not forget to choose the correct filter attributes in Plugin Registration Tool for update message plugins

• While we create a plugin to run on update message of an entity then by default the plugin runs on update of any field of the entity record which may cause some unexpected result if it is not handled properly in plugin code.
• So to avoid unwanted issues always select correct filter attributes in Plugin registration tool by selecting the sdk step.

Use Indexes Wherever required

• When we use fetch XMLs or query expressions then ultimately it hits SQL Database as a SQL Query and if the CRM table you are querying involves large data or there is relationship with other tables then you will find performance impact in big projects.
• So Add required index on the table to optimize the CRM performance also minimizing database deadlocks.

Look Up Fields naming Convention

• When you add new look-up type field on an entity add a Suffix ID in the field name so that these fields are well identifiable.

Write Stateless & Lightweight Plugins

• Don’t declare class level variables in plugins
• Write codes in plugin which will run quicker and must not take more than 2 minutes.

Adding more… Please mention if I missed anything..