Dynamics Community Forum Thread Details

Hello Lucky Dog,

You've hit a common challenge when implementing Dynamics 365 Field Service (and other Power Platform apps) in multilingual environments for setup tables like Priority, Incident Type, and Booking Status. Unfortunately, standard lookup fields in Dynamics 365 do not inherently support multilingual values out-of-the-box.

Your observation is correct: setting up all possible language variations as separate options within a single lookup field leads to significant issues with data consistency, reporting, and user experience.

Here are the recommended approaches and best practices for handling multiple languages for setup tables in Dynamics 365 Field Service:

1. Using Localized Labels for Option Sets (Recommended for Option Sets):

For fields that use Option Sets (like Priority), Dynamics 365 has built-in multilingual support. You can define localized labels for each option value.

How to Implement:
1. Go to Settings > Customizations > Customize the System.
2. Expand Entities, select the entity containing the Option Set field (e.g., Work Order for Priority).
3. Expand Fields and open the Option Set field (e.g., msdyn_priority).
4. In the Option Set definition, click the "Add Translation" button.
5. Select the languages you need to support.
6. For each language, enter the translated label for each option value.
7. Save and Publish All Customizations.

How it Works: When a user whose language preference in Dynamics 365 matches one of the added translations views the Option Set field, they will see the localized label. The underlying numerical value of the option remains consistent across all languages, which is crucial for data integrity and logic.

Limitation: This method only applies to fields with the Data Type of Option Set. Lookup fields do not have this built-in translation capability.

2. Creating Separate Localized Entities and Relationships (Best Approach for Lookups):

For lookup fields like Booking Status and Incident Type (which link to tables), the most robust and scalable approach is to create separate entities to hold the localized values and establish relationships.

Example for Booking Status:
1. Create a new custom entity: Booking Status (Localized)
2. Add the following fields:
  - Booking Status (Language) (Lookup to the Language entity - OOB)
  - Booking Status Value (Lookup to the main Booking Status entity - OOB or custom if you created it)
  - Localized Label (Single Line of Text)
3. Establish a One-to-Many relationship: From the main Booking Status entity to the Booking Status (Localized) entity (e.g., msdyn_bookingstatus_localized).

Data Entry: For each Booking Status record in your main Booking Status entity, you would create corresponding records in the Booking Status (Localized) entity for each language you support, linking them back to the main record and providing the translated Localized Label.

Displaying Localized Values:
- Views and Grids: You would need to customize views and grids to display the Localized Label from the related Booking Status (Localized) entity based on the user's preferred language. This often involves using FetchXML with linked entities.
- Forms: You might need to add subgrids or use JavaScript to display the localized values on forms based on the user's language. A common pattern is to have a hidden field for the base lookup and display the localized value in a separate text field that updates based on the user's language.

Business Rules and Workflows: When referencing the Booking Status, you would typically work with the underlying Booking Status Value (the lookup to the main table). For displaying language-specific text in notifications or other automated processes, you would need to query the Booking Status (Localized) entity based on the target user's language.

Example for Incident Type: You would follow a similar pattern, creating Incident Type (Localized) with a link to the main Incident Type entity and a Localized Label.

3. Using a Configuration Entity with JSON (More Complex):

A more complex approach involves creating a custom configuration entity where you store the multilingual values for your setup tables in a structured format (e.g., JSON).

Configuration Entity: Localized Text Configuration
- Fields: Entity Name, Record ID, Language, Localized Value

Data Entry: You would store records in this entity for each record in your setup tables (Priority, Booking Status, Incident Type), specifying the language and the translated value.

Displaying Localized Values: You would need to use JavaScript on forms and FetchXML in views to retrieve the appropriate localized value based on the user's language. This approach requires significant development effort to implement and maintain.

Why the Localized Entities Approach is Generally Preferred for Lookups:

Data Integrity: Maintains clear relationships between the base record and its translations.

Querying and Filtering: Allows for easier querying and filtering of localized data.

Extensibility: More flexible for adding new languages in the future.

Maintainability: While initially more setup, it's generally easier to maintain in the long run compared to complex JSON parsing in JavaScript.

Addressing Your Business Rule Requirement:

For your business rule scenario ("if it contains data, then continue"), you would typically apply the rule to the underlying lookup field (e.g., the Booking Status lookup). The presence of a value in the lookup field indicates that a Booking Status has been selected, regardless of the displayed language. The localized text field is primarily for user display.

Implementation Considerations:

Language Entity: Dynamics 365 comes with a built-in Language entity (languagelocale) that you can leverage for storing and referencing supported languages.

User Language Preference: The User Settings entity stores each user's preferred language. You can retrieve this information in code or FetchXML to display the correct translations.

Development Effort: Implementing the localized entities approach requires more initial setup and customization (creating entities, relationships, views, forms).

Performance: Be mindful of the number of related localized records when designing your views and forms to avoid performance issues.

In summary, while standard lookup fields don't support multilingual values directly, the best way to handle this for setup tables like Booking Status and Incident Type is to create separate localized entities with relationships to the base tables. For Option Sets (like Priority), utilize the built-in localized labels feature. This ensures a consistent and user-friendly experience across your multi-country, multi-language Field Service implementation.

If my answer was helpful, please click Like, and if it solved your problem, please mark it as verified to help other community members find more. If you have further questions, please feel free to contact me.

My response was crafted with AI assistance and tailored to provide detailed and actionable guidance for your Microsoft Dynamics 365 query.

Regards,

Daivat Vartak

Community site session details

How do I handle multiple languages for Set-up Tables

Helpful resources

News and Announcements

Quick Links

Announcing the Engage with the Community forum!

🌸 Community Spring Festival 2025 Challenge Winners! 🌸

Adis Hodzic – Community Spotlight

Leaderboard > Service | Customer Service, Contact Center, Field Service, Guides

Featured topics

Product updates