Joe Jose

More details can be checked in Support Ticket: 2501300040008869

Issue Statement:

====================

Users have enabled a new session feature that reloads screens that were open when the browser closes. However, there is an issue with how the session feature handles newly created records.

Steps to Reproduce:

1. Open a contact record.
2. Create a new interaction (custom entity) and save the record.
3. Create a new case record and save the record.
4. Work on the case (make updates).
5. Refresh the browser (using Edge).

Observed Behavior: When the session reopens, it reloads the contact record and creates tabs for the interaction and case. Instead of reopening the case and interaction that were just created and saved, it opens them in a new state. As a result, the user sees two blank records, giving the impression that their work has been lost.

Expected Behavior: If the same steps are followed but existing Interaction and Case records are opened and then refreshed, the correct records are displayed after the refresh.

=================================================================

Steps that followed in Vanilla Environment:

=================================================================

 1. Opened an existing case record and created a new email. Added details in the email description and saved the email.

2. After refreshing, I noticed that a case tab opened along with the email record, but the content I saved was missing. It prompted me to create a new email.

3. From the timeline, I was able to open the email record and see the details I had saved in the email description.

Expected result: After browser refresh, we should be able to see the existing case tab and email record with the details that are saved

When an external call is in progress, the first agent, while transferring the DTMF to the consultee or the second agent, is not hearing the dialpad tone. We have identified this as a known limitation. We are requesting to add this feature in future deployments, as customers are looking for this functionality.

Title:

Enhancement Request: Identify Related Entity Causing Duplicate Key Conflict During Lead Merge

Product

Dynamics 365 Sales / Dataverse

Scenario/Problem Statement:

When merging Lead records in Dynamics 365 Sales, users may encounter the error:

“Duplicate record. A record with these values already exists.”

This error occurs during the merge operation when Dataverse attempts to reassign related (child) records from the subordinate lead to the master lead, and one or more related records violate a unique constraint / alternate key.

Currently, the platform does not provide any indication of:

• Which related entity
• Which relationship
• Or which specific record

is causing the duplicate key conflict during the merge process.

As a result, users must manually disassociate related records one by one to identify the conflicting relationship, which is time‑consuming and error‑prone—especially in environments with many custom entities and relationships.

Current Behavior

• Lead merge fails with a generic duplicate record error.
• No details are provided about:
• The related entity
• The relationship name
• The specific record or alternate key involved
• Users must manually inspect and disassociate related records to proceed.
• Once conflicting related records are disassociated, the merge completes successfully.
• This behavior is currently by design / expected.

Expected Behavior:

Provide actionable diagnostics when a merge fails due to duplicate key conflicts by:

• Identifying the related entity and relationship causing the conflict
• Optionally surfacing:
• The alternate key / unique constraint involved
• The record ID(s) causing the conflict
• Returning a clear and descriptive error message, for example:

“Merge failed due to duplicate key conflict on related entity via relationship .”

This would allow users and administrators to immediately address the issue without manual trial‑and‑error.

Business Impact

• Significant time spent troubleshooting merge failures
• High operational overhead in environments with complex data models
• Reduced productivity for sales and data management teams
• Increased support cases for an otherwise predictable platform behavior

Value/Benefit

• Improves user experience and transparency
• Reduces support and operational effort
• Helps administrators proactively resolve data integrity issues
• Enables safer and faster data consolidation during lead management

ASK:

Requesting the Product Group to consider enhancing the Lead Merge operation to surface detailed information about the exact relationship or entity causing duplicate key conflicts during merge.

Product

• Dynamics 365
• Power BI (Dynamics 365 dashboards / visualizations)
• Multilingual / Localization

Idea Type:

Product defect (Localization & data rendering issue)

Problem Description:

When a Dynamics 365 user’s UI language is set to German (de-DE), a specific field (80/20) -custom field renders as blank (“leer”) in an embedded Power BI dashboard, despite the field containing valid data in Dataverse.

This behavior is isolated to the 80/20 field only. Other fields within the same Power BI visual and dataset render correctly under the same language settings.

The issue does not reproduce when the user language is set to English, indicating a localization-specific rendering or data transformation issue.

Expected Result:

The 80/20 field should consistently render its actual value in Power BI, independent of the user’s language or locale settings, and remain aligned with the value stored in Dataverse.

Actual Result:

• Under German (de-DE) locale:
• The 80/20 field displays “leer” (blank)
• Under English (en-US) locale:
• The same field displays correctly
• No other columns are affected

Repro Steps:

1. Enable German (de-DE) as the user language in Dynamics 365.
2. Open the embedded Power BI dashboard.
3. Navigate to the visual containing the 80/20 field.
4. Observe the field value rendered as blank (“leer”).
5. Verify that the corresponding Dataverse field contains a valid value.
6. Switch the user language to English and refresh the dashboard.
7. Observe that the field renders correctly.

 Scope and Observation

• Reproducible and consistent
• Field‑specific (80/20 only)
• Language‑dependent (German locale)
• Not a data integrity issue (value exists in Dataverse)
• Suggests a localization / formatting / metadata translation defect in the Power BI + Dynamics 365 integration layer

Impact

• Results in data loss at presentation layer for localized users
• Causes inconsistent reporting across languages
• Affects customers using non‑English deployments with Power BI dashboards embedded in Dynamics 365