Connecting Power BI Desktop to Power Platform Dataflows - The Legacy Connector Explained

Every so often I open a client's Power BI Desktop file and find a data source I have to squint at. It says Power Platform dataflows, not Power BI dataflows, and the two are close enough in name that people genuinely don't know which one they are using or why. Then Microsoft slapped a "legacy" label on the connector, and now there is a second question stacked on top of the first: is this thing about to stop working?

Let me untangle it, because the confusion here is understandable and the answer actually matters for how you plan the next couple of years. Microsoft's documentation on connecting to Power Platform dataflows in Desktop covers the connector itself. What it doesn't do is explain the family tree of dataflows or tell you what "legacy" should mean for your decisions, and that is the part worth getting right.

First, the naming, because it is genuinely confusing

Microsoft has shipped several things all called "dataflows", and the names are similar enough to cause real problems. Here is the short version.

Power BI dataflows are the self-service data prep feature that lives inside Power BI, storing their output in Power BI's own storage. You build them in the Power BI service using Power Query online, and they feed your semantic models.

Power Platform dataflows are a close cousin that live in the wider Power Platform world, often associated with Dataverse and the Power Apps side of the fence. Same Power Query engine underneath, similar authoring experience, but they belong to Power Platform rather than to Power BI specifically. They are frequently used to load and shape data sitting in Dataverse.

The connector this article is about is the one in Power BI Desktop that reaches out and pulls data from those Power Platform dataflows. So you have prepared data over in Power Platform, and you want to consume it in a Power BI report. That connector is the bridge. And it is the bridge that now carries the legacy label.

What the connector does and why teams reached for it

The appeal was always reuse. If your organisation had already built dataflows in the Power Platform, cleaning and shaping data in one place, it felt wasteful to redo that work inside Power BI. The connector let you skip the duplication: connect Power BI Desktop straight to the existing Power Platform dataflow, pull the shaped output, and build your report on data that had already been prepared once.

For businesses that lived heavily in the Power Platform and Dynamics world, this made a lot of sense. The data prep logic sat with the platform that owned the data, and Power BI was just the reporting layer on top. One place to fix a transformation, many places to consume it. Good instinct, and one we still encourage in principle, even if the specific plumbing is changing.

What "legacy" actually means here

This is where I want to be careful, because "legacy" makes people panic and the panic is usually unwarranted in the short term.

Legacy, in Microsoft's world, almost never means "switched off next Tuesday". It means the connector is no longer where the investment is going. It still works, existing reports keep refreshing, nothing breaks overnight. What it signals is direction. Microsoft would rather you moved onto the newer paths, and the legacy label is the gentle nudge that this connector is a dead end for new development even if it is a functioning one today.

So the honest read: if you have existing reports using this connector, you do not need to drop everything and rip them out. They will keep working for a good while. But you should stop building new things on it, and you should have a plan for where the data prep moves next, because "legacy" is Microsoft telling you the road ahead is somewhere else.

The somewhere else, for most teams, is Fabric. Microsoft Fabric brings dataflows Gen2, OneLake, and a more unified data platform, and that is clearly where the modern data prep story is headed. If you are making a fresh decision about where to shape your data, that is the direction to look, not the legacy connector. Working out how a Power Platform and Dataverse setup maps onto Fabric is a common piece of our Microsoft Fabric consulting, because the migration path is rarely a straight swap.

The traps I see with this connector

A few things bite people specifically with the Power Platform dataflows connector, and they are worth naming.

The first is the credentials and refresh story, which is the usual Power BI headache wearing slightly different clothes. It works in Desktop because you are authenticated as yourself and you have access to the Power Platform environment. Then you publish, the scheduled refresh runs when nobody is logged in, and the service needs its own credentials to reach the dataflow. If those aren't set up properly, the report refreshes fine on your machine and dies in the service, and the error message rarely points straight at the cause. This is the single most common failure I see across every kind of Power BI data source, and this connector is no exception.

The second is the confusion between the two dataflow types when someone inherits a report. A new team member opens the file, sees "dataflows", assumes it is a Power BI dataflow, goes looking for it in the wrong place, and can't find it. Document which dataflow world your data actually comes from. It sounds trivial. It saves an afternoon.

The third is the temptation to keep building on it because it already works. This is the real risk of legacy technology, it functions well enough that inertia keeps you there, and then a few years pass and you are the last team on a connector nobody supports while everyone else moved to Fabric. Working is not the same as future-proof.

What I would actually do

If you are starting fresh and have no dataflows yet, don't reach for this legacy connector at all. Look at where Fabric wants you to prepare data and build there. You will be on the supported path from day one, which is worth a lot.

If you have existing reports on the connector, take stock rather than react. Note which reports use it, confirm their refreshes are healthy and the service credentials are sound, and put "migrate off the legacy dataflows connector" on the roadmap as a deliberate piece of work rather than an emergency. There is no fire. There is a direction, and you want to be moving with it rather than against it. Sorting the reporting layer on top of all this is squarely what our Power BI consultants help with, especially where a business has one foot in Power Platform and one in Power BI.

If you are somewhere in between, mid-build, half committed, this is a good moment to pause and decide deliberately rather than let the legacy connector become the default by accident. The worst outcome is drifting into a dependency on a fading connector because it was the path of least resistance in the moment.

None of this is dramatic. Dataflows, in all their confusingly named varieties, are a good idea: prepare your data once, consume it many times. The specific tool for doing that is shifting toward Fabric, and the Power Platform dataflows connector in Desktop is one of the older bridges being quietly retired. Know which dataflow you are on, keep the existing ones healthy, and point new work at where the platform is going.

If you would like a hand working out how your Power Platform, Dataverse and Power BI setup should evolve as Fabric matures, that is exactly the kind of untangling we do. Have a look at our data and analytics services, or just get in touch and we will take a look at what you have got.