Refreshing Power BI Semantic Models From The Mobile App - What It Does And Does Not Do

Here is a scenario I have seen play out more times than I can count. An executive is at the airport, opens a Power BI report on their phone, and the number looks wrong. Old, really. They pull down to refresh, it does something, and the number stays the same. By the time they land they have sent a slightly annoyed message asking why the dashboard is broken. It is not broken. But the gap between what they think "refresh" means on their phone and what it actually does is doing real damage to their trust in the reporting.

This is one of those small features that looks trivial and causes an outsized amount of confusion. So it is worth being precise about what refreshing a semantic model from the Power BI mobile apps actually does. Microsoft's documentation on refreshing in the mobile apps covers the mechanics. I want to cover the mental model, because that is where people go wrong, and it is usually the people who matter most in the room.

The two different meanings of "refresh"

The core problem is that "refresh" means two completely different things in Power BI, and the mobile app blurs the line between them.

The first meaning is refresh the visuals. This is what the pull-to-refresh gesture in the mobile app does. It goes back to the semantic model, the thing formerly called a dataset, and re-queries it to redraw the report with whatever data is currently sitting in that model. If someone changed a filter, or the underlying model got refreshed on the server five minutes ago, pulling down on your phone will show you that newer state. It refreshes the report against the model.

The second meaning is refresh the data in the model itself. This is the scheduled overnight job that reaches out to your Azure SQL database or your warehouse or your Excel file, pulls in the latest source data, and updates the model. That is data refresh, and for an import-mode model it is what actually makes the numbers current.

Here is the catch that trips everyone up. If your model was last refreshed at 3am and it is now 2pm, pulling down on your phone will faithfully re-query the model and show you the exact same 3am numbers, because the model has not changed since 3am. The gesture did its job perfectly. The data is just as stale as it was, because the phone gesture never touched the source data at all. The executive at the airport is not looking at a broken report. They are looking at data that is eleven hours old, and no amount of pulling down on the screen will change that, because that is not what the gesture does.

Why this matters more than it sounds

You might read that and think it is a minor bit of pedantry. It is not, and here is why. The people most likely to consume reports primarily on their phone are often the most senior people in the organisation. They are also the least likely to have patience for a caveat about refresh semantics. If they lose confidence in the numbers, the whole reporting investment takes a hit, and it takes a hit at exactly the level where budgets get decided.

So getting this right is not really a technical problem, it is an expectation-setting problem. The technology behaves consistently. The human sitting on the plane has the wrong model in their head. Part of doing Power BI well is closing that gap deliberately rather than hoping nobody notices, and it is one of the less glamorous things our Power BI consultants end up sorting out on almost every engagement.

Import versus DirectQuery changes the whole story

Whether the mobile refresh gesture gives people fresh data depends entirely on how the model was built, and this is the lever most people do not realise they can pull.

If the model is import mode, the data is a snapshot taken at the last scheduled refresh. Pulling down on the phone shows you that snapshot, full stop. To get genuinely current numbers, the scheduled refresh has to run, and that happens on Microsoft's servers on the schedule you set, not when someone taps their screen.

If the model is DirectQuery, the story is different. There is no stored snapshot. Every query goes live to the source. So when someone pulls down to refresh on their phone, the visuals re-query the source and they genuinely do see current data. That sounds like the answer to everything until you remember what DirectQuery costs you: every phone refresh fires live queries at your database, and if your source cannot handle interactive load, you have traded stale-data complaints for slow-report complaints.

There is no free lunch here. My honest advice, after years of this, is that import mode with a sensible refresh schedule is right for the large majority of reporting, and the fix for the airport problem is almost never "switch to DirectQuery." It is "refresh the model often enough that stale never becomes a story," combined with actually telling people how fresh the data is. We dig into this import-versus-DirectQuery trade-off in more detail in our work connecting reports to live data, and it is one of the most consequential design decisions in any Power BI build.

The simplest fix nobody uses

Want to know the single most effective thing you can do about all of this? Put the last refresh time on the report.

Add a small piece of text to the report canvas that displays when the model was last refreshed. It is a tiny bit of work, it shows up on the phone just like it does on the desktop, and it quietly answers the question before anyone has to ask it. When the executive at the airport sees "Data as at 3:00am, 3 August" sitting in the corner of the report, they know exactly what they are looking at. No message to the BI team, no dented trust, no pulling down on the screen wondering why nothing changes.

I am always slightly surprised how few reports have this. It is the cheapest confidence-builder in the entire toolkit and it addresses the mobile refresh confusion more effectively than any amount of explaining the difference between visual refresh and data refresh. Show people the timestamp and most of the problem evaporates.

A few practical things about the mobile apps

Beyond the big conceptual point, a handful of practical notes from using these apps in anger.

The pull-to-refresh gesture is the standard way to refresh visuals in the mobile apps, and it works the way you would expect a mobile gesture to work. It is re-querying the model, so if the model genuinely has newer data than what is on your screen, you will get it. That covers cases like someone else having triggered a refresh, or a colleague changing something, while you had the report open.

Connectivity matters in a way it does not on the desktop. These are people on phones, often on patchy mobile networks. A refresh that would be instant on the office wifi can stall on a train. That is worth remembering when someone reports the app being slow: sometimes the answer is the model design, and sometimes it is simply that they were in a tunnel.

And set expectations with the actual humans who use the reports on their phones. A two-line explanation to your executive team about what the refresh gesture does, and pointing them at the timestamp on the report, will save everyone a lot of back and forth. This is exactly the kind of adoption detail that determines whether a reporting rollout actually sticks, and it is a big part of what our broader Microsoft Fabric consulting work covers, since the whole platform shares the same model underneath.

What good looks like

When we set this up properly, the pattern is consistent. The model refreshes on a schedule that matches how fresh the data genuinely needs to be. Every report carries a visible last-refreshed timestamp so nobody has to guess. The people who consume reports on their phones understand, in plain language, that pulling down refreshes their view of the model rather than reaching all the way back to the source. And import versus DirectQuery is a decision made on purpose rather than by default.

That is most of it. The mobile refresh feature itself is fine and does exactly what it says. The trouble is always the gap between what it does and what people assume it does, and closing that gap is cheap if you do it deliberately and expensive if you leave it to chance.

If your team lives in the Power BI mobile apps and you keep fielding "why is this number old" questions, that is a solvable problem and usually not the one people think it is. Have a look at our data and analytics services or just get in touch and we will take a look at how your reports are set up.