Is your feature request related to a problem? Please describe.
We use sfpegRecordDisplayCmp extensively in our Salesforce org and need to write automated tests (Selenium, Playwright, ...) to validate field values displayed by the component. Currently, there's no reliable way to target specific field elements in the rendered HTML:
- The
title attribute shows a tooltip on hover, which has a UX impact for end users
- Using visible label text requires XPath expressions that break with i18n (internationalization)
- Position-based selectors (nth-child, index) are fragile and break whenever the layout changes
This makes it very difficult to write stable, maintainable automated tests for pages using sfpegRecordDisplayCmp.
Describe the solution you'd like
Add support for a generic data property (key/value object) in the field configuration JSON that renders as arbitrary data-* HTML attributes at multiple levels of the component hierarchy (lightning-layout-item, c-sfpeg-field-dsp, and the inner lightning-formatted-* element).
This generic approach allows each consumer to define their own data-* attributes depending on their needs (test automation, analytics, accessibility, etc.).
Configuration example:
{
"fields": [
{
"value": "{{{RCD.IsSleeping__c}}}",
"type": "boolean",
"label": "Mise en sommeil",
"data": {
"field-name": "IsSleeping__c",
"testid": "sleeping-status"
}
},
{
"value": "{{{RCD.Name}}}",
"type": "text",
"label": "Nom du compte",
"data": {
"field-name": "Name"
}
}
]
}
Expected rendered HTML:
<lightning-layout-item data-field-name="IsSleeping__c" data-testid="sleeping-status" ...>
...
<c-sfpeg-field-dsp data-field-name="IsSleeping__c" data-testid="sleeping-status">
<lightning-icon data-field-name="IsSleeping__c" data-testid="sleeping-status">
</lightning-icon>
</c-sfpeg-field-dsp>
</lightning-layout-item>
This enables stable CSS selectors for test automation:
# Selenium - select by field name
driver.find_element(By.CSS_SELECTOR, '[data-field-name="IsSleeping__c"]')
# Selenium - select by testid
driver.find_element(By.CSS_SELECTOR, '[data-testid="sleeping-status"]')
The data property would be optional and backward compatible — existing configurations without it continue to work unchanged.
Describe alternatives you've considered
Here are some alternative solutions or features you've considered :
- Using the existing
title property: This renders as a native HTML title attribute, which causes a tooltip to appear on hover. This is not acceptable as it impacts UX — users see unexpected tooltips on every field.
- XPath selectors based on label text: For example
//span[text()='Mise en sommeil']/ancestor::lightning-layout-item. This works but is fragile — it breaks when labels change or when the org is used in multiple languages (i18n).
- Position-based CSS selectors: For example
lightning-layout-item:nth-child(3). This is extremely brittle — any layout change (adding, removing, or reordering fields) breaks all selectors.
Additional context
This need emerged from the redesign of the partner portal (Salesforce Experience Cloud). The new UX/UI introduced multiple sfpeg components across the portal to display record data (opportunities, cases, insurance policies, etc.). As we now need to cover this new portal with automated end-to-end tests, the lack of stable selectors on sfpeg-rendered fields has become a blocking issue.
Is your feature request related to a problem? Please describe.
We use
sfpegRecordDisplayCmpextensively in our Salesforce org and need to write automated tests (Selenium, Playwright, ...) to validate field values displayed by the component. Currently, there's no reliable way to target specific field elements in the rendered HTML:titleattribute shows a tooltip on hover, which has a UX impact for end usersThis makes it very difficult to write stable, maintainable automated tests for pages using
sfpegRecordDisplayCmp.Describe the solution you'd like
Add support for a generic
dataproperty (key/value object) in the field configuration JSON that renders as arbitrarydata-*HTML attributes at multiple levels of the component hierarchy (lightning-layout-item,c-sfpeg-field-dsp, and the innerlightning-formatted-*element).This generic approach allows each consumer to define their own
data-*attributes depending on their needs (test automation, analytics, accessibility, etc.).Configuration example:
{ "fields": [ { "value": "{{{RCD.IsSleeping__c}}}", "type": "boolean", "label": "Mise en sommeil", "data": { "field-name": "IsSleeping__c", "testid": "sleeping-status" } }, { "value": "{{{RCD.Name}}}", "type": "text", "label": "Nom du compte", "data": { "field-name": "Name" } } ] }Expected rendered HTML:
This enables stable CSS selectors for test automation:
The
dataproperty would be optional and backward compatible — existing configurations without it continue to work unchanged.Describe alternatives you've considered
Here are some alternative solutions or features you've considered :
titleproperty: This renders as a native HTMLtitleattribute, which causes a tooltip to appear on hover. This is not acceptable as it impacts UX — users see unexpected tooltips on every field.//span[text()='Mise en sommeil']/ancestor::lightning-layout-item. This works but is fragile — it breaks when labels change or when the org is used in multiple languages (i18n).lightning-layout-item:nth-child(3). This is extremely brittle — any layout change (adding, removing, or reordering fields) breaks all selectors.Additional context
This need emerged from the redesign of the partner portal (Salesforce Experience Cloud). The new UX/UI introduced multiple sfpeg components across the portal to display record data (opportunities, cases, insurance policies, etc.). As we now need to cover this new portal with automated end-to-end tests, the lack of stable selectors on sfpeg-rendered fields has become a blocking issue.