Considerations When Adding A Business Required Field To Contacts In Dynamics CRM 2011

Colin Maitland, 04 June 2012

Adding a new custom Business Required field called Contact Type to the Contact entity and related Contact form in Microsoft Dynamics CRM seems like a simple change that can be made with minimum impact.  However, there are several issues to be considered and addressed when adding a Business Required field to Microsoft Dynamics CRM.  Over the next couple of blogs I will be discussing these issues.

Business Required fields on forms force the user to provide a value for the field before they can save the record. This applies when creating new and updating existing records. The following screenshot shows the addition of new Business Required field called Contact Type to the Contact form.

 Considerations When Adding A Business Required Field To Contacts In Dynamics CRM 2011

The first impact of our change is that users will now be required to select a Contact Type for each new Contact they create. This is not a problem because this is the desired outcome.  The task can be made easier for users by defining a default Contact Type. Users are then required to select the Contact Type for new Contacts only when the default Contact Type is not suitable for the new Contact.

The second impact of our change is that users will now be required to select a Contact Type for each existing Contact they edit, and for which the Contact Type has not yet been selected.

This second impact introduces some potential issues. Users editing existing Contacts for reasons other than updating the Contact Type, such as adding/updating a phone number or e-mail address for instance, will be prevented from saving their changes until they have also selected the Contact Type. In the screenshot below the user has added an e-mail address but is unable to save the change until they also select a Contact Type.

 
Considerations When Adding A Business Required Field To Contacts In Dynamics CRM 2011

Users who do not know what the Contact Type should be may choose to follow one of several courses of action.

• They might guess or choose the first or another Contact Type just so that they can then save their other changes! In this case the selected Contact Type may or may not be correct!

• They may choose to abandon their changes until such time as they can obtain clarification on what the Contact Type should be set to. They may even abandon saving their changes all together! In this case there is a delay and/or additional effort required before the Contact is updated or the Contact might not be updated at all!

In both cases important business information is either missing or incorrect; or its addition/update is delayed.

There are several best practice methods for mitigating this.

• User documentation and training can be provided to ensure that all users know how to determine and set the Contact Type for all new and existing Contact records.

• The Contact Type for all existing Contact records could be set at the same time as the new Contact Type field is added. Users would not then need to set the Contact Type for existing Contact records. This can be done using the standard Bulk Update or the Export to Excel and Import Data functionality in Microsoft Dynamics CRM. The person responsible for setting the Contact Type for all existing Contact records may have the business knowledge but not the technical skill to use this functionality. However they can be easily trained or assisted by a system administrator /super user who does have the technical skill but perhaps not the business knowledge for completing this task.

Ensuring that the Contact Type for all existing Contacts is set at the same time as the new Business Required Contact field is added has the following benefits.

• Users are saved the task of setting the Contact Type for existing Contacts themselves.

• The Contact Type field has been defined as a Business Required field indicating that this field has special meaning and purpose to the business. If the Contact Type is not set for existing Contacts then they cannot be filtered and/or classified/grouped by Contact Type when included/excluded and analysed in dashboards, charts, lists and reports.

• Other functionality such as Dialogs and/or Workflows, to be added or updated in Microsoft Dynamics CRM, may require the Contact Type in order to execute conditional business logic.

There are other impacts on areas of related functionality in Microsoft Dynamics CRM to be considered when adding a new custom Business Required field to the Contact entity. Next week I will be discussing these.