How to Troubleshoot Dynamics 365 Customer Insights

The single most underused tool in Customer Insights troubleshooting is the built-in activity log. Most people skip straight to refreshing things. Don't. Go to Settings > System > Status first. Every pipeline stage, data ingestion, unification, enrichment, segmentation, and exports, is listed here with a timestamped status. A red status tells you exactly which stage broke. A yellow "In progress" that's been running for over 90 minutes means the job is hung.

For a deeper log, go to Settings > System > Notifications. This log stores the last 30 days of system events. Filter by Errors in the dropdown. You'll see entries like:

DataSource refresh failed for source "ContosoSQL"
Error: Microsoft.PowerBI.DataMovement.Pipeline.GatewayDataSourceAccessException
Details: The credentials provided for the SQL source are out of date.

That kind of entry is actionable immediately, you know the source, you know the error class, and you know the fix (update the credentials). Compare that to the generic red banner in the UI and you'll understand why this log needs to be your first stop every time.

For environments connected to Power Platform, also check the Power Platform Admin Center at admin.powerplatform.microsoft.com → Environments → select your environment → Resources > Flows or Analytics > Common Data Service for correlated errors. If Customer Insights is writing unified profiles back to Dataverse, a Dataverse capacity limit or API throttle will show up there, not in Customer Insights itself.

If the Status page shows everything green but your segments still aren't updating, check the last refresh time on each data source. A source that refreshed three days ago when your schedule is daily means the scheduler silently failed. This is a known issue in multi-region tenants where the scheduler process and the data plane are in different Azure regions.

Dynamics 365 Customer Insights data ingestion errors are the most common category I see. The platform supports connectors via Power Query, Azure Data Lake Storage Gen2 direct attach, Dataverse, and a growing set of native connectors. Each has its own failure mode.

For Power Query-based sources (SQL Server, SharePoint, Excel, REST APIs): Go to Data > Data sources, click the three-dot menu on the failing source, and select Edit. Power Query Editor will open. Click Refresh preview in the top ribbon. If the preview fails, the error message here is much more specific than what the main dashboard shows. Look for:

• DataFormat.Error: We couldn't convert to Number, a column data type mismatch, usually because a source schema changed
• Expression.Error: The column 'CustomerID' of the table wasn't found, the source table was renamed or a column was dropped
• DataSource.Error: TCP Provider: Timeout expired, network or firewall issue blocking the on-premises data gateway

For Azure Data Lake Storage Gen2 direct attach: The most common Customer Insights data source connection failed error here is a missing or revoked RBAC role. Open the Azure Portal, navigate to your ADLS Gen2 storage account, go to Access Control (IAM), and verify that the Customer Insights service principal (named something like Dynamics 365 AI for Customer Insights) has the Storage Blob Data Reader role assigned at the container level, not just the account level. Container-level inheritance can be stripped during storage account policy updates.

Run this PowerShell snippet to quickly audit the role assignments on your storage account:

$storageAccountId = "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account-name}"
Get-AzRoleAssignment -Scope $storageAccountId | Where-Object { $_.DisplayName -like "*Customer Insights*" } | Select-Object DisplayName, RoleDefinitionName, Scope

If the output is empty or shows only Reader (not Storage Blob Data Reader), that's your problem. Re-add the correct role, wait 10 minutes for Azure RBAC propagation, then trigger a manual refresh.

This is where Dynamics 365 Customer Insights troubleshooting gets genuinely complex. Unified customer profile not updating is almost always a symptom of a broken unification pipeline, specifically the Match or Merge phase. Go to Data > Unification and look at the status of each phase: Map, Match, and Merge. A failure in Match stops everything downstream.

Click into the Match phase. If it shows a failed state, look at the Match order and the individual rule pairs. Common reasons the Customer Insights match rules are not working:

• Normalized fields returning empty after schema change, if the source field used for normalization (e.g., email address) changed its column name, the normalized output is null, and null fields never match anything
• Precision threshold set too high, a fuzzy match rule set to 95% similarity on a name field that has mixed-case or special character inconsistencies will match very few records
• Circular deduplication, if entity A matches entity B and entity B matches entity C but entity A does not match entity C, the merge graph produces conflicts that require manual resolution

To diagnose: download the match pair output by going to Data > Unification > Match > View last run results. This CSV export shows every pair of records the algorithm evaluated and its confidence score. If the match count dropped significantly from your last successful run, sort by source entity and look for the entity that suddenly has zero matches, that's the broken one.

After fixing the rule, click Run matching only (not a full unification run) to validate quickly. Full unification can take 30–90 minutes on large datasets; match-only runs finish in 5–15 minutes. Once match succeeds, click Run merge separately. This phased approach saves you a lot of time during iterative debugging.

Also check: if you recently added a new data source and included it in the match order, an empty or malformed entity from that source can cascade failures across all match rules. Temporarily remove the new source from the match order and re-run. If unification succeeds, the new source is the problem.

A Customer Insights segment refresh error is almost always caused by a broken dependency, either a measure the segment references has failed, or the unified profile data the segment queries is stale or corrupt. Go to Insights > Segments, find your failing segment, and click the segment name to open its detail view. The Last refresh status row shows either a green timestamp or a red "Failed" with an inline reason.

The most common D365 Customer Insights segment refresh error messages and what they actually mean:

• "Failed to evaluate segment definition, referenced measure 'TotalSpend' could not be computed", go to Insights > Measures and check if TotalSpend itself is in a failed state. Fix the measure first, then re-run the segment.
• "Segment contains more than 100 million profiles, segment cannot be exported", not actually an error, but it blocks exports. Add a filter to narrow the audience size below the export connector's limit.
• "Query execution timed out after 300 seconds", your segment query is too expensive. Break it into sub-segments or simplify the filter logic. Avoid nesting more than two levels of AND/OR conditions with measure-based filters, it generates a full table scan.

For measure calculation failures, go to Insights > Measures and click the failing measure. The Edit view shows the underlying calculation definition. The most common cause of a Customer Insights measure calculation error is a source attribute that was renamed or removed during a data source schema change. Click View data on each attribute used in the formula, if one shows no data, that attribute mapping is broken. Re-map it to the correct field in the current schema and save.

After fixing measures, always refresh measures before refreshing segments. The dependency order is: Data Sources → Unification → Measures → Segments → Exports. Trying to refresh a segment while its upstream measure is still in a failed state will just re-fail the segment immediately.

Export failures in Dynamics 365 Customer Insights are almost always authentication or permissions problems in the destination system. The platform supports 70+ export connectors, Azure Blob Storage, Dynamics 365 Sales, Salesforce, Mailchimp, Google Ads, Meta Ads, and many more. Each authenticates differently, and each has its own way of silently expiring.

Go to Data > Exports. For any export showing a red status, click the three-dot menu and select View run history. The run history log shows the exact HTTP error code returned by the destination. Here's what the most common ones mean:

• HTTP 401 Unauthorized, the connection's auth token or API key has expired. Go to Settings > Connections, find the connection used by this export, and click Edit. Re-authenticate. For OAuth connections (like Salesforce or Google Ads), you'll go through a re-authorization flow in the browser. For API key connections, paste the new key and save.
• HTTP 403 Forbidden, the authenticated identity doesn't have permission to write to the destination. For an Azure Blob export, the service principal needs Storage Blob Data Contributor (not just Contributor) on the container. For Dynamics 365 Sales, the user account used for export needs the Customer Insights Export destinations security role in the target Dynamics org.
• HTTP 429 Too Many Requests, the destination API is throttling Customer Insights. For the Dynamics 365 Customer Insights API 403 error variant of this, check if multiple exports are targeting the same destination simultaneously. Stagger their schedules so they don't all fire at the same time.
• Connection timed out, a network-level block, usually a firewall rule or VNet policy that doesn't allow outbound traffic from Customer Insights to the destination endpoint. Check with your network team for the specific Customer Insights outbound IP ranges for your Azure region (published in Microsoft's Azure IP ranges JSON file).

After fixing the connection, go back to Data > Exports, select the export, and click Run now. Watch the status, if it transitions from Queued to Running to Successful within a few minutes, you're done. If it immediately fails again, the error is different from what the connection edit resolved, and you need to go back to the run history for the new error code.