What it does

Points Customer Insights - Data at managed Delta tables in a Microsoft Fabric lakehouse and reads them in place. No copy, no staging, no dataflow. Shortcuts inside the lakehouse mean tables physically living elsewhere still appear as candidates.

Key facts

• Listed by Microsoft as preview in the data sources connector table. Treat it as preview for contractual purposes even though it works well.
• Managed Delta tables only. CSV and plain Parquet are not supported, and Fabric Data Warehouse tables are not supported either.
• Two tenant settings must be on in the Fabric admin portal: "Users can access data stored in OneLake with apps external to Fabric" under OneLake settings, and "Service principals can call Fabric public APIs" under Developer settings. The first can take about 15 minutes to take effect.
• The Dynamics 365 AI for Customer Insights service principal needs the Contributor role on the Fabric workspace. The admin creating the data source needs at least Viewer on that workspace.
• Workspace and Customer Insights environment must be in the same Microsoft Entra tenant.
• One Fabric OneLake data source per Customer Insights workspace. If you need tables from several Fabric workspaces, surface them into the one lakehouse using Fabric shortcuts.
• Each table needs a primary key column with unique, non-null values, typed String, Integer or GUID.
• Delta reader version matters: minReaderVersion 1 or 2 only. Deletion vectors and anything else needing reader version above 2 will not read.
• Tables appear in the picker named <lakehouse>_Lakehouse_<schema>_<table>, which is verbose and hard to unpick if the client has naming sprawl.
• If Fabric inbound access protection is enabled on the tenant, you need private links configured before the connection works.
• Microsoft has flagged an upgrade path for existing Azure Data Lake Storage sources onto this connector, stated as coming by October 2026.

When to use / skip

If the client has a Fabric lakehouse and their customer data already lands there, this is the connector you want. Reading Delta in place means unification only reprocesses what changed, ingestion is quicker, and you stop maintaining a duplicate copy that drifts. On a greenfield build where the data platform team is already Fabric-first, make this the default and treat Power Query as the exception.

Skip it if Fabric isn't in the picture, or if the customer data lives in Fabric but in a warehouse rather than a lakehouse — the warehouse isn't supported and pretending otherwise wastes a sprint. Also skip if the client's Fabric estate is spread across many workspaces owned by different teams and nobody will agree to shortcut everything into one lakehouse; the one-source-per-workspace rule turns that into a political problem rather than a technical one.

Preview status is worth a conversation on regulated or high-stakes programmes, though in practice the bigger risk is Delta log retention, not the preview label.

Configuration decisions

• Which single Fabric workspace becomes the connection point, and which tables get shortcutted into its lakehouse to reach Customer Insights. This is effectively an architecture decision and needs the data platform owner in the room.
• Who owns the service principal grant on the workspace, and whether workspace role changes are governed. If someone drops the Contributor role, ingestion stops.
• Delta log retention settings on the lakehouse — delta.logRetentionDuration and delta.deletedFileRetentionDuration — set longer than your refresh cadence.
• The primary key column per table, and whether the lakehouse guarantees it stays unique and non-null. Nominating a column the upstream pipeline can null out is a slow-motion failure.
• Whether inbound access protection is on, and therefore whether private links are part of the build.
• Which tables get data profiling enabled. It's optional per table and column, and it costs time in the data preparation task.

Gotchas

• Aggressive VACUUM on the lakehouse deletes the Delta log history the connector relies on. When logs are gone, the refresh fails and the fix is a manual full refresh on the affected table. Set retention longer than the refresh gap — three weeks or more for a fortnightly cadence.
• The "no tables shown / page unresponsive" symptom almost always means one of the two tenant settings is off, or the service principal was never added to the workspace. It doesn't produce a helpful error.
• The tenant setting change takes up to 15 minutes. People flip it, retry immediately, conclude it's broken, and open a ticket.
• One data source per workspace is a hard limit, and it isn't obvious until you try to add the second one. Design for shortcuts up front.
• A Fabric team enabling deletion vectors for their own performance reasons will silently break your ingestion, because that pushes minReaderVersion past what the connector reads.
• Table naming in the picker is generated from lakehouse, schema and table. With similar table names across schemas you will pick the wrong one at least once.

Consultant notes

• Get the two Fabric tenant settings and the service principal grant raised as a change request in week one. They need a Fabric administrator, not a Customer Insights administrator, and that person is usually in a different team with a different backlog.
• Tell the client plainly that their lakehouse maintenance jobs are now part of the Customer Insights dependency chain. VACUUM and log retention are no longer purely a Fabric concern.
• Demo the refresh reading changed data only. Clients migrating from Power Query copies find the speed difference more persuasive than any architecture diagram.
• If they're on ADLS today, mention the stated upgrade path rather than rebuilding sources by hand — but don't plan a delivery date around it.
• Check preview status again before contract sign-off; the connector table is the place it's flagged, not the connector article.

---

Worth revisiting once the Fabric OneLake connector reaches GA, or when the ADLS upgrade path actually lands.