What it does
Customer Insights - Data can read Delta tables straight out of a Fabric lakehouse in the same tenant, with no copy into staging storage first. Combined with Dataverse's Link to Microsoft Fabric on the other side, it lets a client run Fabric as the single lakehouse for both what goes into Customer Insights and what comes out.
Key facts
- The connector reads Delta format only. CSV and Parquet tables in the lakehouse are not selectable, and Fabric Data Warehouse tables aren't supported.
- Fabric shortcuts are honoured, so tables that physically live in another workspace can still be ingested through the target workspace.
- Two tenant settings have to be on, both set by a Fabric admin: "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 Dynamics 365 AI for Customer Insights service principal must be added to the Fabric workspace with the Contributor role. The person configuring the data source needs at least Viewer on the workspace.
- Every table needs a primary key column with unique, non-null values, typed String, Integer or GUID. Where it can't be auto-detected you assign it during set-up.
- Only Delta reader features at
minReaderVersion1 or 2 are supported. Anything needing a higher reader version won't be readable. - One Fabric OneLake data source per workspace. Multiple lakehouses across multiple workspaces means multiple data sources.
- Private Link can be enabled on the connection where the workspace has inbound access protection turned on.
- Delta log retention matters. Set
delta.logRetentionDurationanddelta.deletedFileRetentionDurationlonger than your refresh cadence, or refreshes fail and you're into a manual full refresh to recover. - On the output side, Dataverse's Link to Microsoft Fabric surfaces Dataverse tables into OneLake as shortcuts with a lakehouse and SQL endpoint, one Dataverse environment to one Fabric workspace, and includes non-system tables with change tracking enabled.
When to use / skip
If the client already runs Fabric as their analytics platform, this is the obvious ingestion route — no ADLS staging layer to build and pay for, no copy job to monitor, and the data engineering team keeps ownership of the tables Customer Insights reads. If they don't have Fabric, this is not a reason to buy it; the Azure Data Lake and Dataverse connectors cover the same ground without a new capacity to fund. Be careful with clients who have a Fabric proof of concept rather than a Fabric practice — the Delta log retention discipline and the reader-version constraint assume someone is actually looking after those lakehouse tables. On the output side, going via Link to Microsoft Fabric to get msdynci_ tables into OneLake is worth it when the client wants Spark or SQL over profiles at scale, and overkill when they just want a Power BI report.
Configuration decisions
- Which workspace is the integration point, given the one-data-source-per-workspace limit and the fact that shortcuts can pull tables in from elsewhere.
- Primary key per table, including for anything the connector can't auto-detect — this is a modelling decision, not a click.
- Whether the Fabric side is left as-is or a curated set of Delta tables is built specifically for Customer Insights to read.
- Delta retention settings on every table in scope, agreed against the Customer Insights refresh schedule.
- Whether the output path is a Fabric export, Link to Microsoft Fabric over the Dataverse tables, or nothing at all because everything downstream reads Dataverse.
- Private Link, if the workspace is locked down for inbound access.
Gotchas
- The two Fabric tenant settings are the usual blocker. They're tenant-wide, they're owned by whoever runs Fabric, and that person is rarely in your project. Raise the request in week one.
- Delta log expiry is the failure mode that bites in month three, not week one. The refresh worked fine until the logs the connector needed were vacuumed away.
- Upstream table changes in the lakehouse — a schema change, a table rewritten by a pipeline — propagate straight into Customer Insights. There's no staging copy absorbing it any more, which is the point and also the risk.
- Someone will point the connector at a Data Warehouse item because it looks like a lakehouse in the Fabric UI. It isn't supported.
- Link to Microsoft Fabric on the Dataverse side consumes Dataverse storage, because the linked tables are held in delta parquet. Check the client's capacity position before enabling it on a large environment.
- One Dataverse environment links to a single Fabric workspace, so if the client already used that link for something else, your output plan needs revisiting.
Consultant notes
- Get the Fabric admin in the room for the architecture session. This integration is decided by settings you don't control and can't work around.
- Agree the Delta retention values in writing with the data engineering team and put them in the runbook. It's the single thing most likely to break the refresh later.
- Demo the no-staging story to the client's data team specifically — losing an ADLS hop and a copy pipeline is a real cost saving they'll appreciate more than the business sponsor will.
- Check whether the client's Fabric capacity is sized for the read pattern before promising refresh windows.
- If the client wants profiles back out in Fabric, decide between an export and the Dataverse link early; they have different latency, different cost and different governance owners.
Worth another look when the in-place upgrade path arrives, or if Delta reader version support widens.