Power BI - Managing Which Queries Refresh and Which Do Not

Slow refreshes are one of the most common complaints I hear about Power BI, and a surprising number of them come down to a setting most report authors have never touched. Every query in your model has a flag that decides whether it runs during a refresh, and by default they all do. When someone tells me their model takes forty minutes to refresh and half of it is staging queries and reference tables that never change, this setting is usually the first place I look.

It is a small thing that has a big effect on refresh time, gateway load, and how much you annoy the source systems your queries hit. Worth understanding properly.

What the setting actually does

In Power Query, every query has an option called "Include in report refresh". You find it by right-clicking a query in the Power BI Desktop query list. When it is ticked, the query runs every time the model refreshes, in the service and in Desktop. When you untick it, the query is excluded from refresh, so it will not run on a scheduled refresh or a manual one.

The Microsoft documentation on managing query refresh lays out the mechanics. The practical point is this: a model with twenty queries does not have to run all twenty every refresh. Some of those queries are staging steps that feed other queries. Some are lookups against data that changes once a year. Making everything refresh on every cycle is the default, and the default is often wasteful.

There is a related visual cue worth knowing. Queries not loaded to the model show in italics in the query list, and disabling load is a separate thing from disabling refresh. The two get confused constantly, so it is worth being precise about which you mean.

Load versus refresh, because people mix them up

These are two different switches and the confusion causes real bugs.

"Enable load" controls whether a query's output becomes a table in your model. Turn it off and the query still exists and can feed other queries, but it does not create a table you can build visuals on. This is how staging queries work: they do the shaping, feed a downstream query, and never load as tables themselves.

"Include in report refresh" controls whether a query runs when the model refreshes. A query can be loaded but excluded from refresh, or refreshed but not loaded, or any combination.

Here is the trap. If you disable load on a query, Power BI also stops including it in refresh, which makes sense for a pure staging query. But people then assume the two settings are the same switch, and they are not. A query loaded to the model that you have manually excluded from refresh will keep serving whatever data it had at last refresh, indefinitely, and that is exactly the kind of silent staleness that makes someone stare at a report wondering why last week's numbers will not budge.

Where excluding refresh genuinely helps

A few patterns where I reach for this deliberately.

Static reference tables are the obvious one. A date table generated in Power Query, a mapping table of region codes, a list of public holidays: these do not change from refresh to refresh, or change so rarely that a manual refresh when they do is fine. Excluding them from the daily refresh trims time and takes load off wherever they come from.

Development and scratch queries are another. During build you often have queries you are experimenting with, or a heavy exploratory pull you do not want firing on every scheduled refresh in production. Excluding them keeps your refresh honest without you having to delete and rebuild work in progress.

Then there is the case of an expensive source you want to control. If one query hits a slow API or a database that groans under load, and its data only needs updating weekly while the rest of the model updates daily, excluding it from the daily cycle and refreshing it on its own schedule is a reasonable way to protect the source. It is a bit manual, but it beats hammering a system that was never built for frequent extracts.

Getting these decisions right across a real model is a chunk of what our Power BI consultants do when a client comes to us with refreshes that have crept past the point of being tolerable.

The honest limitations

I like this setting, but it is a blunt instrument and it is easy to misuse.

It is per query, all or nothing. You cannot say "refresh this query but only the new rows". That finer control is what incremental refresh is for, and the two solve different problems. If your issue is a fact table that grows every day and takes longer each time because it reloads history that never changes, include-in-refresh will not save you. You want incremental refresh, which partitions the data and only pulls the recent window. I have seen people toggle refresh flags trying to fix what was really an incremental refresh problem, and it just moves the pain around.

It is also easy to forget you did it. Six months later someone wonders why a table is stale, digs through the model, and finds a refresh flag turned off and forgotten. There is no big warning banner. My habit is to document any query I have deliberately excluded, right in the query name or a comment, so future me or the next consultant is not left guessing. A query called "Regions (manual refresh only)" tells the story in a way a silently unticked box never will.

And it does not reduce model size or query complexity, it just changes when queries run. If your refresh is slow because a transformation is doing something expensive, excluding other queries only hides the problem. The right fix is usually to look at the query folding and the transformations themselves, not to switch things off around them.

How I would approach a slow model

If you have a refresh that has become painful, the order I work through it is roughly this.

First, look at what is actually running. Open the model and check which queries are loaded and which are included in refresh. It is common to find staging queries or old experiments still firing. Clean those up first, it is free and often gets you a quick win.

Second, separate the truly static from the changing. Reference tables and generated tables that do not change get excluded from the regular refresh, with a note on why. That trims the cycle without touching your real data.

Third, and this is the bigger lever, look at whether your large fact tables should be on incremental refresh rather than full reload. That is where the serious time usually goes, and no amount of toggling refresh flags substitutes for it.

Managing which queries refresh is one of those quiet fundamentals that separates a model that scales from one that gets slower every month until someone dreads the refresh. It will not fix a badly modelled fact table, but combined with incremental refresh and a bit of discipline about what genuinely needs to run, it keeps refreshes fast and your source systems unbothered.

This kind of tuning tends to come up inside broader data and reporting work, which for us sits alongside our Microsoft Fabric consulting and the wider business intelligence engagements where a slow, brittle refresh is usually a symptom of a model that grew faster than anyone planned for.

If your Power BI refreshes have crept out of hand and you want someone to sort out what is actually going on, that is squarely the kind of thing we do. Have a look at what we offer, or get in touch and tell us where it hurts.

Reference: Manage query refresh in Power BI