Power BI Dataflows (Legacy) - The Considerations and Limitations Worth Knowing

There is a moment in almost every Power BI project where someone opens the workspace and finds a dataflow nobody remembers building. It refreshes on a schedule, three reports depend on it, and the person who set it up left eighteen months ago. Now the team wants to change something and they are nervous, because they do not know what will break. That scenario is where most conversations about dataflow limitations actually start, not in a planning meeting but in a slightly panicked "what is this thing and can we touch it" moment.

Dataflows are one of the more useful ideas in Power BI, and also one of the least understood. The legacy variety in particular carries a set of considerations and limits that are easy to miss until they bite you. Microsoft's documentation on dataflows features and limitations lists them out. What I want to do here is give you the version that matters in practice, the parts that actually change how you should build and what you should avoid.

What a dataflow is, quickly

A dataflow is Power Query running in the cloud instead of inside a single report. You build your transformations once, the cleaned result lands in storage, and any report can pull from it. The whole point is reuse. Build the logic for your cleaned customer table one time, and stop reimplementing the same joins and filters in a dozen separate files that quietly drift apart.

That reuse benefit is real, and I would say dataflows are underused across the Australian reporting estates we see. Most of the "why don't these two reports agree" problems come down to the same transformation being written slightly differently in five places. A dataflow fixes that at the source. So I am not here to talk you out of dataflows. I am here to make sure you go in knowing where the edges are, because the legacy ones have some sharp ones.

The refresh limits that catch people

The first thing that trips teams up is refresh. On shared capacity, legacy dataflows have real constraints on how long a refresh can run and how often you can schedule one. Push a dataflow to transform a genuinely large table with heavy Power Query steps, and you can hit a timeout partway through. The frustrating part is that it often works fine in testing with a small slice of data, then falls over three months later when the table has grown, and by then everyone has forgotten the dataflow even exists.

This is the classic trap. It is not that the limit is unreasonable. It is that the limit is invisible until you cross it, and you usually cross it at the worst possible time, in production, on a Monday, when a report the executive team relies on comes up empty. If your dataflow is doing heavy lifting on large volumes, you need to know your capacity's refresh boundaries before you build, not after your first failed run.

Query folding is doing more work than you think

Here is the one that separates a dataflow that scales from one that does not, and almost nobody checks it until performance falls apart.

When Power Query can push your transformation steps back to the source database as native SQL, that is query folding, and it is what keeps a dataflow fast. The source does the filtering and the aggregating close to the data, and only the trimmed result comes back. Break the fold, usually by adding a step Power Query cannot translate, and it has to pull the entire table into the dataflow engine and process it there. On a small table you never notice. On a large one it is the difference between a refresh that finishes in two minutes and one that times out.

The limitation people miss is that not every transformation folds, and the order of your steps matters. Do your filtering early while folding still works, and you send a small dataset downstream. Add a non-folding step too soon and everything after it processes the full table. This is the single most common cause of the slow, fragile dataflows I get called in to fix, and the fix is almost always reordering steps so the fold survives longer. Worth understanding before you build, painful to unpick after.

Storage, linked entities and the connections you cannot make

Legacy dataflows store their output in an underlying storage layer, and there are constraints on how dataflows reference each other. Linked entities, where one dataflow reads from another, come with rules about what can reference what across workspaces and capacity types. Computed entities, where a dataflow builds a new table from an existing dataflow's output, are a premium capability, not something you get on shared capacity.

The practical upshot is that people design an elegant chain of dataflows feeding into each other, then discover halfway through that the capacity they are on does not support the linking they planned. It is not a bug, it is a licensing and capacity boundary, but it feels like a wall when you hit it unexpectedly. If you are architecting anything beyond a single-layer dataflow, check what your capacity actually permits before you draw the diagram, because the gap between the free-tier behaviour and the premium behaviour is wide and it is exactly the kind of thing that stalls a project mid-build.

Data types, connectors and the small stuff that adds up

There is a long tail of smaller limitations that individually look minor and collectively shape what you can do. Some connectors that work in Power BI Desktop behave differently or are unavailable in the dataflow authoring experience. Certain data type handling differs from what you would get in a desktop model. Gateway configuration for on-premises sources adds its own set of considerations, and if your source sits behind a corporate firewall, which for a lot of Australian enterprises it does, the gateway setup is where a surprising amount of the effort goes.

None of these are dealbreakers on their own. Together they mean a dataflow is not simply "Power Query but in the cloud" with identical behaviour. It is close, but the differences are real, and assuming perfect parity is how you end up debugging something at five in the afternoon that worked fine on your laptop.

The word "legacy" is the biggest consideration

All of the above matters, but the label on the front matters more. Microsoft has been steadily moving its investment toward Fabric, and the modern answer to what dataflows do is increasingly built around Fabric dataflows Gen2, OneLake and Lakehouse storage rather than the older Power BI dataflow path. Legacy does not mean broken, and it does not mean switched off next week. It means the platform is moving, and the new capabilities are landing on the newer path.

So the honest consulting position in 2026 is this. If you have working legacy dataflows, do not rip them out in a panic. Legacy things run for years. Keep them, watch the refresh performance, and put a migration onto your roadmap as a planned move rather than a fire drill. If you are building something new and long-lived, look hard at the Fabric path first, because building fresh architecture on a feature Microsoft has already marked legacy is a decision your future self will quietly resent. Getting that call right is genuinely worth a proper conversation, and it is the sort of thing our Microsoft Fabric consultants sort out day to day, because the difference between a data platform that lasts five years and one you rebuild in eighteen months usually comes down to exactly this choice.

How I actually advise on this

Use dataflows for what they are good at, which is reuse and consistent transformation logic shared across reports. That value is real and holds up regardless of the legacy label. Just build them knowing the limits: mind your refresh boundaries, protect query folding, filter early, and check what your capacity actually supports before you design anything clever with linked or computed entities.

And be clear-eyed about direction. The problems dataflows solved have not gone anywhere, but the tooling has moved on, and any new build should lean toward where the investment is flowing. If your Power BI estate has grown into a tangle of dataflows nobody fully understands, or you are weighing up whether to modernise onto Fabric, that assessment work is exactly what we do. Have a look at our Power BI consultants or just get in touch, and we will take a proper look at what you have and where it should go next.

The considerations and limitations here are not reasons to avoid dataflows. They are the things that separate a dataflow you can rely on from one that becomes the mystery box nobody wants to touch. Know them going in, and you get the reuse benefit without inheriting the fragility.