Tip #1176: Handling the Primary Field

Sometimes inspiration comes from unlikely sources. In this case it was not having written a tip for a few weeks and knowing George would meter out Spießrutenlaufen if I did not post soon. Thoughts of such things give one time to reflect and so I am going back to basics and addressing one of the great mysteries of Dynamics: the Primary Field.

Surprisingly, the TOTD crew have never tackled this one, other than as a step in Tip 646 but we are all familiar with its ways. If you are not familiar, the Primary Field is a text field created automatically whenever you create a new entity. Why it is necessary to create a default text field whenever we create a new entity? An excellent question and one that will not be answered as part of this Tip. No one knows. I can confirm that this behaviour has been there since the beginning, back when the product was known as Microsoft CRM. However, like decaffeinated coffee, the reason for its existence is a mystery.

By default the name of the Primary Field is ‘<prefix>_name’ with a display name of ‘Name’. If this name is not appropriate, as per Tip 646, change it, ideally before saving the entity, otherwise, like all saved fields, you are stuck with the system name. You can always edit the display name by finding the field in the entity’s field list and modifying it like any other field. However, you cannot modify it through the Primary Field tab of the entity’s Information screen. That would be too easy.

Where possible, try to work the Primary Field into your list of fields for the entity but make sure it is a field which will be populated each time a new record is created and is generally unique for each record. If there is no text field which fits the bill you are better off making it non-compulsory and hiding it/removing it from the form. To make it non-compulsory, edit it through the fields list. The next question is whether you should auto-populate this field if you have removed it from the form and made it optional.

In my opinion, the answer is “usually yes”. The problem we have is if another record has a lookup to this entity, the value displayed in the lookup field is the Primary Field. We cannot change this so if we leave it blank, even if our lookup is pointing to a valid record, if the Primary Field is blank we will not readily know it. I am pretty old school in populating it and just use a workflow but there are so many ways to populate a field with a default value these days, take your pick. If there is no obvious role for the Primary Field for the entity, create a short description field for the record by concatenating key field values. Your lookups will thank you for it.

 

2 thoughts on “Tip #1176: Handling the Primary Field

  1. M vd Peppel says:

    To add at least one possible (and I think probably a very important) reason to why the primary field is there: To have one specific field that can reduce API call overhead when you only need to show related records.

    For instance, when retrieving a record containing a lookup (or even better, when using a subgrid on a form), you don’t have to call the API for each related record to show an functionally identifying piece of information for the user (CRM user that is) to work with. We already have an entityId & entityName to retrieve the record, but that’s just the technical part. The primary field is used as a display name and will be joined into the result when using FormattedValues:

    SDK: https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/gg326918(v%3Dcrm.8)
    (OData) Web API: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/query-data-web-api#include-formatted-values

    This reduces the amount of calls needed significantly 🙂

    Another small note, use the EntityDefinitions (https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/create-update-entity-definitions-using-web-api) to query what (logical) field(name) is used as a Primary Field: PrimaryNameAttribute.

    P.S. Another reason to “always populate the primary field” (aside from making the field clickable when using a lookup): When opening the record in a form, if the field is empty, the form will always show something like “New record: ” even if the record already was submitted to CRM.

  2. […] Figuring out Primary Keys, Primary Fields and option set values in Dynamics 365 Project Service Automation sometimes takes a bit of time and effort. While there are some sources out these such as the Web API Reference and the Entity Reference, it makes life easier to have all relevant PSA entities and option sets easily available from a single source. This post will list all Primary Key + Primary Field pairs and option sets for PSA, excluding Business Process Flows and deprecated entities. I’ve used the Web API Reference as a source of PSA entities. If you’re not familiar with what Primary Keys and Primary Fields are, see the following two posts:Understanding CRM Metadata: PrimaryKey and PrimaryFieldTip #1176: Handling the Primary Field […]

Leave a Reply

Your email address will not be published. Required fields are marked *