Publishing, Sharing, and Row-Level Security in Power BI Service

Publishing a Report from Power BI Desktop to the Service

Power BI Desktop is where you build your report; Power BI Service (app.powerbi.com) is where you share it with the world. Publishing moves your `.pbix` file to a workspace in the Service. A workspace is a collaborative container—think of it as a shared project folder that holds datasets, reports, and dashboards together.

To publish, open your finished report in Power BI Desktop, select Home → Publish, and choose the target workspace. Power BI uploads both the dataset and the report in a single step. Once published, the dataset and report appear as separate items in the workspace. Treat them as separate objects: you can build multiple reports on top of one dataset, and you can refresh the dataset on its own schedule.

Scheduled Data Refresh

A published dataset can refresh automatically so that your report always shows current data. The data source determines how refresh works:

• Import mode loads a snapshot of data into Power BI's in-memory engine. Refresh replaces that snapshot on a schedule you configure.
• DirectQuery mode queries the source live; no scheduled refresh is needed because every visual fires a live query.

For an Import-mode dataset connected to a PostgreSQL database sitting on your organization's network, you need an on-premises data gateway. The gateway is a lightweight Windows service installed on a machine that can reach both the database and the internet. It acts as a secure bridge, relaying queries and data between Power BI Service and your on-premises source. The gateway must be running and healthy for scheduled refresh to succeed.

To configure a schedule: open the dataset's settings in the Service, expand Scheduled refresh, toggle it on, choose a frequency (up to eight times per day on a shared capacity, more on Premium), and set the time zone. You can also click Refresh now to trigger a manual refresh and check the result immediately in Refresh history, which shows each run's start time, duration, and status—Succeeded or Failed.

Safety note: Refresh credentials are stored in the Service and encrypted at rest. Never store database passwords in plain text inside a `.pbix` file or in source control. Use the Service's credential manager to enter and update connection credentials securely.

Row-Level Security (RLS)

Row-level security restricts which rows a given user can see in a dataset. RLS is defined in Power BI Desktop using DAX filter expressions applied to a table, then enforced in the Service based on role membership.

Creating RLS Roles in Desktop

Go to Modeling → Manage roles → Create. Name your role (for example, `Region_East`). Select the table that contains the column you want to filter—say a `Sales` table with a `Region` column—and enter a DAX filter expression:

```

[Region] = "East"

```

Create a second role, `Region_West`, with:

```

[Region] = "West"

```

Use Modeling → View as to test each role without leaving Desktop. The canvas re-renders showing only the rows that pass the filter. Verify the row counts match expected values before publishing.

Assigning Roles in the Service

After publishing, open the dataset in the workspace, select More options (…) → Security. Add each test email address to the appropriate role. Users assigned to `Region_East` will only ever see East rows, regardless of which report or visual they use. Use View as role inside the Security panel to do a final verification in the Service.

Security note: RLS is enforced at the dataset layer, not the report layer. Sharing a report does not bypass RLS. However, a user with Build permission on the dataset can create their own report and may be able to explore data in ways you did not design; grant Build permission only when it is intentional.

Sharing Reports and Managing Permissions

Sharing a report gives a specific person access to view it without giving them full workspace membership. From the report, select Share, enter the recipient's Microsoft 365 email, choose whether to allow resharing, and set the permission level. For most external viewers, View is appropriate.

The recipient receives an email link. When they open it they see the report but cannot access the Edit mode, cannot modify visuals, and cannot export the underlying data unless you explicitly enable that option.

To revoke access, return to the report's Share panel, find the recipient in the list, and remove them. Their existing link becomes invalid immediately—the next time they try to open it they will see an access-denied message.

Guest users (people outside your Microsoft 365 tenant) require Azure Active Directory B2B guest accounts. Your instructor will provision these test accounts for the lab. Never use real production accounts or real customer email addresses in a lab environment.

PL-300 Relevance

This lesson maps directly to the Deploy and maintain assets domain of the Microsoft PL-300 exam. Expect exam questions on gateway configuration, refresh scheduling limits, RLS DAX syntax, and the difference between workspace roles (Admin, Member, Contributor, Viewer) and dataset-level security roles. Understanding what each permission level can and cannot do is as important as knowing how to configure it.