Refresh a Power BI Semantic Model From a Cloud Desktop File - How OneDrive Refresh Actually Works

Here is a scenario I have watched play out more than once. Someone builds a Power BI report, publishes it to the service, and then keeps tweaking the .pbix file on their desktop. A week later the report in the service is stale, nobody can work out why, and the person who built it has moved on. The fix they needed was there the whole time, sitting in a feature most people do not know exists: refreshing the semantic model from a Power BI Desktop file stored in the cloud.

When your .pbix lives in OneDrive for Business or a SharePoint document library, the Power BI service can watch that file and pull changes from it automatically. Save an updated version to OneDrive, and the service notices, and the semantic model and reports in the workspace update to match. No manual republish. It closes the gap between "the file on my machine" and "the report everyone looks at," and that gap is the source of a surprising amount of confusion in reporting teams.

I want to explain what this actually does, because it is easy to misunderstand, and the misunderstanding leads to people expecting the wrong thing. Microsoft's documentation on refreshing from a cloud Desktop file has the reference detail. This is the working version, with the traps.

Two different things both called "refresh"

The word refresh in Power BI means two completely different things, and conflating them is where most of the trouble starts.

Data refresh is pulling the latest rows from your source. Your model connects to a SQL database or a warehouse, and data refresh reruns the queries so the numbers are current. This is the refresh everyone thinks of.

Metadata refresh from a OneDrive file is different. This is the service noticing that the .pbix file itself changed, and syncing the model structure, the measures, the report layout, the visuals, to match the new file. It is about the design of the report, not the freshness of the data.

They are related but separate. The OneDrive sync keeps the model definition aligned with your file. Scheduled data refresh keeps the numbers aligned with your source. You usually want both, and you set them up separately. When someone says "my report is out of date," the first question is always which of these two they actually mean, because the fixes are nothing alike.

How the OneDrive sync works

When you store a .pbix in OneDrive for Business or a SharePoint document library and connect it to a workspace, Power BI checks the file roughly every hour for changes. If it sees a newer version, it pulls the updated model and report into the service.

So the workflow becomes: edit in Power BI Desktop, save to the OneDrive-synced folder, and within about an hour the published version catches up on its own. If you have added a measure or reworked a chart, that change flows through without you touching the service. For a team where one person owns a report's design, this is the tidy way to keep the published version honest.

The important detail is that OneDrive is the source of truth in this setup. The service is following the file. That is a mental shift from the usual publish model, where you push from Desktop to the service and the service holds the copy. Here the file leads and the service follows.

Where this genuinely helps

Single-owner reports that change often. If you are actively iterating on a report's design, the OneDrive sync means you save and move on, instead of remembering to republish every time. For a report in its first few weeks of life, where the layout is still settling, that removes a whole category of "did I remember to push it" errors.

Keeping a team on one version. When the .pbix lives in a shared SharePoint library rather than on someone's laptop, the file is not trapped on a machine nobody else can reach. The report survives the person going on leave or leaving the company. I have seen too many businesses where the only copy of a critical report was on a departed employee's device, and the OneDrive approach is a straightforward guard against that.

A clearer audit trail. SharePoint and OneDrive version the file, so you can see who changed what and roll back if a change broke something. That history does not exist in the same way when the file bounces between desktops and the service.

This kind of governance is a real part of what we sort out in Power BI consulting work, because a reporting estate without a clear source of truth becomes impossible to maintain once it grows past a few reports.

Where it catches people out

Now the honest part, because this feature has sharp edges.

It is not instant. The check runs roughly hourly, so a change you save might take up to an hour to appear in the service. People expect a live sync and then panic when the report has not updated two minutes after they saved. It will get there. It is just not immediate. If you need it now, you can trigger it manually, but the automatic cycle is not real-time.

Metadata sync is not data refresh. This trips up nearly everyone. The OneDrive sync updates the model and report design. It does not, by itself, go and pull fresh data from your database. If your numbers are stale, you probably need scheduled data refresh set up, which is a separate configuration with its own gateway and credential requirements. I have had clients convinced the OneDrive sync was broken when in fact it was working perfectly, syncing the design, while their data refresh was never configured at all.

The gateway question. If your model imports from an on-premises source, you still need an on-premises data gateway for the data refresh, regardless of the OneDrive setup. The cloud file sync and the gateway are unrelated pieces. One handles the file, the other handles the data connection. Getting the file into OneDrive does not remove the gateway requirement.

Conflicts and multiple editors. OneDrive is not built for two people editing the same .pbix at once. Power BI Desktop files are large binary files, not something that merges cleanly. If two people open and save the same file, someone's work gets overwritten. This works best with one clear owner per file. If you have a team all wanting to edit, you need a different approach, and honestly for shared development you are better off looking at proper deployment pipelines than trying to make OneDrive behave like source control.

Large files and sync reliability. Big .pbix files can be slow to sync, and I have seen the odd case where a large model did not pick up changes cleanly. For heavy models, keep an eye on it rather than assuming it just works.

How I usually set it up

For a small team with one report owner, storing the .pbix in a dedicated SharePoint library and letting the service sync from it is a sensible, low-friction setup. Pair it with scheduled data refresh so both the design and the numbers stay current, and you have a report that mostly looks after itself.

For anything bigger, with multiple developers or a formal path from development to production, I move away from relying on the OneDrive sync as the mechanism and set up proper deployment pipelines, where you promote content through stages with control over what lands in production and when. The OneDrive approach is great for its size. It is not a substitute for real release management once you are past a handful of people.

The point of both is the same thing: there should be one obvious source of truth for every report, and the published version should never quietly drift away from it. Most reporting messes I get called into come down to nobody being able to say which copy is the real one.

My rule of thumb

Use OneDrive-based refresh when a report has a single owner and you want the published version to track the file without ceremony. Understand that it syncs design, not data, and set up scheduled data refresh separately for the numbers. And the moment you have multiple people editing or a genuine production environment to protect, graduate to deployment pipelines rather than stretching OneDrive past what it was built for.

This is the plumbing that decides whether a reporting estate stays maintainable or turns into a pile of orphaned files, and it usually sits inside a broader business intelligence and Microsoft Fabric platform. If your Power BI reports have drifted out of sync, or nobody can say which .pbix is the real one anymore, take a look at our services or get in touch.