Publishing Power BI Reports and Semantic Models - What the Publish Button Actually Does
There's a moment in every Power BI rollout where someone finishes a report in Desktop, hits Publish, and assumes the job is done. Then Monday comes around, the data is stale, someone else has overwritten their changes with an old copy from their desktop, and finance is making decisions off numbers from the previous week. The Publish button is the single most-clicked piece of the Power BI workflow at Australian businesses, and it's also the piece most people understand least.
Having cleaned up after this at organisations from ten-person firms to enterprises, I want to walk through what publishing actually does, because Microsoft's documentation on publishing semantic models and reports covers the mechanics well but the failure modes are things you mostly learn the hard way.
One button, two artefacts
When you publish a .pbix file from Power BI Desktop to the service, you don't get one thing in your workspace. You get two: a report and a semantic model. The report is the visual layer, the pages and charts. The semantic model is the data layer underneath - the tables, relationships, measures and queries you built in Desktop.
This split is the most important thing to understand about the whole platform, and it's invisible at the moment you publish. It matters because the two artefacts have separate lives in the service. The semantic model can be refreshed on a schedule, secured with row-level security, and - this is the big one - used by other reports. Someone else can build a completely different report on top of your published model without ever touching your .pbix file.
That's the mature pattern, and it's where we steer every client with more than a handful of report builders: a small number of well-built, certified semantic models, and many thin reports connecting to them live. The alternative, which is what organically grows if nobody intervenes, is forty .pbix files each with their own embedded copy of the same data model, each with slightly different DAX for "revenue", each refreshing separately against the same poor source database. If you've ever had two dashboards disagree about last month's sales in the same meeting, you've seen this disease. Publishing is where it starts, so publishing is where you fix it.
Where things land, and who can see them
Desktop asks you to pick a destination workspace. Two rules we give every client.
Never publish anything that matters to My Workspace. It's tied to your account, invisible to your colleagues, and effectively a black hole when you leave the company. It's fine for experiments. Anything another human depends on goes in a shared workspace, no exceptions. This sounds like obvious advice and yet every governance review we run finds business-critical reports living in the My Workspace of someone who resigned eight months ago.
And publishing is not sharing. Landing a report in a workspace makes it available to the people in that workspace, which is usually the builders, not the audience. Getting it to actual consumers properly means a Power BI app or explicit sharing, with licensing implications that depend on whether you're on Pro, Premium Per User or capacity. Plenty of "the report is broken" tickets are really "the report was never shared correctly".
The overwrite problem
Publish the same report to the same workspace again and the service replaces what's there. Both the report and the semantic model, silently, with whatever is in your local file. Desktop warns you it's going to do this, and everyone stops reading that dialog by their second week.
There is no undo. If a colleague made changes in the service, or published a newer version, and you push your stale local copy over the top, their work is gone. In teams with more than one person touching a report, this happens roughly once a quarter until someone imposes process.
The fixes, in ascending order of maturity: agree on a single owner per .pbix file and keep the master copy somewhere shared like SharePoint or OneDrive rather than on individual desktops. Better, adopt the PBIP project format and put reports in git, which turns "who changed what" from archaeology into a diff, and pairs with the deployment pipelines and git integration in Fabric for a genuinely professional dev-test-prod flow. That second path is more setup, and for a two-person analytics team the SharePoint-plus-discipline version is honestly fine. For anything bigger, source control stops being optional. This is the kind of workflow our Microsoft Fabric consultants set up regularly, and it's usually a week of effort that pays for itself the first time someone fat-fingers a publish.
Publishing is not refreshing
The data in a freshly published import-mode report is a snapshot from the last time you hit refresh in Desktop. It will sit there, ageing quietly, until you configure refresh in the service. This is the number one cause of the stale-data Monday I opened with.
After publishing, go to the semantic model's settings in the service and deal with two things. Credentials: the service needs its own connection to your data sources, separate from whatever authentication Desktop was using on your machine, and until you set them the model cannot refresh at all. And a gateway, if your data lives on-premises - a SQL Server in your server room, files on a network share. The service can't reach into your network without an on-premises data gateway installed and configured, and gateway setup is its own small project involving service accounts and firewall conversations with IT.
None of this is hard once you know it's there. All of it is invisible at publish time, which is why the docs page linked above is worth an actual read rather than a skim. Budget the gateway conversation early if you have on-prem sources; it has organisational lead time that the technical work doesn't.
A publishing checklist that holds up
The habits that separate tidy tenants from messy ones, condensed from a lot of engagements:
Before you publish, check which workspace you're aiming at - Desktop remembers your last choice, and muscle memory has sent plenty of draft reports into production workspaces. After you publish anything new, immediately configure credentials, refresh schedule and gateway, then run a manual refresh in the service and watch it succeed. Don't assume. A refresh that works in Desktop can fail in the service for credential, gateway, or privacy-level reasons, and you want to find that out now, not when the schedule silently fails at 6am.
Name semantic models like they'll be found in search by a stranger, because if you're doing shared models properly, they will be. "Sales Model FINAL v2 (copy)" is funny exactly once.
And decide who owns each published model. The service tracks an owner, refresh failures email that owner, and if that person leaves or moves on with no handover, refreshes break and nobody notices until the numbers are visibly wrong. Ownership isn't a metadata field, it's a job.
When to get help
Publishing one report is a five-minute task, and if that's your world, the checklist above is all you need. The consulting conversation starts when the pattern breaks down at scale: dozens of builders, models duplicated everywhere, no source control, refresh failures nobody owns, and executives who've stopped trusting the numbers. That's less a technical problem than a workflow one, and it's the bulk of what our Power BI consulting practice gets called in for. Usually the fix is some combination of shared semantic models, a proper workspace structure, deployment pipelines, and a short list of rules everyone actually follows.
If you're not sure how bad your situation is, a quick way to find out is to count how many different semantic models in your tenant contain a table called something like "Sales" or "Customers". If the answer makes you wince, get in touch - untangling that is genuinely satisfying work, and the payoff is the thing every business wants from BI in the first place: one version of the truth, refreshed on time, that people trust enough to act on.