Editor's Note: The following MVP Monday post is by Dynamics CRM MVP Jerry Weinstock.
When you create a custom entity (think table for all you DB gurus) in Dynamics CRM if you do not think before you click you will end up with a Primary Field that is Required.
What you normally get is the configuration shown in this screen shot of a default setup.
This may not fit some environments where you:
Unfortunately, there are no other field types available – you are limited to Text, you can change the Display Name and the Requirement Level. However, once you save the record the settings cannot be edited.
The following is a how-to using a client example on moving from the default configuration to a customized configuration. The client needed a CRM entity to track what types of technology an Account was using. They wanted to enforce the name of the technology the CRM user would enter into the Primary Field, which is utilized throughout CRM for Lookups, etc.
We created a new entity called Technology, renamed the Primary Field to ‘Technology’ and made the Requirement Level ‘No Constraint’.
We then created a new field called Technology Type as an Option Set and entered the option values.
Then we created a Workflow Rule that would fill in the Primary Field (Technology) with the value from the Option Set. That way the client could easily enforce consistency in the Primary Field. The workflow rule was set to start when the record was initially created or if the option set value changed.
After the Workflow Rule was created, published and tested we went back to the Technology form and made the Primary Field Read Only.
The nice thing about using Workflow to support this work around is that it is a technique that programmers or non-programmers can use. Yes, you could use Jscript to populate the value as soon as the Option Set Value is selected or changed but Workflow removes one less piece of code to manage and document. In addition, it further demonstrates the power of Dynamics CRM Workflow, which some other competitors do not have in their feature set.
Jerry Weinstock 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
The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager for Dynamics, Excel, Office 365, Platforms and SharePoint in the United States. She has been working with MVPs since her early days as Microsoft Exchange Support Engineer when MVPs would answer all the questions in the old newsgroups before she could get to them.
Very helpul. We will be using this in our CRM environment.
An excellent workaround. One small correction. You can change the requirement level and display name of the field, post-save, by going to it in the field list of the entity ;)
Also in Dynamics CRM 2015 you may apply Jerry's workaround. The annoying thing about an entity record with an null value or empty string value for its primary field, when appearing as an existing record on a CRM form, is that the caption will be "New: Technology" --> suggesting that you're creating a new record, while your just viewing or editing an existing record.
In an environment with many custom entities, for which many thousands of records will be saved, I prefer not to start a synchronous plugin or workflow for each them, only for filling a primary field. But I do want to get rid of the misleading "New: Technology" caption.