The Power BI Service

Why this matters

Everything you have built lives in a file on your laptop. Lesson 1 published to My workspace — a private sandbox — and every lesson since has quietly assumed the real destination: an organization where the merchandising team sees the report, finance's numbers refresh at 6 a.m. without a human, and the Midwest manager sees the Midwest. That organization-shaped layer is the Service, and it is where BI work stops being a file and starts being infrastructure.

Workspaces: from sandbox to shared

My workspace is yours alone — the sandbox. Real deployment happens in shared workspaces, where a team collaborates on reports and their underlying semantic models (the published form of the model you built in Module 2 — one model, many reports, the measure family shared). Four roles govern who can do what:

Apps: distribution without the workshop tour

Handing readers Viewer access to a workspace shows them the workshop — every draft, every test page. An app packages selected reports from a workspace into a clean, read-only experience with its own navigation and audience list. The workshop/showroom split: builders live in the workspace; the organization installs the app. Update the workspace, push the update to the app when ready — a deliberate release step, not a live wire. If Lesson 9's answer-versus-exploration frame was page design, this is the same idea at distribution scale.

Scheduled refresh: the 6 a.m. analyst

A published semantic model is a snapshot until refresh brings new data. In the model's Service settings you schedule it — daily at 6 a.m., say — and the recipe you wrote in Module 1 replays against the sources without you. The one architectural wrinkle: where do the sources live?

• Cloud sources (SharePoint, OneDrive, cloud databases) — the Service reaches them directly.
• On-premises sources (a file share, a local SQL Server) — the Service cannot reach into a building. A gateway — a small agent installed inside the network — brokers the connection. Concept-level here; installing one is IT's work.

Row-level security: the Midwest manager sees the Midwest

The report is shared, but should every reader see every region? RLS filters data per reader, and it is built exactly where you would hope: in the model, with DAX. In Desktop: Modeling → Manage roles → create role Midwest Manager with a table filter on the Regions dimension:

[Region] = "Midwest"

Publish, then in the Service assign people to the role. When the Midwest manager opens the report, the filter rides every query: their revenue card reads $8.71M (the Midwest's all-time total), their attainment chart shows one region, and — because the filter lives on the dimension and flows down the star — every fact obeys at once. Lesson 4's architecture is doing security work now: one more reason the model was worth three weeks.

Two professional notes. Test with "View as" in Desktop before trusting it — predict what the role should see, then look (the habit needs no introduction by now). And know that dynamic RLS exists: a single role filtering on [Email] = USERPRINCIPALNAME() against a user-mapping table (our employees table, with its Region column, is shaped for exactly this) — one role serving fifty managers. Build the static version this week; recognize the dynamic pattern for the day the fifty arrive.

Licensing, honestly

The question every instructor and every team eventually asks, answered plainly (verify current terms at print time — this is the shape, not a price sheet):

The design consequence for this course: everything gradeable ships as a .pbix; the Service exercises degrade gracefully to concept questions where a tenant is not provided. Your instructor tells you which lane your institution is in.

Mobile layout and the export conversation

Two closing practicalities. Mobile layout (View → Mobile layout in Desktop) rebuilds a page as a phone-shaped vertical stack from the same visuals — if L10's question test named phones as a primary audience, this is the mechanical follow-through: answer card first, one claim per screen-height. And the export conversation: readers will export your visuals to Excel — it is the most-used button in the Service, it is how trust in numbers gets extended into workflows you don't control, and fighting it outright loses. The professional posture: let the measures be the single source of truth so exports agree with the report, and treat heavy exporting as a signal the report is missing a page someone needs.

Common mistakes

• Viewer roles where an app belongs. The audience installs the showroom, not the workshop.
• Untested RLS. "View as" first, distribution second — a leaking role is a breach, not a bug.
• Scheduling refresh against a laptop path. The Service refreshes what it can reach; reachability is an architecture question answered before the schedule.
• Treating RLS as file security. The .pbix contains everything; who gets the file is its own decision.
• Fighting the export button. Make the measures the single source of truth and read heavy exports as unmet-need telemetry.

Summary