Editor's Note: The following is a guest post by Dynamics CRM MVP Jerry Weinstock as part of the MVP Award Program Blog's "MVPs for Office 365" series. Jerry is the Business Development Manager at CRM Innovation. Jerry has been working with CRM since the 1.2 release in 2003. CRM Innovation builds Email, Marketing and Event Management solutions for Microsoft Dynamics CRM. Twitter: @crminnovation
In Dynamics CRM there are in a few core entities where the Primary Attribute field is a nvarchar Text field that the user must complete. These fields are system required and you are unable to edit them to change their type. Additionally, since they are required fields the record cannot be saved until it contains some data. The fields do not lend themselves to a consistent data entry format due to the nature of them being free form text fields.
For example, in the grid view shown below for the Opportunity entity the first column represents the Topic field in the form, which is the primary field. While this allows the CRM user great flexibility in data entry, it all but eliminates any possibility of easy sorting or filtering.
While Free Form Text Fields provide significant advantages they fall short in being able to serve up the information to the user in an organized presentation.
Text Field Advantages –
- adapts to any situation – users can enter anything they want that is relevant to the record
- very descriptive relevant data – they can be verbose
Text Field Disadvantages –
- Sorting – no organized format enforced so it’s nearly impossible to sort
- Filtering – common terms or spelling are not enforced
- Scanning – data can’t be presented in subgroups which makes it hard on the eyes
- Irrelevant – users can enter anything they want which can often include unnecessary info
If we look at a few of the Core Records in the CRM system, some lend themselves to free form text entry and others have primary fields that could benefit by consistent data formatting.
The ones that lend themselves to building in data consistency are Case and Opportunity. The solution is to insert some Jscript in the OnLoad and OnChange events for the entity so that we can concatenate data from other fields into the primary key field.
For example in the Opportunity entity if we concatenate ID Status (a custom field) and Potential Customer into the Topic field you get this view in the record.
After implementing the concatenation you then end up with a grid view that is easily sortable, scanable and if necessary filterable.
Implementing the same type of concatenation in the Case entity builds a “Customer – Subject” consistency into the Case Description Field. In this example, the concatenated field is set to read only so that user cannot edit the description.
Then you get consistent view of open cases in the grid view as follows:
Moving away from the core CRM records this technique can be applied to the Recurring Appointment activity by concatenating the Engagement Type (custom field) and the Required Participant.
The Jscript code to write for the concatenation is not that extensive, a snippet is shown below. Note the line of code in Red. That line is necessary in the Case example above where the concatenated field is set to read only. Without the ForceSubmit, the concatenation result will only be displayed but not saved to the field when the record is saved.
So in review there are a lot of advantages to managing the data that goes into some of the system required fields in the CRM system to pre-fill them in via concatenation to provide uniform, consistent, and highly scannable records. It will make records that are outliers jump off the screen and likely improve user efficiencies in entering data.
I have shown one way to do this using Jscript which gives you immediate results, the Workflow Process in CRM is another way to accomplish it, albeit with a slight delay as Workflow is processed in the background.