Configuring and Consuming Power BI Dataflows (Legacy) - What Still Holds Up

Walk into most Australian organisations that have been using Power BI for a few years and you will find the same quiet pattern. The same transformation logic, copied into five different reports, drifting slightly out of sync each time someone tweaks one and forgets the others. One analyst has a slightly different definition of "active customer" baked into their queries than the person two desks over, and nobody notices until two reports show different numbers in the same meeting and the whole thing grinds to a halt while people argue about whose figure is right.

Dataflows were Microsoft's answer to that mess, and even though the branding has moved on to Fabric, the legacy dataflow is still running in a lot of places and still doing useful work. Microsoft's guide to configuring and consuming a dataflow covers the how. I want to talk about what they are actually good for, where they fall down, and how to think about them now that the newer options exist, because a lot of teams are sitting on legacy dataflows wondering whether to leave them alone or move on.

What a dataflow actually is

Strip away the marketing and a dataflow is Power Query that lives in the service instead of inside a single report. You build your queries with the same familiar interface you use in Power BI Desktop, the same connectors, the same transformation steps, except the result gets stored centrally and can be reused by many reports rather than being trapped inside one file.

The output lands in storage as a set of tables, and any report in the workspace can connect to it as a source. The point is reuse. You define "here is how we clean and shape our customer data" once, in one place, and every report that needs clean customer data connects to that dataflow instead of each analyst rebuilding the same steps. When the definition changes, it changes once, and everything downstream picks up the new version on the next refresh.

Why teams still run them

The value is genuinely real, and it is worth being clear about it because "legacy" makes people assume "bad".

The first win is a single definition of your logic. When "net revenue" or "active account" is defined in a dataflow, everyone consuming it gets the same number by construction. This kills off a specific and exhausting category of meeting, the one where two people have different totals and nobody can work out why. If both reports pull from the same dataflow, they cannot disagree, and that alone justifies the effort for a lot of teams.

The second is taking load off source systems. If ten reports each hit your production database to pull and transform the same customer table, that is ten hits on a system that probably has a day job. A dataflow pulls once, does the work once, and the reports read from the prepared result. Your database administrator will thank you, and your refreshes stop competing with each other for the same source.

The third is that it lets less technical people reuse solid data prep without having to understand it. An analyst who is great with visuals but shaky with Power Query can connect to a well-built dataflow and get clean, correct data without needing to build the transformations themselves. That separation of "someone builds the plumbing, someone else builds the reports" is a healthy division of labour that scales far better than everyone doing everything.

Configuring one without regret

A few things I always tell teams setting these up.

Keep each dataflow focused. It is tempting to build one giant dataflow that prepares everything, but you end up with a slow, fragile thing where a change to one table forces a full refresh of the lot. Smaller, purpose-built dataflows refresh faster and fail in more contained ways. If sales prep and HR prep have nothing to do with each other, they do not belong in the same dataflow.

Think about the refresh schedule properly. A dataflow that feeds twenty reports needs to finish refreshing before those reports refresh, or they read yesterday's data. Sequencing matters, and the legacy tooling gives you less orchestration help than the newer options, so you have to be deliberate about the timing. Get this wrong and you get the worst kind of bug, where the data is not broken, just quietly stale.

Use computed and linked entities carefully. Referencing one dataflow from another to build layered transformations is powerful, and it keeps things clean, but it also builds dependency chains that can get hard to reason about. When a refresh fails three layers down, tracing why takes patience. Layer deliberately, document the dependencies, and do not build a tower you cannot explain to the next person.

Where it falls down

Now the honest part, because I would not put a client on legacy dataflows today without a conversation first.

The word "legacy" is doing real work in the name. Microsoft's direction is Fabric, and Fabric's Dataflow Gen2 and the broader data engineering tools are where the investment is going. Legacy dataflows still function, they are not being switched off tomorrow, but they are not getting better either. If you are starting fresh, you should be looking at the newer options rather than building new legacy dataflows, because you are choosing a path that has already been superseded.

Performance can disappoint at scale. Dataflows are Power Query under the hood, and Power Query is a capable tool that was not built to be a heavy-duty data engineering engine. For moderate volumes they are fine. Push very large data through complex transformations and you will feel the limits, and you will start wishing you had a proper pipeline. There is a size beyond which a dataflow is the wrong tool, and knowing where that line sits is most of the skill.

Refresh times and reliability need watching. As dataflows grow and dependencies stack up, refreshes get slower and there are more places for a failure to hide. The monitoring and error handling in the legacy experience is thinner than what you get with the newer tooling, so you end up doing more of the babysitting yourself.

And there is a real risk of a dataflow becoming a black box nobody understands. The person who built it leaves, the logic is complex, and now you have a critical piece of your reporting that everyone depends on and nobody can safely change. That is not unique to dataflows, but the reuse that makes them valuable also makes them high-stakes, because a mistake in a shared dataflow ripples out to everything at once.

How to think about it now

If you already run legacy dataflows and they work, there is no need to panic or rip them out. They still do their job. But do not build a big new investment on them, and have a plan for where you move as Fabric matures. If you are starting now, look at the current tooling first. The concept of centralising your data prep and reusing it is completely sound and more relevant than ever. It is only the specific legacy implementation that has been overtaken.

This is exactly the kind of decision our Microsoft Fabric consultants and Power BI consultants get pulled into all the time. Should this stay a legacy dataflow, move to Dataflow Gen2, or become a proper pipeline? The answer depends on your data volumes, your team's skills, and where you are heading, not on a blanket rule. Getting the data foundation right is also usually the first real step in the broader data and AI work we do, because clever things built on messy, duplicated, inconsistent data tend to produce clever-looking nonsense.

If you have a tangle of duplicated report logic, or legacy dataflows you are not sure what to do with, that is squarely the sort of thing we sort out. Take a look at our services or get in touch and we will help you work out the sensible path.