As you begin to dive into Microsoft Dynamics CRM configuration, it is helpful to follow a few standards, best practices and tips that will help you and future administrators of your system. Sometimes, the smallest details make the biggest impact when it comes to future development, configuration and administration.
Here are a few tips to help you along the way.
Field Naming Conventions:
It is a good idea to keep your naming conventions in order to allow for simple navigation and back-end viewing of your database. Specifically, there are a few types of fields that can be aided by some standard protocols.
Lookup Fields: You should always add an “ID” at the end of the schema name of any lookup field. The schema name is essentially the Database Object name of the field. When it comes to querying the database through SQL and FetchXML – it is nice to see the ID in a field name which will immediately let you know it is a reference to another entity. Example: Field Name: Account Schema Name: new_AccountID instead of new_Account
Two Option Set Fields: You might want to add the prefix of “is” before the remainder of the name in the Schema Name of a two option set. More specifically – any “Yes/No” two option set. This will make it very easy to see from the backend that this is a Boolean type field and there will only be 2 possible values in this field when your query returns the results. Be sure to set Yes = 1 and No = 0 as this is the most common understanding of the data values.
Relationship Naming Conventions:
This is an area that can get very sticky and you really want to keep it clean and standardized. This will ensure you will always know what the relationship means and what entities are involved with it.
Out of the box, where you create a lookup field it will assign a default name to the relationship. Unfortunately if the entity is a custom entity it will add an additional Publisher Prefix in front of the relationship name. Example: “new_new_Entity…” It is always advisable to remove that extra prefix so as to avoid redundancy.
Now….to take the relationship names to the next level you can also add in the nature/context of the relationship. It is going to be one of 3 different types: One to Many, Many to One or Many to Many. If you are creating a relationship between Contact and Account, Account being the parent entity and Contact being the child entity – you could use the following naming convention if it suits you: “Account_1toN_Contact_AccountID”. This signifies that the Account entity is on the “One” side, or the parent side, and the Contact entity is on the “Many” side, or the child side.
There are 2 types of views I recommend using often in building your customized Dynamics CRM system. Lookup Views and Sub-Grid Views.
Lookup Views will be useful for every entity you plan on having Lookup Fields to. For example, having a Lookup to the Account Record on a Custom entity. In these instances, you want to be sure to have the columns/fields that are most prevalent to that screen to make choosing the correct value the easiest possible for the end user. It may be a few fields that constitute uniqueness, or simply the most recognizable to the end user. Either way – be sure to create a view called “EntityName Lookup View” and use that view on the form where the lookup field sits.
Sub-Grid Views are also a mechanism that easily allow you to identify which view to use when building a sub-grid on a form. Your “child-type” records will often times be displayed in a sub-grid. Create a view called “EntityName Sub-grid View” and it will make it easier for you to configure the sub-grid. Also, often times what you see in a sub-grid view on a form is different than a related record screen – therefore having a completely distinct view for this purpose is helpful to not interfere with the Out of the Box views like “Active”, “Associated”, etc.