Publishing and Sharing in the Power BI Service with Row-Level Security

A report that lives on your laptop only helps you. The Power BI service (app.powerbi.com) is where reports get published, refresh on their own and are shared securely. In this lesson you'll go from a .pbix file to a solution the whole company uses.

Limits from Microsoft's Power BI service description, checked in November 2026. Microsoft can change them: check the current version before sizing a project.

Licensing: what you need to know

Building reports in Power BI Desktop is free. To share in the service, both the publisher and the viewers usually need a paid license (Pro or Premium Per User), unless the content lives in a dedicated company capacity (a Premium capacity or a Fabric F64 or larger capacity), in which case viewers can use free licenses. Many organizations already include Power BI Pro in their Microsoft 365 plans. Terms and prices change, so check Microsoft's official Power BI pricing page or ask IT before you decide.

Publishing

1. In Power BI Desktop, sign in with your work or school account.
2. Click Home › Publish and choose the destination workspace.
3. Two items get published: the report (pages and visuals) and the semantic model (data, relationships and measures; it used to be called a "dataset").

When you make changes, publish to the same workspace again and confirm you want to replace it.

Workspaces and roles

A workspace is a shared folder for a team or project ("Sales", "Finance"). "My workspace" is personal: don't use it for content other people need. In each workspace you assign roles:

Best practice: creators work in the workspace and end users consume content through an app (see below), not by browsing the workspace.

Scheduled refresh

In the service, open the semantic model's settings › Scheduled refresh and choose the frequency and times. The number of refreshes per day depends on the license:

For a sales report like Summit's, one early refresh a day (say, 6:30 a.m.) is usually enough, and Pro's 8 per day leave plenty of room. If someone asks for "real-time data", read Lesson 14 before promising anything.

The full path, from Desktop to your users

1. Power BI DesktopPublishTo a team workspace, never to "My workspace" if others need it.
2. Service · semantic model settingsCredentials and gatewayCredentials for each source; if there are local files or servers, map the gateway.
3. Service · semantic model settingsScheduled refreshTimes, time zone and an email notification if it fails.
4. Service · model securityAssign rolesPeople or groups for each row-level security role.
5. WorkspaceCreate or update the appEnd users consume content from the app, with its navigation.

Ways to share

Row-level security (RLS)

With row-level security, one report shows each person only their own data: the Midwest manager sees the Midwest; the VP sees everything.

Static roles

1. In Power BI Desktop: Modeling › Manage roles › New. Create a role named "Midwest".
2. Select the Customers table and write the DAX filter: [Region] = "Midwest". Thanks to the relationships, the filter reaches Sales.
3. Test it with Modeling › View as › Midwest.
4. Publish and, in the service, open the semantic model's Security settings and add people or groups to the role.

Dynamic roles

With many managers, instead of one role per region, create an "Access" table with each person's email and region, relate it to your model and use a single role with this filter on the Access table:

[Email] = USERPRINCIPALNAME ()

USERPRINCIPALNAME returns the sign-in email of whoever is viewing the report. When a manager changes, you only update the table.

Dynamic security with Summit's data

In the course file you don't need to build an access table: the SalesReps table already has each rep's email (for example, emily.carter@summitsupply.example). Create a "Sales Rep" role with this filter on SalesReps:

[Email] = USERPRINCIPALNAME ()

The filter flows from SalesReps to Sales through RepID (and to Targets, if you related it to SalesReps). Test it in Desktop with Modeling › View as, checking the role and typing Emily's email under Other user: every number should drop to hers. For 2025–2026 her sales are $133,438.18, exactly the Midwest region's total, because at Summit each rep covers a single region. Also create a "Leadership" role with no filter for people who should see everything.

Governance best practices

• One semantic model, many reports: several reports can connect to the same published model (Get data › Power BI semantic models). Measures are defined once and everyone uses the same "Sales" number.
• Separate workspaces for development and production when the report is critical.
• Check refresh history and set up failure notifications by email.
• Document measures with descriptions (in each measure's Properties pane).
• Sensitivity labels, if your organization uses them, for reports with sensitive data.

Common publishing and sharing mistakes

Access table:
  Email                                  | Region
  emily.carter@summitsupply.example      | Midwest
  marcus.johnson@summitsupply.example    | South
  rachel.kim@summitsupply.example        | Northeast
  daniel.ortiz@summitsupply.example      | West

Relationship: Access[Region] (1) → Customers[Region] (*). If one person
can cover several regions, Access will have several rows per email,
and it's better to relate it through a separate Regions table.

"By email" role, filter on the Access table:
  [Email] = USERPRINCIPALNAME ()

For the VP who must see everything, create another role with no
filter (or leave them out of any filtered role).

Summary

• Publishing uploads the report and its semantic model to a workspace in the service.
• Sharing usually requires paid licenses or a company capacity; check current terms.
• Scheduled refresh needs credentials for cloud sources or a gateway for on-premises sources.
• Share through apps, Teams, subscriptions and alerts; never publish internal data to the web.
• Row-level security, especially dynamic RLS, shows each person only what they should see.
• RLS only applies to viewers: end users consume from the app, without editing roles.

Next lesson: Advanced DAX and Performance: Variables, Rankings, Top N and New Customers. You'll level up your DAX with variables, rankings, Top N, customer segments and performance tuning.