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.

power-bi/03-power-query-and-dataflows/feature-dataflows.md
feature-dataflows.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

A dataflow is Power Query running in the cloud on a schedule, with its output persisted so multiple semantic models can consume the same prepared tables. It moves the transformation layer out of individual .pbix files and into something shared, refreshable and separately owned.

Key facts

  • Power BI Dataflow Gen1 is in a legacy state and won't get new feature investment. Microsoft's documented recommendation is Dataflow Gen2 for customers with Fabric access; Pro and PPU customers can carry on with Gen1 while Gen2 guidance for those scenarios develops.
  • Gen1 persists output to internal storage (reachable via the Dataflow connector) or to your own Azure Data Lake Storage Gen2 if you configure it. Gen2 adds explicit data destinations — Fabric Lakehouse, Fabric Warehouse, Azure SQL and others.
  • Gen2 uses system-generated staging items in the workspace named DataflowsStagingLakehouse and DataflowsStagingWarehouse. They're internal plumbing, not something to build against.
  • As of April 2026 you can no longer create Dataflow Gen2 items without CI/CD and Git integration support — all new Gen2 items get it by default.
  • Dataflow refresh is scheduled from the workspace, the same way semantic model refresh is.
  • Dataflows run Power Query Online, so folding indicators are available — which they aren't in Desktop.
  • Dataflows may not be available in the Power BI service for all US Government DoD customers.

When to use / skip

The case for a dataflow is reuse, not tidiness. If three models are each connecting to the same ERP tables and applying the same joins and filters, that's a dataflow — one refresh against the source instead of three, one place to fix the logic, and report authors who never see the credentials. If one model uses the data and always will, a dataflow adds a hop, a refresh dependency and a thing to monitor for no return. Also reach for one when you want to reduce load on a fragile source system or take direct source access away from self-service authors.

Configuration decisions

  • Gen1 or Gen2 — which is largely decided by whether the client has Fabric capacity, but confirm rather than assume.
  • Whether to split staging dataflows (raw extract, no logic) from transformation dataflows (the business rules). It costs an extra layer and buys you a much cheaper reload when logic changes.
  • Where the output lands: internal dataflow storage, the client's own ADLS Gen2, or a Fabric destination.
  • The refresh chain — dataflow first, then dependent models, with enough gap that models don't read a half-written table.
  • Who owns the dataflow workspace, and whether report authors get Viewer or Contributor on it.

Gotchas

  • Refresh dependency is the big one. A dataflow failing at 2am means every downstream model refreshes against yesterday's data, often without an obvious error anywhere.
  • Dataflows using an on-premises data gateway older than April 2021 may fail — Microsoft flagged this from 15 March 2023 and the fix is to update the gateway and sign in to it again.
  • Consuming a dataflow into a model doesn't fold to the underlying source. You're reading a persisted output, so all the folding work happens inside the dataflow, not downstream of it.
  • Gen1 to Gen2 isn't a switch. Microsoft publishes a migration path but it's a rebuild-and-repoint exercise, and it needs planning if the client has dozens of them.
  • Dataflow sprawl is real and quieter than report sprawl. Nobody audits them, and orphaned dataflows keep refreshing and keep consuming capacity.

Consultant notes

  • Position dataflows as the shared data-prep layer with a named owner, not as "somewhere to put the queries". Without an owner they rot.
  • If the client is heading to Fabric, say plainly that Gen1 is legacy and that anything built there now will need migrating. Better that conversation happens at design time.
  • Dataflows are a good governance lever — they let you cut off direct source access to self-service authors without cutting off the data. That argument lands well with IT and security.
  • Build monitoring for dataflow refresh failures, not just model refresh failures. Most clients only watch the second one.

Revisit whenever the client's Fabric position changes, or when the Gen2 guidance for Pro and PPU scenarios firms up.

Was this accurate?
Related
OneLake and workspace items05-service-and-workspacesSemantic model fundamentals01-semantic-modelsDeployment pipelines09-alm-and-deploymentXMLA endpoint09-alm-and-deploymentGit integration for workspaces09-alm-and-deploymentPower BI vs native Dynamics 365 reporting11-decision-guides