The first Power BI lesson ended with a working report on your machine — and a warning that sharing is where the free ride ends. This lesson is that second half: the Power BI Service (app.powerbi.com), where a report file becomes a living product — refreshed on schedule, opened in browsers and phones, and retired from the email-an-attachment lifestyle forever.

Publish, and what actually happens

In Desktop: Home → Publish, pick a workspace. Two things upload, and the distinction organises everything after: the dataset (your data model — the queries, the relationships) and the report (the visual pages pointed at it). One dataset can feed many reports — the same one-truth architecture as everything else on this course, and the reason you resist publishing six near-identical files.

Viewers get the report in a browser: interactive — cross-filtering, slicers, drill-down all work — but read-only, on always-current data. Nobody can sort your source sideways, and nobody is ever looking at last month’s copy.

Refresh: the plumbing that makes it live

A published report doesn’t magically see your files — refresh has to be arranged, and the arrangement depends on where the data lives (which is why the files-placement lesson matters more than ever):

  • Sources in SharePoint/OneDrive — the happy path: the Service reaches them directly. Schedule it: dataset → Settings → Scheduled refresh, pick the times, add failure notifications — the flow-history habit in new clothes: silence is never assumed success.
  • Sources on your PC or a server — you need a gateway (a small connector service; your IT team usually runs one). The honest advice: move the sources to SharePoint instead if you can — fewer moving parts, no gateway to babysit.

Done right, the pipeline this course has been assembling runs end to end without you: attachments file themselves → the recipe shapes them → the dataset refreshes at 07:00 → the report is current when the first phone opens it.

Desktopbuild & model publish the Service dataset + report refresh 07:00 ⟳ SharePoint browser: filters, drill-down, live phone 07:31 ✓ build once, publish once, refresh forever — the report becomes a place, not a file
Desktop builds, the Service serves. Once refresh is scheduled from a proper home, the report stops being something you send and becomes somewhere people go.

Sharing, and the small print in plain English

Sharing runs through workspaces (a team’s shelf; give colleagues Viewer role — the minimum-access rule again) or an app (a tidy packaged front door for a wider audience). The licensing, without the fog: viewing shared content needs Pro licences (~£8/user/month, bundled in E5), or the workspace sits on Premium/Fabric capacity (org-level, viewers free) — small teams: everyone Pro; big audiences: capacity is the maths. And the one that catches people: “Publish to web” makes a report genuinely public on the internet — treat it as what it is, publishing, and keep anything with real data behind the tenant.

Boundaries, as ever, honestly: the Service is a serving layer. Modelling stays in Desktop (republish to update — and note the file’s provenance in your README); ad-hoc analysis stays in Excel, which can connect straight to the published dataset (“Analyze in Excel” — pivots against the same single truth); and a dashboard nobody asked for is still a dashboard nobody reads, however smoothly it refreshes.

Build once, publish once, schedule the plumbing, share the minimum. The report stops being an artefact you produce monthly and becomes infrastructure that produces itself — which was the destination this whole automation arc was walking toward.