This is the last part in the Microsoft Dynamics CRM configuration series. The topics covered here go a little deeper…perhaps spanning into more intermediate/advanced configuration. Nonetheless, I think they are things that every configurator needs to be conscious of and will help you in your pursuit of quality CRM configuration for Microsoft Dynamics.
Whether you manually create a relationship, or it is auto-created through creating a Lookup field, one thing that can be forgotten is the Tile Navigation Display. When it comes to the UI, you want to ensure that only relevant navigational items are viewed by the end-user. This avoids confusion and in some cases, improper functionality. In cases where a relationship is built, you should always navigate to the relationship itself and decide whether you want it to be “Displayed” or not. In this instance, we are talking about the Tile Navigation. If you are creating a sub-grid on a form and you don’t want a user to be able to navigate through the related records tiles, then you must set it to “Do Not Display” in the relationship. This is even more important in cases where you have multiple fields looking up to the same entity. You will have multiple navigation tiles to the same entity in the Navigation if you do not manage this well.
Another VERY important component of relationships is the ability to do field mapping. This piece is vital to the efficiency of Dynamics CRM, but takes very careful consideration to the User Flow. What I mean by that is, you must decide how the user will optimally flow through the system and create records. If you want to create Contacts and always want them related to Accounts, then perhaps the best place to create them from is a Sub-grid on an Account record. In this instance you can automatically “Map” in the AccountID to the contact when generating a new Contact record. You may also be able to map in many other field values that make the user more efficient in the system. At all costs you should save the user time and effort of data entry and utilizing the relationship field mapping is a great way to do so.
There are a few things that can make your life easier when configuring for multiple Orgs in Dynamics CRM. One of the biggest time-savers relates to using look-ups.
Quite often, you configure a View or a Workflow to use a Lookup value. In this case, Dynamics CRM is leveraging the GUIDs of the records behind the scenes of the Lookup record. Normally, most folks would simply choose the field name that references the look and then choose the record they want to filter by, trigger by or check a condition on. The down side of this is when you pass this Solution to another Org, CRM will make you re-choose manually the value you are trying to leverage in these cases.
A simple fix to this is having a “Code” field that becomes a unique and distinct value assigned to Lookup records. When it comes time to configure a View or Workflow, instead of using the field name on the Primary Entity, you would change the entity to the one referenced in the Lookup. For the field you would choose the “Code” field. If this value is truly distinct in the system, then you can say “Where Code = Specific Value”. In the end you will get the same result as if you had chosen the lookup value, however when the Solution gets passed to another org, it does not need manipulation due to the fact that it is a String comparison instead of a GUID/Relational comparison.
Oh and of course, not to be too obvious…but be sure to always develop and configure within a predetermined Solution file. This will make your configurations/development efforts more easily managed, transferred and adjusted.
Our experts at RSM specialize in helping you to get the most out of your Microsoft Dynamics CRM solution. For more news, tips and insights, Contact us or call 855-437-7202