Dynamics 365 Customer Insights - Data

Currently, there is no option to connect the Dataverse environment while trying to export a segment from Customer Insights – Data to Customer Insights – Journeys.

Even though the Dataverse connection is added under Data Sources, it does not appear under the Export Destinations when attempting to export a segment. As a result, we are unable to push segments from Customer Insights (Data) to Journeys for real-time marketing.

It would be extremely helpful if Microsoft could enable or clearly guide on establishing the correct Dataverse export connection for seamless segment transfer between Customer Insights – Data and Journeys, especially in trial or newly provisioned environments.

"Combine a group of fields" detailed here : https://learn.microsoft.com/en-us/dynamics365/customer-insights/data/data-unification-merge-tables

Currently when you combine address fields into a group it still leaves the original fields in the unification output (the customer profile table).

This can be confusing as you end up with 2 addressline1, 2 addressline2 etc, one that isn't combine and one that is.

Please can the original field either allowed to be excluded or hidden from the result of the unification if the fields are used in a combined group.

Currently the "Combine a group of fields" has a 15 data source limit.

The group by provides a way of keeping together fields in unification, like address fields, that should not be treated as individual fields, The current limit means that you would need to pick which data sources not to combine and show in the end unification which is problematic.

Please can this be removed so it can match the number of data sources.

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.

Based on the document Exclude bot interactions - Dynamics 365 Customer Insights from Microsoft, inflated open rates are a known occurrence due to the fact that bot protection does not apply to email opens. As a result, nonhuman traffic can artificially increase open rates, leading to misleading analytics.

I would like assistance in identifying a solution to prevent this issue from occurring in the future

Sending alerts to notify administrators when there is any restarts, DB availability movements or container move to ensure transparency and customer visibility regarding these issues.

Purpose of Notifications

The goal is to proactively inform administrators about infrastructure-level changes that could impact system performance, data availability, or customer experience. These alerts would serve two key purposes:

1. Transparency: Ensuring that internal teams are aware of backend operations that may affect service continuity or performance.
2. Customer Visibility: Allowing support teams to communicate confidently with customers about any disruptions or changes, backed by real-time system insights.

What Each Alert Covers:

• Restarts: Alerts when services or containers are restarted—whether planned (e.g., updates) or unplanned (e.g., crash recovery).
• DB Availability Movements: Notifications when databases are moved between nodes or regions, which may affect latency or access.
• Container Moves: Updates when containers are relocated for load balancing, scaling, or maintenance purposes.

Implementation Suggestions:

• Integrate with existing monitoring tools (e.g., Azure Monitor, Application Insights).
• Use email or dashboard alerts for delivery.
• Include metadata like timestamp, affected resources and expected impact.

In our case, we want to add an event registration form to our website, which means that people who are not yet in our contact database could register. They would fill out an event registration form, not a marketing form and therefore would not have consent for marketing communication. Without this prior consent, they would be unable to receive any emails, such as the event confirmation email.

Unfortunately, this approach doesn’t meet our current requirements. We need a solution that accommodates non-registered contacts in the system who still need to receive event-related emails.

While I have no issue using a marketing form (since it would include the DOI process), it does not have the event-specific fields, such as session summaries or speaker information. Additionally, I would not be able to integrate the marketing form into the event system, where registrations, check-ins, and other event-related actions are managed.

As it stands, according to the current logic, a new contact must register twice: first with the marketing form, then with the registration form and finally confirm the DOI email.

However, this issue could be resolved if the registration form had the same functionality as a marketing form, triggering the DOI process and sending the automated first DOI confirmation email.

We would appreciate any suggestions on how this process can be streamlined while still meeting the necessary requirements.

Currently, when using a form published with the "Form capture" option, the system tracks only the number of submissions. It does not record visit metrics, which consistently display as zero in the Analytics tab. This creates a confusing user experience, as the visit metric is visible but non-functional—leading users to question whether their setup is incomplete or incorrect.

Incorporating visit metrics into form capture functionality is critical for optimizing user engagement, improving conversion rates, and enabling data-driven decision-making.

• By understanding the ratio of visits to submissions helps identify friction points in the form experience, allowing teams to make targeted improvements that enhance completion rates.
• Visit metrics provide valuable insights into form performance across campaigns, channels, and audience segments, supporting more accurate ROI analysis and strategic adjustments.

If you are creating a measure that shows the latest order based on several different tables ingested from several different systems, it is easy to create the latest order per customer per ingested table, but combining the latest order over several different tables, or just measures, is not possible. Either it has to be done by first putting these into activities and then doing "latest" on the activities, or running the calculations outside of CI-D, with for instance, Fabric.

Currently the ListAllSegments operations include almost everything about segment metadata, but it does not include the 'SegmentType' which indicates the segment is 'Static' or 'Dynamic'. Having this attribute as part of the same API can help any consumer system.