Choosing between Customer Insights - Data and a Fabric-first build

What it does

The Fabric OneLake connector lets Customer Insights - Data read Delta tables straight out of a Fabric lakehouse instead of you staging copies in Azure Data Lake Storage. It's the join between the two architectures a client is usually choosing between: build the customer view yourself in Fabric, or buy the identity resolution and activation layer and feed it from Fabric.

Key facts

The OneLake connector is in preview. It reads managed Delta tables from a Fabric lakehouse, and Fabric shortcuts can bring in Delta tables that live outside the target workspace.
Only Delta format is supported. CSV and non-Delta Parquet aren't, and neither are Fabric Data Warehouse tables.
Tables must stay within Delta features needing minReaderVersion 1 or 2. Deletion vectors and anything above that are out.
One Fabric OneLake data source per workspace.
Every table needs a primary key column with unique, non-null values — string, integer or GUID.
Two tenant settings have to be on: "Users can access data stored in OneLake with apps external to Fabric" and "Service principals can call Fabric public APIs".
The Dynamics 365 AI for Customer Insights service principal needs the Contributor role on the Fabric workspace; the admin setting the source up needs at least Viewer.
Data doesn't stay in OneLake. It's transferred and processed in the geography of the Customer Insights - Data environment, which is a data residency conversation, not a technical footnote.
An upgrade-in-place path for existing Azure Data Lake Delta sources is stated as releasing by October 2026, so treat it as planned rather than shipped.
If Inbound Access Protection is on in the Fabric tenant, you'll need private links.

When to use / skip

My default for a client who already has Fabric and a competent data team: keep the plumbing in Fabric and let Customer Insights - Data do the two things it's actually good at — fuzzy identity resolution and activation into Journeys, Sales and the ad platforms. Cleansing, conformance and history belong in the lakehouse where you can test them, version them and reuse them for finance reporting. Ingesting raw source extracts straight into CI Data and doing the tidying with Power Query is how projects end up with transformation logic nobody can review.

Go Fabric-first and drop the CDP entirely when the customer view is wanted for analysis rather than action. If the deliverable is a Power BI report on customer behaviour, you don't need unified profiles, segments or exports, and a notebook plus a dimension table will do it at a fraction of the licence cost.

Go the other way — CI Data doing more of the work — where the client has no data engineering capability. A marketing team with a Power Query-literate analyst can run the whole thing in Customer Insights - Data and get to a working segment in weeks. Handing them a Fabric workspace instead means they wait on a queue for every change, and the project stalls. That's a real trade and worth saying out loud: you are choosing between a slower, more governable build and a faster one the business can maintain.

The one case where I'd avoid the OneLake connector while it's in preview is a regulated client with a hard go-live. Use the supported Delta Lake or Common Data Model connection against ADLS Gen2 instead, and revisit once the upgrade-in-place path has actually shipped.

Configuration decisions

Where the conformance layer sits: a Fabric gold layer that CI Data reads, or Power Query steps inside CI Data.
Whether to ingest through the OneLake connector, ADLS Gen2 Delta tables, or the Dataverse connector for anything already in Dataverse.
Whether to use Fabric shortcuts to expose tables from other workspaces, given the one-source-per-workspace limit.
Which column becomes the primary key on each lakehouse table, and whether it's genuinely unique and non-null in production data rather than in the sample.
Whether the CI Data environment's region is acceptable for data that currently never leaves the client's OneLake region.
Who owns the Fabric workspace permissions, including the service principal grant, once the consultancy leaves.

Gotchas

The two tenant settings are Fabric admin territory. On a large client these take longer to get approved than the whole build, so raise them in week one.
A Delta table that picks up deletion vectors later — someone enabling them for performance in Fabric — silently puts the table outside what the connector supports.
One OneLake data source per workspace pushes you into a workspace layout decision early. Splitting a monolithic workspace afterwards is painful.
Preview features aren't covered by the same support commitments. Say so in writing before the client builds a go-live plan around it.
Processing in the CI Data environment's geography catches out clients who assumed a Fabric-native connection meant the data never moved.
Fabric Data Warehouse tables not being supported surprises teams whose gold layer is a warehouse rather than a lakehouse. Materialise into a lakehouse or change the target.

Consultant notes

Ask early whether the client has bought Fabric capacity. If they haven't, the Fabric-first option carries a cost they haven't budgeted, and the honest comparison changes.
Demo the same segment built both ways if you have time. Business stakeholders consistently underestimate how much of the work is matching, not querying.
Push back on any architecture where transformation logic is split across both — half in a notebook, half in Power Query. Pick one place and hold the line.
Before go-live, check the service principal grant survives whatever workspace governance the client runs, and that primary key uniqueness is enforced upstream rather than assumed.

Worth another look once the OneLake connector leaves preview and the upgrade-in-place path for existing Delta sources actually lands.