Olwen Nguyen

Show straightforward error information in the CI–Data UI for each step (ingestion, unification, enrichment, export). Include what failed, where it failed, a reference ID, and plain‑language guidance to fix it. Let users copy/export the details, open the related run history, and choose how much detail they see based on their role. Use the existing diagnostic events for consistency, reduce support tickets, and enable self‑service troubleshooting.

Idea by Aditya Patil's team

Problem:

In Dynamics 365 Customer Service, an Entitlement becomes locked once Active, and updates to key fields (including status transitions) are restricted. In an F&O ↔ Dataverse Dual-write scenario, when a related Subscription Billing Contract is terminated in Finance & Operations, Dual-write attempts to update the Entitlement in Dataverse but the update fails because the Entitlement can only be edited in Draft state. This prevents the Entitlement status from reflecting the real contract lifecycle.

Current behavior:

Terminating the contract in F&O triggers Dual-write, but the Entitlement update fails with an error similar to: “You can only edit a draft entitlement”. As a result, Entitlement remains Active/locked, even when the upstream contract is terminated.

Expected behavior

When a linked Subscription Billing Contract is terminated in F&O, Dual-write should be able to reliably transition the Entitlement status

Requested enhancement:

Provide a supported, integration-safe mechanism for Entitlement lifecycle updates, such as:

1. Allow Dual-write (application user / integration context) to perform specific status transitions for Entitlements when driven by upstream contract termination
2. Introduce a configurable option/policy that permits Entitlement updates required for lifecycle synchronization when initiated by system integration processes.

Hi Customer Insights - Data team,

This is the idea from: Romy Briers - Angle Auto Finance

Scenario

The customer sends Dynamics 365 Customer Voice surveys.

• When they target a standard CI-J segment (Dataverse Contact as the targeting entity), the survey response interaction is visible on the Dataverse Contact timeline.
• When the journey targets a Customer Insights – Data (CID) segment (unified profiles), the survey response interaction is not visible on the Dataverse Contact timeline, even though business users rely on the Contact record as their primary workspace.

Expected behavior

When a Customer Voice survey is sent—regardless of whether they target a Dataverse Contact segment or a CID (unified profile) segment—business users should be able to see survey interactions in a consistent “single pane of glass” experience from the Dataverse Contact timeline (or an equivalent supported timeline view), assuming the unified profile can be matched to a Dataverse Contact.

Actual result

When customer targets a CID segment, the resulting Customer Voice survey interactions do not appear on the Dataverse Contact timeline.

PG confirmed this aligns with current product behavior and documentation, and no supported workaround or near-term change plan is available at this time.

Ask

Could the Product Group consider a future enhancement so that Customer Voice survey interactions targeting CID segments (unified profiles) are surfaced in the Dataverse Contact timeline (or a supported equivalent), when a corresponding Contact exists?

Hi Customer Service workspace team,

This is the idea from: Andreas Wijaya - Bupa ANZ

Scenario

The customer uses Contact as the main anchor tab / supertab in Customer Service workspace.

When an agent is working within Contact A, the customer expects that opening Contact B should launch Contact B under its own separate anchor tab, rather than as a child tab under Contact A. In addition, when the agent opens Dashboard, Activities, Opportunities, or other entity list pages from the left navigation, the customer expects those pages to open as their own separate anchor tab / supertab instead of as subtabs under the currently focused contact session.

Expected behavior

• When an agent navigates from Contact A to Contact B in Customer Service workspace, Contact B should open under its own anchor tab rather than as a child tab under Contact A.
• When an agent opens Dashboard, Activities, Opportunities, or other entity list pages from the left navigation, those pages should open as separate anchor tabs / supertabs instead of as subtabs within the current focused session.

Actual result

Currently, when the agent is already working within an existing focused session such as Contact A:

• Contact B opens as a subtab under Contact A instead of under its own anchor tab.
• Dashboard, Activities, Opportunities, and other sitemap-opened pages load as tabs within the current focused session rather than as separate anchor tabs.

PG confirmed this aligns with the current product design in Customer Service workspace. The documentation also states that pages opened from the site map load in the current focused session, while the anchor tab is defined when the session starts. At this time, there is no supported SDK or configuration to make sitemap-opened pages launch as anchor tabs by default.

Ask

Could the Product Group consider a future enhancement so that:

• Navigating from Contact A to Contact B can optionally open Contact B under its own separate anchor tab, and
• Dashboard, Activities, Opportunities, or other sitemap-opened entity list pages can optionally launch as separate anchor tabs / supertabs instead of subtabs in the current focused session?

This enhancement would help customers maintain clearer separation between workspace contexts, reduce agent confusion, and avoid the need for complex custom workaround logic using Microsoft.Apm APIs.

Thank you for your help.

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.

Hi Team,

This is the idea from Jerry C.W. Wang(王嘉煒):

Scenario

We are evaluating the use of Copilot Studio and have identified a product design concern related to the current dependency on a Dataverse-enabled environment for core Copilot Studio usage.

During our investigation, we understood that Dataverse is currently a key dependency for creating and operating Copilot Studio agents in many scenarios, and that environments used for agent creation generally require a Dataverse data store or database to be available.

From the customer perspective, this introduces additional environment planning, governance, and operational considerations. It also creates extra complexity for organizations that would prefer to adopt Copilot Studio in a lighter-weight manner without needing to enable Dataverse in the target environment. In some cases, this also leads to additional Azure subscription considerations as part of the broader customer environment design, which may not always align with the customer’s preferred deployment model.

At the moment, there does not appear to be a straightforward supported way to use Copilot Studio without having Dataverse enabled in the environment for the relevant scenarios we reviewed. As a result, customers who want to use Copilot Studio in a more minimal or simplified architecture have limited options.

Expected behavior

We expect Copilot Studio to support a configurable or supported method to:

Allow customers to use Copilot Studio in selected scenarios without requiring Dataverse to be enabled in the environment Provide a simpler deployment option for customers who do not need Dataverse-backed capabilities Reduce environment setup complexity for organizations that want to adopt Copilot Studio with a lighter operational footprint Provide a supported and operationally manageable design for this scenario without requiring customers to enable Dataverse when it is not needed for their intended use case

Actual result

Copilot Studio usage is closely tied to environments that have a Dataverse data store. If an environment does not have a Dataverse enabled, it may not appear as usable for agent creation in Copilot Studio until the database is created. There is no clear supported product capability to allow customers to use Copilot Studio in a way that avoids this Dataverse dependency for the scenarios we reviewed

As a result, customers are unable to adopt Copilot Studio in a simplified environment model without enabling Dataverse, even when their intended business scenario may not require broader Dataverse-backed functionality.

Ask

Could the Product Group consider a future enhancement so that:

• Customers can optionally use Copilot Studio for suitable scenarios without requiring Dataverse to be enabled in the environment
• Organizations can adopt a supported lightweight design pattern for Copilot Studio where full Dataverse enablement is not necessary Administrators have a clearer and more manageable way to deploy Copilot Studio in environments where they want to minimize setup, governance, and operational overhead
• Customers have more flexibility to align Copilot Studio deployment with their environment strategy and architecture preferences

This enhancement would help customers reduce implementation complexity, improve deployment flexibility, and avoid being forced into a broader platform dependency when their scenario may not require it.

Thank you for your help.

Hi Team,

Please check the idea from our valuable customer below:

Problem Statement

Customers need the ability to view configured booking tooltip fields when hovering over bookings in Daily/Weekly/Monthly views. Today, the “Booking tooltips view” setting is documented and implemented to affect Hourly view only. In interday views, tooltips are either limited to a fixed template or behave inconsistently depending on the schedule board tab implementation (for example, legacy/older behavior vs the New Schedule Board). This creates operational disruption for customers who relied on tooltip-driven workflows for years and now see the behavior removed or inconsistent after newer schedule board updates aligned to current design.

Current Behavior (As‑Is)

1) “Booking tooltips view” impacts Hourly view only (by design / per documentation).

2) In Daily/Weekly/Monthly (interday) views, tooltips may:

  - Not reflect the configured tooltip view, or

  - Show only a minimal fixed set of fields, or

  - Behave inconsistently across schedule board tabs/environments depending on underlying implementation.

Business Impact (Why this matters)

Dispatchers/schedulers depend on hover tooltips to quickly validate booking/work order details without opening each record. When interday tooltips don’t show configured data, schedulers must manually open records, reducing productivity and delaying scheduling decisions. This gap contributes to customer dissatisfaction when a previously relied-on workflow no longer behaves consistently.

Requested Enhancement (To‑Be)

Provide a supported, configurable, and consistent way to display Booking Tooltip information in Interday views (Daily/Weekly/Monthly) on the New Schedule Board, while ensuring tooltip content remains accurate and safe when bookings are aggregated.

Goals

1) Allow customers to see meaningful booking details on hover in Daily/Weekly/Monthly views without opening each record.

2) Ensure tooltip content is accurate, especially when the hover target represents multiple underlying bookings (aggregates).

3) Provide a supported configuration so customers are not relying on legacy/unsupported behavior.

Success Metrics 

- Reduced need to open booking/work order forms during dispatching (fewer clicks and record opens).

- Improved hover latency and stability (no crashes, consistent tooltip rendering).

- Reduced support escalations related to tooltip inconsistency across schedule board tabs.

- Higher customer satisfaction with interday scheduling workflows.