Hi Health Cloud / OmniStudio community,
We are replacing a legacy Health Check solution with Salesforce Health Cloud Discovery Framework Assessments.
The target model must support many forms, many assessment questions, and multiple languages.
Context
Health Cloud Assessments use Discovery Framework and OmniStudio to build assessment forms. The assessment forms are created with OmniScript / OmniStudio and surfaced through the Assessment component.
Salesforce documentation for multi-language OmniScripts describes the out-of-the-box translation approach using Custom Labels. The OmniScript custom label reference also shows that many element properties, including labels, help/error text, and select/radio/multiselect option values, rely on custom labels for translation.
In our first implemented form, the translation setup already generated approximately 250 Custom Labels. Since Salesforce Custom Labels are limited per org (5000), this does not appear scalable for additional forms, questions, response values, and languages.
What we evaluated
Salesforce has suggested Custom Metadata Types as a more scalable translation-management option.
However, in our testing, Discovery Framework assessment rendering does not resolve translated text dynamically from Custom Metadata Types at runtime (this is also documented as a limitation). In other words, we have not found a supported way to keep one assessment form and dynamically inject all question text, help text, and response values from CMDT based on selected language.
Resulting design decision
Because of this, we are currently moving toward a governed **one-form-per-language** model:
- one Discovery Framework assessment form per language
- questions authored directly in the local language
- local AssessmentQuestion / AssessmentQuestionVersion records per language
- a global parent/anchor question identity for reporting
- normalized answer identifiers for cross-language reporting
This avoids Custom Label exhaustion and keeps the runtime compatible with Discovery Framework, but it increases governance and deployment overhead.
Question to the community
Has anyone implemented large-scale multilingual Health Cloud Discovery Framework Assessments?
If yes:
1. Did you use OmniStudio multi-language Custom Labels, or did you also move to one form per language?
2. Has anyone successfully used Custom Metadata Types or another translation store at runtime inside Discovery Framework assessments?
3. How do you manage translated question text, help text, and picklist/radio/multiselect response values at scale?
4. How do you keep global reporting consistent across translated assessment forms?
5. Are there any Salesforce-supported patterns we should consider before finalizing the one-form-per-language approach?
Any experience, lessons learned, or recommended architecture patterns would be appreciated.
Hi all,
A quick update on this, as we have since found a better approach.
Salesforce now documents a Discovery Framework-specific option for this: Multi-Language Data Translation for Discovery Framework. This is enabled from Setup under Discovery Framework settings:
The broader documentation is here:
https://help.salesforce.com/s/articleView?id=ind.discovery_framework_data_translation.htm&type=5
This appears to be a relatively new and/or recently documented area, and it was not obvious from the earlier OmniStudio multilingual documentation. Which is why we were originally moving toward a one-form-per-language design.
After enabling and testing this, we validated that Discovery Framework can support multilingual assessments without the use of Custom Labels for Assessment Questions.
The key translation object is:
AssessmentQuestionVersionDataTranslation
Translations are linked to the Assessment Question Version by:
AssessmentQuestionVersionDataTranslation.ParentId = AssessmentQuestionVersion.Id
The translation child record uses Salesforce language codes, for example:
German = de
French = fr
We used API v67 during validation.
For the Assessment / Summary API context, our testing showed that c__LanguageCode must use the full language name, for example:
c__LanguageCode = German
c__LanguageCode = Japanese
I have not found it clearly described in the Summary API documentation:
