Refreshing a Power BI Semantic Model From a CSV File on OneDrive - The Setup and the Gotchas

Not every data pipeline needs to be a proper pipeline. A surprising amount of business reporting in Australia still runs off a CSV that somebody exports from a system once a week and drops in a folder. That is not a failure of engineering, it is just what a lot of real workflows look like, and pretending otherwise is how consultants end up over-building things nobody asked for. So when a client says "we have a CSV that updates and we want the report to follow it", the neat answer is often to put that CSV in OneDrive and let Power BI refresh from it. The Microsoft documentation walks through the steps. I want to give you the practical read: how it works, when it is the right tool, and the specific ways it trips people up.

What this actually does

The idea is simple. You have a CSV file. You put it in OneDrive for Business, or a SharePoint document library, which under the hood is the same thing. You connect a Power BI semantic model to that file. From then on, Power BI keeps the model in sync with the file, so when the CSV changes, the report catches up without anyone touching Power BI.

The important detail people miss is that OneDrive-hosted files get a different refresh behaviour to a normal scheduled refresh. Power BI polls the file roughly every hour and picks up changes automatically, on top of whatever scheduled refresh you also configure. So you get a near-automatic sync as long as the file keeps living in the same place with the same name and the same shape. That last clause is doing a lot of work, and it is where most of the trouble comes from later.

When this is the right call

I am genuinely fond of this approach for the right situation, because it matches effort to need. If you have a small-to-medium dataset that arrives as a file on a regular cadence, and the person producing that file is not going to build you an API, this is the pragmatic answer. A weekly sales extract. A monthly finance export. A list a team maintains by hand in a spreadsheet they save as CSV. For all of those, standing up a database or a proper ingestion pipeline would be absurd overkill.

It is also genuinely good for the "citizen" end of things. A team owns their data in a file, they update the file, the report updates. No data team in the loop, no tickets, no waiting. For the right dataset that is exactly the self-serve setup you want, and it keeps the data team free for the work that actually needs them.

The other quiet advantage is that OneDrive gives you versioning for free. If someone breaks the file, you can roll back to a previous version, which is a safety net you do not get with a file sitting on someone's laptop. That alone makes OneDrive a better home for these files than the local drives and email attachments they usually live on.

The gotchas, because there are a few

Here is where experience earns its keep, because the setup is easy and the failure modes are not obvious until they bite you.

The big one is schema stability. Power BI connects to the file expecting a particular set of columns in a particular order. The moment someone adds a column, renames a header, or reorders things, the refresh can break or, worse, silently load the wrong data into the wrong place. And the person editing the CSV usually has no idea a report depends on the exact shape of their file. They just added a helpful new column. Now your report is broken and nobody knows why. This is the single most common way these setups fall over, and it is a people problem as much as a technical one. Whoever owns the file needs to know it is load-bearing.

CSV type handling is the second trap. CSVs have no types. Everything is text until something decides otherwise, and Power BI does the deciding. It infers whether a column is a number, a date, or text, and its inference is not always right. Australian date formats are a classic offender: a date like 03/04/2026 is the third of April to us and the fourth of March to the parser if it defaults to US format, and you will not always notice the flip until a report looks quietly wrong. Leading zeros on product codes get stripped because Power BI decides the column is numeric. You have to set the types explicitly in Power Query rather than trusting the auto-detection, or you inherit a subtle data-quality problem that surfaces at the worst time.

Encoding is the third one, and it is boring right up until it ruins your afternoon. If the CSV is saved with a different encoding than Power BI expects, special characters turn to gibberish. Names with accents, currency symbols, the occasional stray character in an address field. Pin the encoding in the query rather than hoping the file is always saved the same way.

And then there is the refresh timing confusion. People assume OneDrive files refresh instantly. They do not. The automatic pickup is roughly hourly, so if someone updates the file and immediately checks the report, the change is not there yet, and you get a "the refresh is broken" panic that is really just impatience. Set that expectation up front and you save yourself a support call.

Where it stops being the right tool

I would be doing you a disservice if I did not say where this approach runs out of road, because I have seen people push it well past its sensible limit.

CSV-on-OneDrive is a small-data solution. When the file gets large, refreshes get slow and flaky, and you have outgrown it. When you need proper data quality controls, validation, or a real audit trail of what changed and when, a file in a folder is not enough. When multiple sources need combining, or the logic gets complicated, you have crossed into territory that wants an actual pipeline. Microsoft Fabric and tools like Dataflows or Data Factory exist for exactly this step up, and knowing when to make that move is part of the job. We do a lot of Microsoft Fabric consulting that starts with someone realising their trusty CSV setup has quietly become business-critical and is now too fragile to leave as-is.

The honest framing I give clients is this: CSV-on-OneDrive is the right answer for a real and common situation, and the wrong answer the moment the data matters enough that a broken refresh would actually hurt. The tell is usually the conversation about who is allowed to edit the file. If the answer is "anyone" and the report is important, you have a problem waiting to happen.

How to set it up so it lasts

If you are going to do this, do it deliberately. Put the file somewhere controlled, ideally a SharePoint library rather than one person's personal OneDrive, so it survives that person leaving or reorganising their folders. Lock down who can edit it. Document the expected schema somewhere the file owner will actually see it. Set explicit column types in Power Query instead of trusting auto-detection. Pin the encoding. And tell everyone involved that the automatic refresh is hourly, not instant, so nobody panics.

Get those basics right and this is a lovely, low-maintenance setup that quietly does its job for years. Skip them and it is a fragile thing that breaks the first time someone touches the file, at which point it becomes an emergency because by then a report someone relies on depends on it.

The broader point, and the one worth carrying beyond this specific feature, is that good data engineering is about matching the tool to the actual need. Not everything deserves a pipeline. A CSV in OneDrive is a legitimate, sensible architecture for the right dataset, and reaching for something heavier would waste money and time. The skill is knowing which situation you are in, and being honest when the cheap-and-cheerful option has quietly grown into something that needs a proper foundation.

If you have a pile of these file-based reports and you are not sure which ones have outgrown the approach, or you want help drawing the line between "leave it simple" and "this needs a real pipeline now", that is a conversation we have often. Have a look at our business AI and data services or get in touch and we will work through it with you.