It is easy to assume that simply by virtue of selecting a Microsoft product as the core to your CRM solution you’ll achieve inherent quality of product.  However, that is not always the case!  Having managed, developed, and deployed several solutions for MS CRM since version 1.0 Beta, I’ve noticed that the folks in the field who are configuring solutions don’t always keep a keen eye on quality measures.  Quality measures with MSCRM begin and weigh very heavily on Design Quality.  If the design is incomplete or inconsistent, all other aspects of the project and final solution will suffer.

For example, since MSCRM allows designers to create custom entities and attributes using standardized UI (User Interface) controls and datatypes, it might be easy to create a custom transaction record to hold “period” and “year” fields on the form.  At first glance, this seems like there’s some good insight into future scale of the design by matching field design to common financial systems – possibly to allow for a straight forward integration.  While the concept is good, however, the execution is where the quality control must come into play. 

A good designer will realize that if you ask a system user to enter a month value (“period”) and year value (“year”) once in the solution, they will expect all other instances of that type of entry to look and behave the same.  Therefore, if you configure the “period” field to be an integer with a range of 1-12, all “month” and “period” fields throughout the entire system should consistently be an integer value allowing the same input range of 1-12.  Additionally, if you use alternative field labels for a custom field like this, it should present itself consistently not just to the other instances of the field type throughout the system, but also must stay consistent to all field labels used in the system.  If you use square brackets to clarify usage of a label in one instance, you should use square brackets throughout the entire solution.

Take a look at the following real world example I found recently.  On one custom entity, the fields are presented without any custom label attributes and use string values as shown below.  While it is a bit unorthodox, it can work in some situations depending on the planned use and training content surrounding the entity.

Shockingly, inside the same solution (on a different entity), these same two fields (“period” & “year”) reappear and take on completely different functionality.  Now, the users has to comply to an integer input and is prompted with a custom label.  Additionally the “year” field is not using a common web resource that re-masks the integer control to strip out the thousandths comma separator.

In order to bring consistency to these solutions, the fields must be made to appear and function identically.  Depending on the level of code customizations and integration points that tie to these fields, this could represent several thousands of dollars in rework effort!

Here at Webfortis, we use a standardized and well documented methodology for our CRM Design to help maintain quality control in our CRM projects and save our customers the added cost of rework as shown here.  If you’re considering a CRM project and have not asked yourself the question around Quality Control, do yourself a favor and make sure that whomever is doing your solution design can elaborate on and illustrate to you how their design methodology will minimize your costs of rework effort!