Publishing to the Power BI service: workspaces, refresh and row-level security

Power BI Desktop is where you build. The Power BI service, in the browser, is where other people use what you built. The first month in a reporting role usually includes publishing a report, setting it to refresh on its own, and making sure one region's team cannot see another region's numbers.

What publishing creates

When you click Publish, the file is split into two items in a workspace: a semantic model (also called a dataset) holding the data, relationships and measures, and a report holding the pages and visuals.

A workspace is a container with its own roles: Admin, Member, Contributor and Viewer. Viewers can open reports but cannot edit or republish. To hand a finished set of reports to the business, you create an app from the workspace; the app is what end users open.

Scheduled refresh and gateways

Published data is a snapshot taken at publish time. To update it, set a scheduled refresh on the semantic model. If the source is a cloud service, refresh connects directly. If the source is a file on a shared drive, an on-premises database or anything inside the company network, the service cannot reach it, and you need an on-premises data gateway installed on a machine that can.

Example 1: a report reads an Excel file on a network drive. Refresh fails with a message about the data source. Fix: install the gateway on a server that is always on, add the file path as a data source under the gateway, map the model to it, then schedule refresh. Example 2: a report using DirectQuery shows live data, so it needs no refresh schedule, but it still needs the gateway if the database is on-premises.

Row-level security

Row-level security (RLS) filters rows by who is viewing. In Desktop, under Manage roles, create a role, pick a table and write a DAX filter. Example 3: a role called Region Manager with the filter [Region] = "South" on the Region table. A more useful version uses [ManagerEmail] = USERPRINCIPALNAME() so one role serves every manager. Test with View as. After publishing, open the model's Security page in the service and add users or groups to each role. Without that last step the role exists but applies to nobody.

RLS does not apply to workspace members with edit rights; they see everything.

Common mistakes and a practice habit

• Publishing to My Workspace and sharing from there. Use a shared workspace so the report survives staff changes.
• Assuming scheduled refresh is set by default. It is not.
• Creating roles in Desktop and forgetting to assign members in the service.

Publish a small report to a trial workspace, set a refresh, change the source file and confirm the change arrives. Then add an RLS role with a hard-coded filter and test it with View as before and after publishing.