Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

feature-onelake-and-workspace-items.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn

What it does

OneLake is the single storage layer under every Fabric tenant, built on Azure Data Lake Storage Gen2 and holding tables in open Delta Parquet or Iceberg format. On a Fabric-enabled tenant, a Power BI workspace becomes a container in that lake and can hold lakehouses, warehouses, notebooks, pipelines and eventhouses alongside the semantic models and reports.

Key facts

  • One OneLake per tenant. You can't create a second one or delete it, and there's nothing to provision.
  • The hierarchy is tenant, then workspace, then data items. Each workspace belongs to a capacity tied to a region and billed separately.
  • Every workspace surfaces as an ADLS Gen2 container and every data item as a folder inside it, so existing ADLS Gen2 tools and SDKs work against it. There's a OneLake file explorer for Windows that mounts it like OneDrive.
  • Shortcuts reference data in another workspace, another OneLake location, or outside it entirely — ADLS Gen2, Blob, Amazon S3 and S3-compatible sources, Iceberg-compatible sources, Dataverse, on-premises sources — without copying. Source changes are visible through the shortcut immediately.
  • Mirroring continuously replicates external databases into OneLake as Delta Parquet. Supported sources include Azure SQL Database, Azure Cosmos DB, Azure Database for PostgreSQL, Azure Databricks with Unity Catalog and Snowflake.
  • Direct Lake is the Power BI storage mode that reads Delta tables in OneLake directly, without an Import copy and without a DirectQuery round trip.
  • OneLake security roles define permissions down to folder, table, row and column, enforced consistently whether the user arrives via SQL, Spark or a Power BI report.
  • Sensitivity labels and DLP policies apply to OneLake items and follow the data into exports.
  • Redundancy is zone-redundant storage where availability zones exist, locally redundant elsewhere. Soft delete keeps deleted files for seven days. Geo-replication to a paired region is opt-in per capacity.
  • Workspace-level OneLake diagnostics stream data access events into a lakehouse — who read what, when, and through which route, including cross-workspace shortcut access.

When to use / skip

For a Power BI team, the honest answer is that most of OneLake arrives whether you want it or not, and the decision is how much of it you adopt. If the client's data already lands somewhere sensible and the models are working, you don't need lakehouses to make Power BI better. Where it earns its place is when you're currently copying the same data three times — into a warehouse, into a dataflow and into an Import model — or when model size is pushing the capacity ceiling and Direct Lake would remove the copy. Shortcuts and mirroring are also worth a look purely as a way to stop building extraction pipelines nobody wants to maintain.

Configuration decisions

  • Whether Power BI content and Fabric data items share workspaces or live in separate ones. Mixed workspaces mean Contributor now grants write access to lakehouse data as well as reports.
  • Whether data reaches OneLake by shortcut, by mirroring, or by an actual pipeline — three very different operational profiles.
  • Whether security is enforced in the semantic model with RLS, or in OneLake with security roles that apply across every engine.
  • Whether OneLake diagnostics are switched on per workspace, and where those logs land.
  • Whether BCDR geo-replication is enabled on the capacity, which is a capacity-level decision with a cost the client has to agree.

Gotchas

  • Workspace roles got wider without changing name. A Contributor in a Fabric-enabled workspace can write and delete lakehouse and warehouse data, not just edit reports. Access reviews written for Power BI-only workspaces are now out of date.
  • Shortcuts don't carry the source's permissions automatically. Reading through a shortcut needs permissions at the destination too, and people assume the shortcut is the boundary.
  • Soft delete is seven days. That's a recovery window, not a backup strategy, and it's shorter than most clients assume when they hear "built-in protection".
  • Each workspace sits in a capacity's region. Mixed-region workspaces in one tenant create data residency questions that are much easier to answer before the workspaces exist.
  • "One copy of data" is a design goal, not an automatic outcome. Nothing stops a team importing a lakehouse table into a semantic model and having two copies again.

Consultant notes

  • Don't sell Fabric as an upgrade the Power BI users have to take. Most of them can carry on exactly as they were; the change is what's now possible next to them, not what's now required.
  • The governance conversation is the one worth having early. Domains, workspace ownership and OneLake security roles are decisions that get very expensive to change once fifty workspaces exist.
  • If the client is on Fabric capacity already, Direct Lake is the argument that lands — no copy, no refresh window, no size ceiling in the usual place. Just be straight that it has its own constraints and isn't a drop-in for every Import model.
  • Flag the region point to anyone with data residency obligations. Capacity region is set at creation and moving workspaces afterwards is not a five-minute job.

Revisit when OneLake security roles or the shortcut permission model change, or after the next Fabric governance release.

Was this accurate?