Configuring Power BI Premium Dataflow Workloads - The Legacy Settings Still Worth Knowing

If your Power BI dataflows keep timing out or falling over on refresh, there is a decent chance nobody ever touched the workload configuration. It sits in the capacity settings, off to the side, quietly using whatever defaults Microsoft shipped years ago. For a lot of Australian organisations running on Premium capacity, those defaults are the reason a refresh that should take four minutes takes forty, or fails outright at 2am and nobody notices until the morning report is stale.

I want to talk about the legacy dataflow workload settings because they are still live in plenty of tenants, they still cause real problems, and the guidance around them is scattered. Microsoft has moved a lot of this into Fabric and the newer compute model, but if you are on a P-SKU that predates that shift, or an A-SKU running embedded workloads, you are still in the world of manually configured workloads. And the settings matter more than the interface lets on.

What the dataflow workload actually is

A quick grounding, because the terminology trips people up. In older Premium capacities, the capacity is carved into workloads: datasets, paginated reports, dataflows, AI. Each one gets a slice of the memory and can be turned on or off. The dataflow workload is the engine that runs your Power Query transformations when a dataflow refreshes, and it has its own set of knobs that are separate from everything else on the capacity.

The two settings people care about are the memory allocation, expressed as a percentage of the capacity's total memory, and the enhanced compute engine, which is the thing that decides whether your dataflows run as fast SQL-backed operations or slow row-by-row Power Query. Get those two right and a struggling dataflow environment often just starts behaving. Get them wrong and you throw hardware at a problem that was a configuration issue all along.

I have lost count of the number of times a client has been quoted an upgrade to a bigger capacity to fix refresh performance, when the real fix was a five-minute change to the workload settings. That is not a knock on anyone. The settings are buried, the documentation is dry, and the symptoms look exactly like "we need more grunt".

The enhanced compute engine is the setting that matters most

If you take one thing from this post, make it this. The enhanced compute engine changes how dataflows execute, and for anything beyond trivial transformations it is the difference between usable and painful.

Without it, a dataflow runs your Power Query steps more or less literally, pulling data through the mashup engine. With it on, Power BI loads the data into a managed SQL-based cache and runs transformations against that, which means folding, faster joins, and the ability for downstream dataflows to query the output efficiently. Computed entities and linked entities, where one dataflow references another, basically depend on it to perform.

The catch, and there is always a catch, is that the enhanced compute engine has three states in the legacy settings: on, off, and optimised. "Optimised" only spins the engine up when it decides the workload warrants it, which sounds sensible but in practice means small-but-important dataflows sometimes run cold and slow because the engine judged them not worth warming. For any capacity doing serious dataflow work, I set it to on, not optimised. You are paying for the capacity anyway. Let the engine run.

One honest caveat: turning it on consumes memory even when dataflows are idle, because the engine holds resources ready. On a small A-SKU or a busy P1 that is already tight, that overhead can bite other workloads. So it is not a free win. It is a trade you should make deliberately, ideally after looking at the Premium Capacity Metrics app to see what your headroom actually is.

Memory allocation and the refresh failures nobody explains

The second setting is the maximum memory percentage the dataflow workload can use. Default is often 20 percent. If you are refreshing large dataflows, or several at once, 20 percent of a P1's memory is not much, and the failures you get are ugly because they do not always say "out of memory". They say the refresh failed, or a mashup step errored, or a timeout, and you go hunting through the query when the actual problem was the workload hit its memory ceiling and got killed.

The fix is to raise the allocation, but you cannot just crank everything to 100 percent because the workloads share the same pool. If datasets and dataflows both want 80 percent, they fight, and now your reports are slow too. So it becomes a balancing exercise specific to how your capacity is used. A capacity that is mostly interactive reporting with a nightly dataflow refresh wants the dataflow allocation high overnight and modest during the day, which the static setting cannot do on its own. This is exactly the kind of thing our Power BI consultants end up sorting out on capacity health reviews, because the right number is never a number you can guess. It comes from watching the metrics.

My rule of thumb: if refreshes are failing and the metrics show memory pressure on the dataflow workload, bump the allocation in steps and watch what happens to the rest of the capacity. Do not make a big jump and walk away. These settings interact, and the second-order effect on datasets is easy to miss until someone complains their dashboard got sluggish.

The container size setting people forget

There is a less obvious control worth knowing about: the container size for the mashup engine, sometimes exposed as the maximum memory per query or container. When a single dataflow entity is genuinely large, a big fact table doing a heavy transformation, the constraint is not the whole workload's memory, it is how much any one container can grab. You can have plenty of workload memory free and still fail because one entity blew past its per-container limit.

Raising this helps big single-entity refreshes but reduces how many can run in parallel, because each one now reserves more. So a capacity doing lots of small dataflows wants smaller containers and more parallelism, while a capacity doing a few monsters wants bigger containers. Most teams never touch this and never need to, but when you hit a wall that the overall memory percentage does not explain, this is usually the culprit. It is the setting I check third, after the compute engine and the overall allocation.

Why Microsoft calls this "legacy" and what that means for you

The word legacy in the title is doing real work. Microsoft has moved dataflow compute into the Fabric model, where the mechanics are handled differently and a lot of this manual tuning goes away or changes shape. Fabric dataflows Gen2 run on a different compute architecture, and the capacity is measured in capacity units rather than the old workload-percentage carve-up.

So should you bother learning the legacy settings at all? If you are already on Fabric, mostly no, and I would spend your energy understanding the newer model instead. But a huge number of Australian organisations are still on classic Premium capacities, still running Gen1 dataflows in production, and still hitting exactly the problems above. Migration to Fabric is a project, not a toggle, and until you have done it these settings are the ones keeping your refreshes alive. Pretending they do not exist because a newer model shipped is how you end up with a stale executive dashboard and no idea why.

When we help clients plan that migration, the workload configuration is one of the first things we audit, because it tells you a lot about how the current environment is really being used. A capacity with the dataflow memory cranked to 60 percent and the compute engine forced on is telling you it has been fighting to keep large dataflows running, and that history should shape how you size the Fabric capacity you move to. That planning work sits inside our broader Microsoft Fabric consulting, and honestly the config review often pays for itself before the migration even starts.

What to watch out for

A few things that catch people, from the field.

Changes to workload settings do not always take effect instantly, and some require the capacity to essentially recycle the workload. Do not make a change, see no difference in the next thirty seconds, and conclude it did nothing. Give it a refresh cycle.

The Premium Capacity Metrics app is your source of truth, not the settings screen. The settings tell you what you allowed. The metrics tell you what actually happened. Every real diagnosis of a dataflow problem I have done started in the metrics app, not the config.

And do not tune in isolation. Dataflows share the capacity with datasets, paginated reports, and everything else. A change that fixes your dataflow refresh can quietly degrade interactive performance, and the person who feels that is a report user who has no idea you touched anything. Tell your stakeholders when you are changing capacity settings, and watch the whole picture afterwards.

The bottom line

The legacy Premium dataflow workload settings are unglamorous, half-hidden, and still responsible for a surprising share of the refresh failures and slow dataflows I see in Australian tenants. The enhanced compute engine is the big lever, the memory allocation is the one to tune carefully against the rest of the capacity, and the container size is the one you reach for when nothing else explains the failure. None of it is hard once you know it exists.

If your Power BI environment is on classic Premium and the dataflows are giving you grief, or you are weighing up the move to Fabric and want to do it with eyes open, that is work we do all the time. Have a look at our Power BI consulting, or just get in touch and we will take a look at your capacity.

Reference: Configure Power BI Premium dataflow workloads (legacy)