Lecture video · L11 The Power BI Service

[Slide 1] Everything you have built this semester lives in a file on your laptop. Tonight it leaves. The Service is the layer where BI stops being a file and starts being infrastructure: where a team collaborates instead of emailing versions, where data refreshes at six in the morning without a human awake, and where the Midwest manager sees the Midwest and nothing else. By the end of tonight you will know the four workspace roles, why audiences install apps instead of touring your workshop, what a gateway is actually for, and how one line of DAX becomes row-level security — riding, of all things, the star schema you built in week four.

[Slide 2] Deployment starts with where things live. My workspace is your private sandbox — where Lesson One published, and where nothing team-shaped should stay. Shared workspaces are the workshop: reports and their semantic models, worked on together under four roles. Admin can do everything including delete the workspace — that is for one or two owners, not a team of twenty-three. Members publish and share; Contributors publish but do not control distribution; Viewers read. And here is the distribution insight most teams learn late: audiences usually should not be Viewers at all. Viewer access shows the workshop — drafts, tests, half-built pages. An app packages the finished reports into a clean, read-only experience that updates only when a builder pushes a release. Builders in the workspace; the organization installs the app. Workshop and showroom.

[Slide 3] Scheduled refresh is the six a.m. analyst: it replays the Power Query recipes you wrote in Module One against their sources, on a timer, without you. The one architectural question is reachability — where do the sources live? Cloud sources the Service reaches directly. On-premises sources — a file share, a local database — it cannot, because a cloud service cannot reach into a building. The gateway is the answer: a small software agent installed inside the network that brokers the connection. Concept-level for this course; installing one is IT's afternoon. The mistake to never make: scheduling refresh against a path on your own laptop, which is unreachable by definition and asleep besides. Reachability first, schedule second.

[Slide 4] Prediction beat, and it ties the whole course together. Your Midwest Manager role filters exactly one thing: the Regions dimension. View as the role, and revenue narrows — but so do returns, and targets, and every other fact. Nobody wrote filters on those tables. Why does it work? One minute. The answer is the machinery you have used since week one and named in week four: filter flow. Dimensions filter facts, down the relationships — so one filter on Regions governs every fact Regions can reach. RLS is a slicer with a badge. And the second question answers itself the same way: a leak — a returns card ignoring the role — means a fact the filter cannot reach, which means a missing or broken relationship. An RLS leak is a filter-flow gap with security consequences, and Model view is where you catch both. In the practice you will build that exact leak on a copy and hunt it from the reader's side.

[Slide 5] The mechanics, then the two professional notes. In Desktop: Modeling, Manage roles, create Midwest Manager, one DAX filter on the Regions dimension — Region equals Midwest. Publish, assign people to the role in the Service. Note one: test with View as, with a predicted value in hand — the Midwest's all-time revenue is eight point seven one million, so the card either reads it or the role is wrong. An untested role is an assumed role, and a leaking role is a breach. Note two: dynamic RLS exists for scale — a single role filtering email equals USERPRINCIPALNAME against a mapping table, one role serving fifty managers. Build static this week; recognize dynamic for the day the fifty arrive. And the boundary that surprises people: RLS binds readers of the published report. Anyone who gets the .pbix file itself has the entire model in free Desktop. Who gets the link and who gets the file are different decisions. Make both on purpose.

[Slide 6] Three practicalities. Licensing, in one honest line each: free builds everything and publishes to the sandbox — Lessons One through Ten ran on it entirely; Pro unlocks the collaboration layer — shared workspaces, apps; capacity lets unlicensed readers consume at organizational scale. Your instructor tells you which lane your institution is in, and the assignment is designed to grade fully in any of them. Mobile: if the field team reads on phones, Desktop's mobile layout re-choreographs the same visuals into a vertical stack — answer card first, one claim per screen. And the export button: your readers will export visuals to Excel, it is the most-used button in the Service, and fighting it loses. The professional posture: your explicit measures make every export agree with the report — the single source of truth extends into spreadsheets you will never see — and heavy exporting is telemetry: somebody needs a page you have not built yet.

[Slide 7] Tonight in five lines. Builders work as Members in shared workspaces; audiences install the app — workshop and showroom, released on push. Refresh replays your recipes on a timer, from sources the Service can reach — gateways broker the on-premises ones. Row-level security is one DAX filter on a dimension, riding the star's filter flow into every fact — verified with View-as against a predicted figure, never assumed, and never confused with file security: the .pbix carries everything. This week's Hot practice has you write the rollout memo for the whole company — including two stakeholder requests you will decline professionally, with substitutes. And then one lesson remains: the AI features — Q and A, key influencers, Copilot — approached with exactly the discipline you have spent thirteen weeks building, because a confident answer you cannot verify is this course's oldest enemy wearing its newest costume.