Best Practices for developing with Microsoft Dynamics CRM Part2

Configuration is one of the most fun and essential aspects of Microsoft Dynamics CRM. Creating entities, fields, relationships , labels and what have you are as fun as playing online games and winning against a nine year old kid, if not more (at least that’s what we think!). However, what makes the CRM experience worthwhile for everyone (from system administrators to the end users) is consistency in design of the CRM architecture. What we need is a set of best practices for configuring Dynamics CRM.

We’ve made a checklist of sorts that you can use when you are configuring Dynamics CRM on your own. Think of this checklist as a recipe to create magical unicorn dust that you can sprinkle on your CRM. It should help you incorporate consistency in your CRM configuration and eliminate frustration! Keep these items in mind when you’re customizing and configuring Dynamics CRM and enthralling your users with CRM abracadabra!

1. Don’t forget to create icons for custom entities !

2. Clean up forms. It is a good idea to remove fields from the forms that may not be used. ( Accounts/ Contacts/Leads/Marketing).
3. Test your forms and make sure fields are arranged in the correct tab order.
4. Make unused out-of-the-box fields hidden so they don’t appear in Advanced Fields. Two posts that can help you out with this are updating attributes that aren’t being used , and bulk editing field attributes .
5. Clean up navigation area on each record to remove items not being used right now. Take a look at our post on modifying the left navigation for individual records for more info.
6. Enhance specific uses of Dynamics CRM, from marketing to sales to productivity, with Power Objects’ Power Pack add-ons .
7. Remove areas and sub-areas from the sitemap that would not be used. Here’s a good reference on sitemap editing .
8. Know when to turn OFF auditing!.
9. Create consistent views for each entity–use view replicator! Also, don’t forget to rename views for renamed entities! .
10. Make search better–install PowerGlobalSearch and/or PowerOneview ; add fields to ‘QuickFind’ view.

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.
1. Use Custom Attribute not Entities
Always focus to save server space. Use existing entity and add custom attributes to achieve a specific task.
Rename existing entity to make the entities more meaningful.

2. 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.

3. 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.

4. 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.

5.Don’t Customize Default Solution

Using “Solution” we can package all customizations which give flexibility in distributing the customization to other environment. Always create custom solution and add all components to that solution. Do not customize the default solution.

6. 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), Pre-Production (PRE-PROD) and Production (PROD).
Do all development activities, customizations in DEV environment. Never ever customize the CRM directly in production.

7. 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.

8. 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.

9. 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.

10. 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 (execution Context) unless the activity bypasses base class functionality.

11. Avoid returning ActivityExecutionStatus. Closed.

12. 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.

13. 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.

14. Do not use JQuery in Form customization as this is not recommended. Only use JQuery in HTML web resources.

15. Never ever change the files in the Dynamics CRM application
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.

16. Do not change the default web pages or any files from this folder as this will cause unexpected errors in CRM

17. Do Not Retrieve/Update Data Directly from Database

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 without 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.

18. Changing the database tables, stored procedures, or 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.

19. 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.

20. Do not forget to choose the correct filter attributes in Plugin Registration Tool

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.

21. 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.