Almanac
Microsoft/dataversePower Platform

Consultant KB for Microsoft Dataverse, the data layer under Dynamics 365 and the Power Platform: data model, security model, business logic, APIs and integration, search and queries, analytics and Fabric, ALM and solutions, administration, governance and compliance, and Dataverse as an agent data platform, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Dataverse release plans, docs repo and product blog, plus the author's own consultant notes.

feature-link-to-fabric.mdv1 · history
CurrentApplies to AdminUpdated last monthSource Microsoft Learn

What it does

A wizard in Power Apps that connects a Dataverse environment to a Fabric workspace and puts your tables into OneLake as shortcuts. Dataverse maintains a delta parquet replica in its own storage; Fabric reads it through the shortcut. No storage account, no Synapse workspace, no pipelines.

Key facts

  • Setting it up creates a Fabric lakehouse, a SQL endpoint and a Power BI semantic model, and points shortcuts at your Dataverse tables.
  • Prerequisites: System Administrator in the Power Platform environment, admin of the Power BI workspace, and a Power BI premium licence or Fabric capacity in the same Azure geography as the Dataverse environment. Fabric tenant settings must also allow item creation, workspace creation and external OneLake access.
  • Three authentication options for the connection — organisational account, service principal, or workspace identity. Workspace identity is a Fabric-managed service principal bound to one workspace, and it has to be added as an application user in Dataverse with an appropriate role.
  • By default the wizard selects every non-system Dataverse table with Track changes enabled. Tables without change tracking aren't supported at all.
  • Initial sync can take up to 60 minutes including the delta parquet conversion, longer for large tables. Shortcuts show as "unidentified" until it finishes. Incremental updates typically appear within an hour, depending on churn and load.
  • Link to Fabric increases Dataverse database storage consumption. Each linked table shows up in the capacity chart with an -Analytics suffix.
  • More than 2,000 active Dataverse tables and the link can fail with an error.
  • Every Dataverse per-record limit applies, including the 200 MiB cap on the uncompressed size of a single record returned by the server. Email bodies and attachments are the usual culprits, and the limit can't be raised.
  • Elastic tables are supported provided change tracking is on. Some system tables — bot, workflow, flowmachine and others — are always synced and can't be unselected, as are tables required by add-ins like Customer Insights - Journeys.
  • Removing a table drops its shortcut and stops sync. It doesn't delete anything in Dataverse.

When to use / skip

This is the default analytics path for Dataverse now, and unless the client has a specific reason to own the storage it's the one to pick. It removes the entire "who provisions the lake and who pays for the pipeline" conversation. Skip it if the client's analytics estate genuinely lives outside Fabric and they need the data landing in their own ADLS Gen2 for tools that can't read OneLake — that's still Synapse Link territory. Be honest about the trade: you're swapping their storage bill for Dataverse storage consumption, and Dataverse storage isn't cheap.

Configuration decisions

  • Which authentication method the connection uses. Workspace identity avoids secret management and is the cleanest option if the workspace can support it; organisational account ties the link to one person's credentials.
  • Which tables actually sync. The wizard selects everything with change tracking on, and accepting that default is how storage bills surprise people.
  • Whether to create a fresh Fabric workspace or link into an existing one, bearing in mind the region constraint.
  • Who gets Owner versus Reader on the Dataverse connection, and separately who gets access to the workspace and the lakehouse.
  • Whether to secure at lakehouse or table level using OneLake security before sharing data more widely.

Gotchas

  • The region rule is absolute. No Fabric capacity in the same geography as the environment and the wizard simply blocks you, usually discovered halfway through a workshop.
  • SinkModifiedOn is later than ModifiedOn by design, and for long-running finance and operations transactions a record can sync repeatedly with SinkModifiedOn showing the last sync. Building a latency dashboard on that difference gives you a misleading picture.
  • Adding a column to a linked table doesn't propagate until you use Refresh Fabric tables, and even then only after the next data change on that table.
  • The connection is created with the credentials of whoever ran the wizard. If that person leaves, the link breaks. Share the connection or move it to workspace identity on day one.
  • Unlinking removes the Fabric lakehouse. Relinking triggers a full initial sync of everything.

Consultant notes

  • Do the storage maths in the design phase. "All tables" on a mature Dynamics 365 environment is a materially different number from what the client expects, and the capacity report only charts the biggest consumers by default.
  • Push for workspace identity from the start. Retrofitting it means editing the connection in Fabric's manage connections and gateways, which is a different team and a different change window in most organisations.
  • Tell the client that a single oversized record — usually an email with a large attachment — can block sync for a table, and that the fix is on their side in Dataverse.
  • If the environment is linked to finance and operations, those tables aren't auto-selected. Someone has to ask for them explicitly, and that someone is usually not in the room.

Worth revisiting once low-latency sync has finished its global rollout, or if the 2,000-table ceiling moves.

Was this accurate?