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.

At this time, there is no available way to implement this functionality. However, there have been previous community and Ideas submissions, indicating that this is a highly requested feature among many customers.

Since this directly impacts the end-user experience, enabling this capability would greatly improve usability for users.

We have started using the Sales Qualification Agent. So far it looks promising.

One draback is that we can only set up one agent per environment.

Our sales department works with many different segments in many different industries.

We therefore see the need to set up several agents.

As an example, you can only add 3 key competitors in the agent config. In our case these key competitors are not the same across different industries.

Another example is products. We offer different kinds of products across different industries.

We really hope that it will be possible to add several agents per environment in the not so distant future.

We would like to request the provision of means to fully collect or visualize all information on Dataverse Web API HTTP GET requests—including those executed directly via Postman or browsers, and including calls.

When Dataverse read auditing is enabled, Purview allows us to confirm that specific users or applications have accessed data within a table. However, the following detailed information is not logged:

Details of API requests

Paging behavior

Number of records returned

It has been confirmed that this behavior is by product design; however, the fact that such detailed information is not logged poses a potential obstacle for security and compliance teams that require complete visibility into all API calls.

Although the summarization for the account table has been enabled via [App Settings] - [Copilot] - [Opportunity] in the Dynamics 365 Sales app, there are cases where the summarization of specified items works and cases where it does not.

Since this feature relies on AI to generate summaries, users can only select items manually. Because some selected items are not being summarized, we request an update to ensure that summarization is always performed for the items selected by users.

This will enable users to confidently review the summarized information and reduce the effort required to check multiple pieces of data.

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.

Hello,

When using Sales Copilot in Outlook, if the meeting organizer is from an external domain, appointment tracking does not work. There is no error message, and this issue affects both existing and new appointments. This behavior is consistent with the documented synchronization scenarios: when the organizer is not a Dynamics 365 (CRM) user, immediate or fallback synchronization for tracked appointments may not occur. The system relies on the organizer being a CRM user with an eligible mailbox for tracking to function properly. If the organizer is external, the appointment will not sync to Dynamics 365, which explains why tracking fails in these cases, even though it works with the previous Outlook add-in and in other scenarios

This is a REGRESSION from the app for outlook and should be improved.

Thank you

Pierre-Olivier

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

In the visual hierarchy for a specific form, when "Expand all levels" is selected, the levels of the entity do not allow for a custom label. Only a number is showed, and one needs to expand it to understand what that number is talking about. This causes the confusing for users, and thus, it would be great if we can change the label right in that specific form.

Problem Statement

When configuring multi-level hierarchies (e.g., Account-to-Account via custom connection tables), the platform currently builds a single QueryExpression that enumerates all possible related tables. In environments with many custom tables referencing Account, this results in more than 100 filter conditions, causing the configuration to fail due to the hard QueryExpression limit.

This behavior effectively blocks use of the hierarchy feature for common enterprise scenarios, even though customers accept the 100-entity limit itself.

Current Limitation

• The 100-condition limit is enforced for performance reasons (by design).
• The hierarchy configuration issues stem from how the query is constructed, not from the customer’s intent to exceed supported limits.
• 
  

Customer Expectation / Feedback

Customers are not asking to remove or increase the 100 limit

They expect the platform to:

• Load the first batch (e.g., 100 entities), and
• Use paging or incremental loading instead of issuing a single, unpaged query.

This would allow the feature to remain performant while still being usable in real-world schemas.

Proposed Enhancement

• Introduce paging or incremental loading when resolving hierarchy-related queries.
• Avoid generating a single QueryExpression with >100 filter conditions.
• Optionally cap each page to existing limits while allowing traversal across pages.

Business Impact

• Enables hierarchy features to function in complex but valid enterprise environments.
• Reduces support escalations where behavior is technically “by design” but functionally blocking.
• Improves customer perception of scalability and robustness without changing core limits