Power BI Dataflows Explained for Beginners

In Power BI Desktop, Power Query prepares data for one semantic model. When three reports need the same cleaned customer table, each file repeats the same steps, queries the same source, and drifts a little further from the others with every edit. Dataflows move that preparation into the Power BI service, where it is done once and shared. This guide explains what they are, which version to use, and when they are worth the extra moving part.

What a dataflow is

A dataflow is Power Query running in the Power BI service instead of in a desktop file. You connect to sources, apply transformation steps in the familiar Power Query editor, and save the results as tables. Semantic models then connect to the dataflow rather than to the original sources. Microsoft lists the scenarios dataflows are designed for (Microsoft Learn: introduction to dataflows):

• Reusable transformation logic that many semantic models and reports share, without each one connecting to the source separately.
• A single source of truth, curated from raw data with agreed definitions.
• Protecting sources: report creators use the dataflow, so their access to the underlying systems can be limited and the load on those systems falls.
• Storing the output in your own Azure Data Lake Storage Gen2, where other Azure services can use it.
• Larger volumes and ETL at scale with Premium.

Gen1 or Gen2?

Microsoft now describes the original Power BI dataflows, Gen1, as legacy: they will not receive new feature investment. For Premium customers with Fabric access, Dataflow Gen2 is the recommended path; Pro and Premium per user customers can continue to use Gen1 while guidance for their scenarios evolves.

Both versions are built with Power Query. The main practical difference is where the output goes. Gen1 stores its results in its own internal storage, read through the Dataflow connector, while Gen2 can write to different destinations, and adds autosave, background publishing and better monitoring (Microsoft Learn: Gen1 and Gen2). If your organisation has Fabric, start new work in Gen2; if not, Gen1 remains usable, with the expectation of moving later.

When a dataflow is worth it

Dataflows add a moving part: a separate object with its own refresh, owner and failure modes. They pay for themselves when:

• Several semantic models need the same tables, especially shared dimensions such as date, customer and product. Microsoft's adoption guidance recommends exactly this for managed self-service: centralise preparation logic and share commonly used tables with many model authors (Microsoft Learn: content ownership).
• Source systems should not be queried by every report author, for security or load reasons.
• Preparation logic needs a single owner, so a definition such as "active customer" is changed in one place.

They add little when a single report uses data that no other model needs, or when the transformations are specific to one analysis. Keep those in the report's own Power Query.

Creating a dataflow

1. In a workspace in the Power BI service, create a new dataflow.
2. Connect to a source; for on-premises sources, select the gateway.
3. Shape the data in Power Query Online, as you would in Desktop.
4. Save, then refresh it once and set a refresh schedule from the workspace.
5. In Power BI Desktop, use Get data to connect to the dataflow and load its tables into your semantic model.

If you already have queries in Desktop, you can often paste the M code into a blank query in the dataflow editor, then point your semantic models at the dataflow instead. The Power Query tutorial covers the transformation skills themselves.

Refresh happens twice

A dataflow and the semantic models that use it refresh separately. If both are scheduled at 6:00, the model may load yesterday's dataflow output. Schedule the dataflow first and the models after it, with enough gap for the dataflow to finish, or trigger model refreshes after the dataflow completes. Refresh limits, time-outs and failure notifications work much as for semantic models; Power BI data refresh covers them, and the gateway guide covers on-premises sources.

Design habits that keep dataflows useful

• One dataflow per subject, such as sales or HR, rather than one giant dataflow for everything.
• Clean, analysis-ready output: friendly column names and correct data types, so every model author does less work. Microsoft's guidance makes the same point.
• Dimensions and facts shaped for a star schema, so models can relate them directly; star schema in Power BI covers the design.
• A named owner and a description on each dataflow, so users know who to ask.
• Endorse trusted dataflows, so authors can tell a certified shared table from someone's experiment.

Common pitfalls

• Refresh order, covered above, is the most frequent cause of stale numbers.
• Duplicated logic: a dataflow that exists but that models do not use still leaves each report doing its own preparation. Migrate the models.
• Hidden dependencies: changing a dataflow's column name breaks every model that uses it. Treat its output as a contract and communicate changes.
• Building new work on Gen1 where Gen2 is available, which creates migration work later.

Where dataflows fit

Dataflows are the preparation layer of self-service BI in Power BI: a central team or experienced analyst prepares shared tables, and report authors build on them. Self-service analytics explains the organisational side of that arrangement.

Power Query transformation, data refresh and the Power BI service are part of the Power BI course.

Sources

• Introduction to dataflows and self-service data prep (legacy) (Microsoft Learn) — Microsoft Learn
• Differences between Dataflow Gen1 and Dataflow Gen2 (Microsoft Fabric) — Microsoft Learn
• Microsoft Fabric adoption roadmap: content ownership and management (Microsoft Learn) — Microsoft Learn