Contact

Industry Leading Blog for Manufacturers

Composite fields were added in Microsoft Dynamics CRM 2013 to capture data as a group rather than through multiple disconnected fields. For example, in previous versions of Microsoft Dynamics CRM individual components of an address would need to be captured as separate fields. In Microsoft Dynamics CRM 2013, composite fields are presented as a single field that is then broken down into the individual components that make up that field’s value.

composite fields as a single field that is then broken down into the individual components that make up that field’s value

Although composite fields do simplify the user experience and reduce form clutter, they do not have many customization options. This can become a problem if you need to support multiple languages. When localizing normal field labels, you would simply export the translation files, add a localized label for each of the languages you need to support, and re-import the translations. With the composite address fields, this is not the case.

In the exported translation file, you may notice translations for fields that appear to be for the composite address field’s individual components.

composite address field’s individual components

Updating these values will not update the labels shown in the composite address field’s pop-out form. Behind the scenes the values the user enters into a composite field’s components are copied to their own fields; the localized labels you are seeing in the translation file are the localized labels displayed on the form for those individual fields. For example, no matter what changes you make in the translations file, these values will always be shown for users viewing the composite field in Spanish:

for users viewing the composite field in Spanish

If you need to show different labels for these fields, you will have to use the fields associated with the individual components of the composite address field, such as “Address 1: Street 1” and “Address 1: City,” rather than the composite address field “Address 1.”

The best way to work around this is to only show the individual component fields for languages you need custom labels for. This can be done by making a separate section for each way of presenting the data to the user and using JavaScript to show and hide the correct sections based on the user’s language.

.JavaScript to show and hide the correct sections based on the user’s language

The user’s language code can be obtained using the following front-end API call:Obtaining user's language code using front-end API

With the user’s LCID, you can show and hide each section with the front-end API:show and hide each section with the front-end API

With this logic running on form load, the composite address field will be shown when the user’s language is set to English which will use the un-editable translations packaged with CRM and the individual address fields will be shown when the user’s language is set to Spanish which will use the editable localized labels from the translations file.

Although this solution does not directly fix the problem that the localized labels for the composite address fields are not customizable, it does allow you to provide your customers with the translations they need while also allowing as many users as possible to benefit from composite fields.


Stay up to date on the leading industry solutions by subscribing to our blog digest.
What can we help you with?

CONTACT US

(585) 506-4600