Dynamics 365 Sales

In Dynamics 365's standard charting functionality, the order of the horizontal axis sometimes does not match the order of the data (the order on the grid or a meaningful order in business context).

Currently, this chart is not designed to match the column order, and the standard functionality does not provide a way to arbitrarily control the order.

However, if the order of important metrics, such as sales data, changes unintentionally, there is a concern that users may misinterpret data trends, potentially impacting decision-making.

Therefore, we would like you to consider providing the following flexible sorting functions for the horizontal axis of the chart:

• Option to match the sorting order of the grid or view

• Sort specification based on any column or condition

• Explicit control of ascending/descending order

These added features will improve the consistency of data visualization, allowing users to understand and analyze information more accurately. As a result, we expect this to lead to improved quality of business decisions and an enhanced user experience.

Currently, when you download a Dataverse data import template, even if your environment contains more than 500 items (fields), not all items will be displayed in the template.

This functionality is not currently provided as a standard feature; therefore, creating a template that includes all fields requires the use of external tools.

Adding a feature to display all items (more than 500 fields) in the data import template will allow users to work without relying on external tools, thus improving user convenience.

Currently, Azure Functions does not provide a standard capability to detect changes in Microsoft Dataverse tables directly, especially in scenarios where polling or outbound-only communication is required.

In many enterprise environments, strict network security policies prohibit inbound communication, making it difficult to adopt event-driven architectures such as Webhooks or Business Events (Dataverse → Azure Functions). As a result, users are unable to implement change detection scenarios using Azure Functions when inbound connectivity is restricted.

If Azure Functions (or Dataverse) could support a standard mechanism for detecting changes via outbound communication (for example, polling with change tracking or a lightweight delta API optimized for Functions), it would significantly improve usability in restricted network environments.

This enhancement would enable:

• Implementation of change detection in environments where inbound communication is not allowed
• Greater flexibility in designing secure, outbound-only integrations
• Simplification of architectures that currently require additional services (e.g., Logic Apps, Power Automate) as intermediaries
• Broader adoption of Azure Functions for enterprise integration scenarios with Dataverse

Currently, users must rely on workarounds or alternative services, which increases complexity and operational overhead. Providing this capability as a standard feature would greatly enhance developer experience and expand supported architecture patterns.

Starting from May 1, the use of model-driven apps embedded in Teams will be restricted/controlled.

As a result, we would like to request the addition of a feature that enables our internal admin users to identify which users are accessing model-driven apps from Teams.

At present, it is not possible to determine this based on available logs or configuration settings, so it will be necessary to consider how to provide effective notifications to admin users.

This request is being posted as a requirement specific to model-driven apps, but in the future, extending this capability to other services (such as canvas apps) and allowing the origin/source information to be identified would also be very effective for internal communication. It would help prevent unexpected interruption/stop of business operations.

We have multiple users accessing the same model‑driven app forms that include embedded Power BI reports. These users operate Dynamics 365 in different languages, which are configured through Dynamics personalization and user language settings.

Currently, embedded Power BI reports displayed within Dynamics 365 model‑driven apps determine their language based on the browser language or Power BI service locale, rather than the Dynamics 365 UI language selected by the user. As a result, users viewing the same form see Power BI content in different or unexpected languages, leading to inconsistent user experience and additional operational overhead.

Business Requirement:

We would like embedded Power BI reports to automatically align with the Dynamics 365 UI language selected by the user, instead of relying on browser language settings. This would ensure:

• Consistent multilingual user experience across Dynamics UI and embedded analytics
• Reduced dependency on browser configuration
• Better usability for global organizations with multilingual users
• Improved alignment between Dynamics personalization settings and embedded Power BI behavior

Requested Enhancement:

Provide a supported mechanism (such as a configuration option, parameter, or integration improvement) that allows embedded Power BI reports in model‑driven apps to inherit the user’s Dynamics 365 UI language.

This enhancement would significantly improve usability for organizations operating across multiple regions and languages while using embedded analytics in Dynamics 365.

Improvement request to how Dynamic Marketing List member list is generated and stored in database

Current behavior:

Dynamic Marketing List member list is generated each time we navigate to Marketing List > Members tab via a fetch query.

This does not generate relationship between target audience records (Contact / Account / Lead) and Marketing List.

When clicking on audience record > Related > Marketing list, the view only displays audience inclusion for Static list, not Dynamic list.

Enhancement request:

We'd like to have the Dynamic list generate a relationship between the records, so that we can view the audience's participant via Related view.

Business Impact:

This will greatly improve data readability for users.

In the past, the email signature was automatically appended for both single emails and the out of the box mass email functionality. At some point in late 2025 the appending on mass emails stopped working. We now have to maintain two separate email templates - one for single emails without the email signature hard coded and a mass email template with the email signature hard coded. Please make it so no matter which email type it is, the signature is appended to the template.

Current behavior (by design): In Dynamics 365, the Mailbox setting "Delete Emails after Processing" cannot be changed to "Yes" from the Mailbox UI screen. This field is read-only by design, even when:

• Creating a new mailbox record (the option is not available at creation time)
• Setting the mailbox to Inactive → Active again
• Editing the mailbox through the standard form

Currently, the only workaround is to create a Business Rule on the Mailbox table to force-update the field value, which is not intuitive for end users and administrators.

Requested improvement: Please allow users (with appropriate privileges) to directly toggle the "Delete Emails after Processing" field between Yes / No from the Mailbox configuration UI, without requiring workarounds such as Business Rules or backend modifications.

Business value / Why it matters:

• Many customers integrate Exchange Online with Dynamics 365 and want emails to be removed from Exchange Online once synced to Dynamics 365 (for storage, compliance, or data governance reasons).
• Currently, admins must rely on workarounds (Business Rules) which:
• Are not discoverable for typical admins
• Increase configuration complexity
• Are difficult to maintain and troubleshoot
• Making this setting directly editable in the UI would significantly improve the usability and administrative experience of Dynamics 365.

Customer impact: This feedback has been raised by enterprise customers in Japan (e.g., OKI Software) and would benefit all organizations using Server-Side Synchronization with Exchange Online.

My team has reported a large number of deployed Copilot Agents and corresponding Application Registrations (service principals) being created in Azure Entra. I am seeking the ability to control which agents are created and deployed.

Currently, there are 14 agents deployed per environment (https://learn.microsoft.com/en-us/dynamics365/sales/ai-agents-apps). As we move toward increased use of Unified Developer Environments (UDEs), the lack of control over agent deployment—and the automatic creation of associated service principals—will only compound this issue.

Like many D365 F&O customers, we currently do not use Dynamics 365 Sales, and customers should have the ability to control the deployment of these assets. 

Hi Team,

This is the idea from Mick Munro - The University of Newcastle

Scenario

We use SharePoint document management integration in Dynamics 365 and is currently facing a scalability concern related to the Default Document Location behavior for specific entities.

The existing Default Document Location has accumulated 50,000+ unique permissions, and our goal is to reset this boundary to reduce the risk of hitting the SharePoint unique permissions threshold.

We would like the ability to change or reassign the Default Document Location for newly created records only, without affecting existing records that are already associated with the original document location.

During investigation, we confirmed that there is currently no straightforward supported way in product behavior to directly change the Default Document Location once configured.

A workaround was implemented to associate newly created records with a new SharePoint document location. However, newly created Contact records still continue to default to the original document location, so the workaround does not fully meet our business requirement.

We also confirmed that this change may be possible through PowerShell, but this approach is operationally complex and difficult to manage in practice.

Expected behavior

We expect Dynamics 365 to support a configurable or supported method to:

• Reassign the Default Document Location for newly created records only
• Preserve the existing document location for historical records without disruption
• Help organizations reset or avoid continued growth of unique permissions on the current SharePoint document location
• Provide a supported and operationally manageable design for this scenario without requiring complex scripting or unsupported administrative workarounds

Actual result

Currently:

• There is no supported product capability to directly change the configured Default Document Location in a way that applies only to newly created records
• Newly created records for some entities, such as Contact, continue to resolve to the original document location even after workaround attempts
• The available PowerShell-based approach is not practical for the customer due to administrative complexity and operational overhead

As a result, we are unable to cleanly redirect new records to a fresh SharePoint document location while keeping existing records unchanged.

Ask

Could the Product Group consider a future enhancement so that:

• We can optionally reassign the Default Document Location for new records only, without impacting existing records
• Organizations can adopt a supported design pattern to reset or control SharePoint unique permission growth over time
• Administrators have a clearer and more manageable way to transition entity document storage to a new SharePoint location when scale or permission-boundary concerns arise

This enhancement would help customers better manage long-term SharePoint document storage scalability, reduce operational complexity, and avoid reliance on difficult manual or scripted workarounds.

Thank you for your help.