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

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.

Description

Customers using Microsoft Dynamics 365 and Microsoft Outlook often require seamless synchronization of Contacts between the two platforms while maintaining Dynamics 365 as the system of record (master contact database).

Currently, Server‑Side Synchronization between Outlook and Dynamics 365 relies on category‑based tracking and does not support:

• Automatic matching of Outlook Contacts with existing Dynamics 365 Contacts
• Ongoing bidirectional synchronization using Dynamics 365 as the authoritative source
• Native prevention of duplicate Contact records across Outlook and Dynamics
• Centralized identity matching based on Dynamics Contact data

As confirmed by Microsoft Support, synchronization logic today does not support automatic matching of Contact records between Outlook and Dynamics 365 during synchronization, and implementing this capability would require platform‑level enhancement.

This limitation creates challenges for organizations attempting to:

• Maintain a single unified Contact database in Dynamics 365 for Outlook contact loist.
• Ensure Outlook users interact with accurate and up‑to‑date Contact information from Dynamic
• Avoid manual tracking or duplicate Contact creation for Outlook

Customers want to leverage Dynamics 365 as the master Contact repository while allowing Outlook to reflect synchronized Contact data automatically, without relying on manual tracking or categorization.

Business Impact

The lack of automatic Contact matching and synchronization between Outlook and Dynamics 365 introduces several operational challenges:

• Contact duplication between Outlook and Dynamics environments
• Increased administrative overhead to manually track or sync Contacts
• Inconsistent customer data across sales, marketing, and service teams
• Reduced user adoption of Dynamics 365 when Outlook becomes the preferred Contact store
• Risk of outdated or conflicting Contact information across platforms
• Some users currently have more than 1000 contacts were mismatch.

Organizations attempting to centralize customer data within Dataverse are unable to ensure Outlook users operate from the same validated Contact dataset.

This impacts:

• Data governance initiatives
• Customer engagement accuracy
• Reporting reliability
• Sales productivity
• Enterprise adoption of Dynamics 365 as a single source of truth

For many customers transitioning from Outlook‑centric workflows, this represents a blocker to fully adopting Dynamics 365 Contact management capabilities.

Proposed Approach / Enhancement Request

Introduce a native synchronization option within Server‑Side Synchronization to allow:

1. Dynamics‑First Contact Authority Mode

Enable administrators to configure Dynamics 365 Contacts as the authoritative source for Contact data synchronized to Outlook.

2. Automatic Matching Logic

Provide built‑in matching rules to associate Outlook Contacts with existing Dynamics 365 Contacts using configurable attributes such as:

• Email Address
• Full Name
• Company Name
• External ID (optional custom field)

3. Duplicate Prevention

Allow synchronization to:

• Match to existing Dynamics Contact when criteria are met
• Prevent creation of duplicate Contact records in either system
• Update Outlook Contact records based on matched Dynamics Contact data

4. Ongoing Synchronization

Ensure matched Contacts remain synchronized for updates made in Dynamics 365, supporting:

• Contact detail updates
• Email or phone number changes
• Company or role updates

Dynamics CRM on-premises version 9.1 and SharePoint online integration is no longer functioning as expected.

Microsoft currently provides the following documentation for configuring the integration:

On-Premises CRM to SharePoint Online setup:

https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/admin/on-prem-server-based-sharepoint-online?view=op-9-1

Claims mapping configuration:

https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/integration-dev/define-custom-claim-mapping-sharepoint-server-based-integration?view=op-9-1

Based on this setup, the integration works; however, when a user uploads a file from CRM to SharePoint, the file is recorded as uploaded by the SharePoint App rather than the actual user. This is the current product limitation. 

Ideally, the uploaded document should retain the identity of the user performing the action, similar to how the integration behaves in Power Apps / Dataverse environments.

It would be helpful if this behavior could be addressed in a future cumulative update, along with clearer guidance to ensure the integration works consistently and records the correct user identity.

If you are using the sorting by Sequence Name option or any option whereby the activities in the Sales Accelerator are sorted under a header and can be collapsed or expanded, if you were to collapse your headers to limit the expansiveness of options showing, then select a single record from the expanded header, then automatically the list re-opens every collapsed header and you're brought back to the very top of the list again.

This frustrates my Producers greatly and is becoming a nuisance in their daily effort in the CRM. Not sure if this is a "BUG" or a feature request so I'm starting here for our organization. With over 2,500 licensed sales teammates, hoping this gets picked up quickly and resolved.

I would like to raise a requirement regarding access control in Microsoft Dynamics 365 Sales related to manager hierarchy and security role configuration.

Currently, we have the Manager Hierarchy enabled in the system. However, users are experiencing issues when attempting to assign or delete records that belong to their reportees. The affected users have security roles configured with User-level access depth only for the relevant entities.

Due to this configuration, managers are unable to perform Assign and Delete actions on records owned by their direct reportees, even though the managerial relationship is defined in the hierarchy. This is causing operational challenges for teams that rely on managers to manage or reassign records within their reporting structure.

We would like to explore the following as part of this requirement:

1. this idea is to enable assign and delete records owned by their reportees while maintaining the current User-level access depth in the security role.
2. Identify possible approaches (such as hierarchy security configuration, privilege adjustments, or alternative design) that allow managers to manage reportee records without granting broader Business Unit-level access.
3. Ensure the solution aligns with existing governance and data security standards.

Regards,

We have several tenants that we have within our group and all want to use 1 main D365 tenant and have subsidiary tenants to be using the cross email that works but we also want them to use the Outlook Sales App which we are told as yet does not support cross tenant can this be something looked at urgently.

When users copying content from CRM RTE control and pasting to other application only text is copied and images in content are not copied.

After raising ticket MS mentioned this scenario is internally and confirmed with the engineering and product group teams before sharing this update. Based on the investigation, this behavior is by design in the Rich Text Editor (RTE v2).



Images added in the RTE are stored as Dataverse file records in the msdyn_richtextfile entity and are referenced dynamically. When the content is copied from the RTE to external applications such as Word, OneNote, or Microsoft Teams, only the text content is transferred, and images are not included.

Workaround for this issue copy pasting each image manually. But business is not accepted this workaround and asked to share efficient workaround.

As per current functionality copy pasting images from other application to CRM is working but vice versa not working.

As business/End users using this copy paste functionality we request that copy pasting images from other application to RTE should also work.

When users copying content from CRM RTE control and pasting to other application only text is copied and images are not copied.

After raising ticket MS mentioned this scenario is internally and confirmed with the engineering and product group teams before sharing this update. Based on the investigation, this behavior is by design in the Rich Text Editor (RTE v2).



Images added in the RTE are stored as Dataverse file records in the msdyn_richtextfile entity and are referenced dynamically. When the content is copied from the RTE to external applications such as Word, OneNote, or Microsoft Teams, only the text content is transferred, and images are not included.

Workaround for this issue copy pasting each image manually. But business is not accepted this workaround and asked to share efficient workaround.

As per current functionality copy pasting images from other application to CRM is working but vice versa not working.

We request that copy pasting images from other application to RTE should also work.

Even if the security roles for Basic User and Environment Maker are revoked from the user in the default environment, they are quickly restored.

I understand this is a limitation of the default environment's design, but it poses a significant challenge in controlling and managing users.

This is because users can inadvertently create apps within the environment without intention.

I hope that automatic role assignment in the default environment can be disabled, allowing for more flexible management options.