Skip to content
FR

Securing and Governing Power BI Items

Step 23 of 24

Securing and Governing Power BI Items

Introduction

This lesson completes the domain Manage and secure Power BI (15–20% of the PL-300 skills measured, outline dated April 20, 2026). Under "Secure and govern Power BI items" the official outline covers: configuring item-level access, configuring access to semantic models, implementing row-level security (RLS) roles, assigning members to RLS roles, applying sensitivity labels, and choosing a distribution method that respects governance. The exam describes a security requirement ("each manager sees only their region", "contractors can read but not export", "confidential reports must stay labeled when exported") and asks which mechanism meets it, or where in the Desktop or the service to configure it. Microsoft does not publish the number of questions or the question-type mix; OnLevelUp mock exams use a 50-question practice length and an 80% practice target, neither of which is official nor equal to the 700/1000 passing score.

After this lesson you will be able to layer the security controls of Power BI correctly, create static and dynamic RLS roles with DAX filters, test them, assign members, grant the right permissions on a semantic model, and apply and understand sensitivity labels.

Learning objectives

  • Explain the security layers: workspace roles, item permissions, app audiences, semantic model permissions, RLS and sensitivity labels.
  • Grant and revoke Read, Reshare, Write and Build permissions on items.
  • Create static RLS roles and dynamic RLS with USERPRINCIPALNAME().
  • Validate roles with View as and assign members in the service.
  • Explain what RLS does not cover and when object-level security applies.
  • Apply sensitivity labels and describe their effect on exports.

1. Security layers: who controls what

Security in Power BI is not one switch but a stack. Each layer answers a different question.

Layer Question it answers Where configured
Workspace role Who can see or edit everything in this workspace? Workspace > Manage access
Item permissions Who can open, reshare, edit or build on this specific report or model? Item > Manage permissions
App audience Which curated content does this consumer see? Workspace > App > Audiences
Semantic model permission Who can connect to this model to build new content? Model > Manage permissions (Build)
Row-level security Which rows of data does this viewer see? Desktop (roles) + service (members)
Sensitivity label How must the exported or shared file be protected? Item settings or Desktop (Microsoft Purview Information Protection)

Principle: grant the least privilege, use groups instead of individuals, and combine the layers rather than relying on one.

2. Item-level access and semantic model access

You can grant access to a single item without making someone a workspace member. From the item's ellipsis menu choose Manage permissions. The permissions to know:

Permission Allows
Read Open and view the item (a report, a dashboard)
Reshare Share the item with others (granted when sharing with "Allow recipients to share")
Write Edit or delete the item (given implicitly by workspace roles Contributor and above)
Build Build new content on a semantic model: connect from Desktop, Analyze in Excel, create new reports in the service, export underlying data
Execute Run a paginated report or a dataflow trigger (Fabric items)

Semantic model access

A semantic model is the sensitive asset: whoever can build on it can read its data (subject to RLS). Permission principles:

  • Consumers of a report need Read on the report and, for the report to render, an effective right to the underlying model. Sharing a report with a user gives them Read on the report and Build on the model only if you tick the option (and only if they otherwise lack it).
  • To let analysts create new reports on a shared, certified model, grant Build on that model, ideally through a security group. Without Build, Get data > Power BI semantic models does not list the model for them.
  • Removing a user from a workspace also removes the permissions inherited from the role, but direct item permissions remain until revoked. Always audit both lists.
  • Export data and Analyze in Excel require Build; tenant and report settings can disable export for consumers.

Pitfall: sharing a report link with "Anyone in the organization with the link" does not mean RLS is bypassed; RLS still filters Viewers. But if a recipient also has an editing role in the workspace that owns the model, RLS does not apply to them.

Worked example: choose item permissions

Statement. Camille, an external partner analyst, must (1) open the "Supplier KPIs" report, (2) build her own report on the "Supplier model", (3) never edit the original, nor share it onward.

Reasoning.

  1. Open the report: Read on the report (via a share link or Manage permissions, with Allow recipients to share off).
  2. Build her own report: Build on the semantic model, granted in the model's Manage permissions.
  3. Never edit: she must not hold a Contributor, Member or Admin role, so no workspace role is needed at all; Write is not granted.
  4. Not share: leave Reshare off.

Why not the alternatives. Making her a workspace Contributor grants write access to everything and bypasses RLS. Making her a Viewer exposes every item in the workspace. Giving only Read on the report prevents her from building new content.

3. Row-level security (RLS)

RLS restricts rows a user can see in a semantic model by applying DAX table filter expressions attached to a role. You author roles in Power BI Desktop, then assign members in the service. RLS applies to Viewers, to people reaching the model through an app, a share link, or Build permission, but never to those who can edit the model (Admin, Member, Contributor of the owning workspace).

Static RLS

A static role hard-codes the filter. In Desktop: Modeling > Manage roles > Create, name the role, select the table, and enter the filter.

-- Role "Europe": rows of the Territory table
[Region] = "Europe"

A user in that role sees only rows of Territory where Region is "Europe", and because relationships propagate filters, only the related Sales rows. Static roles scale poorly: one role per region, each with its members.

Dynamic RLS

A dynamic role uses the signed-in user's identity and a mapping table, so a single role serves everybody.

-- Role "RegionalManager" on the table UserRegion (columns: UserEmail, Region)
[UserEmail] = USERPRINCIPALNAME()

UserRegion is related to Territory on Region, so the filter on the mapping table reaches Territory and then the fact table only if the relationship filter direction allows it (see the note below). Key functions:

Function Returns Remark
USERPRINCIPALNAME() The user's UPN (e-mail like) Preferred in the service; matches the sign-in
USERNAME() DOMAIN\user in Desktop, the UPN in the service Differs between environments; tests can mislead
USEROBJECTID() Entra object ID Useful when e-mails change
LOOKUPVALUE() Looks up a value in another table For mapping users to attributes

Important: filters in RLS flow along relationships in the filter direction. If the security table is on the "many" side, or the cross-filter direction is single the wrong way, the filter does not reach the fact table. Enabling Apply security filter in both directions on the relationship solves a mapping-table design, with care for performance.

Testing with View as

In Desktop, Modeling > View as lets you tick one or more roles (and optionally "Other user" to emulate a UPN) and view the report as that role. In the service, open the model's ellipsis, Security, and use Test as role. Always test the role with a user who is not an editor.

Assigning members in the service

After publishing, roles do nothing until members are assigned: Semantic model > Security (ellipsis) > select the role > add users, security groups or distribution lists. Members are assigned per role, in the service, not in Desktop. A user in several roles gets the union of the rows allowed by those roles. A user with no role who has Viewer access sees no data (an RLS-protected model returns nothing for a viewer not in any role).

What RLS does not do

  • It does not apply to workspace Admin, Member and Contributor.
  • It does not hide tables or columns. Hiding a column in the model is not security. Use object-level security (OLS) (configured with Tabular Editor) to secure tables and columns.
  • With DirectQuery, RLS can be pushed to the source; with live connection to Analysis Services, RLS is defined in the source model, not in Power BI.
  • Roles on a shared semantic model apply to every report built on it.

Worked example: dynamic RLS for sales managers

Statement. Fabrikam has 40 sales managers. Each must see only the customers of the regions listed for them in an HR table ManagerRegion(ManagerEmail, Region). New managers are added weekly, and the model has Customer[Region] and a Sales fact.

Reasoning.

  1. One dynamic role, not 40 static roles.
  2. Relate ManagerRegion[Region] to Customer[Region] so that the filter propagates to Sales.
  3. Define the role "ManagersRLS" with the filter on ManagerRegion: [ManagerEmail] = USERPRINCIPALNAME().
  4. Test with View as > Other user using one manager's e-mail.
  5. Publish, then in the service assign the security group Sales-Managers to the role. New managers are added to the group and to the HR table; nothing is republished.
  6. Make sure the managers have the Viewer role (or only an app) and no editing role.

Why not the alternatives. Hiding the fact table columns does not filter rows. Per-region static roles require manual member updates and a republish for each region change. Setting the filter on Sales directly with a hardcoded email list becomes unmaintainable.

4. Sensitivity labels

Sensitivity labels from Microsoft Purview Information Protection classify and protect content (for example Public, Internal, Confidential, Highly Confidential). They require that the tenant admin enables labels for Power BI and that users are in the label policy. Facts to know:

  • Labels can be applied to semantic models, reports, dashboards, dataflows in the service, and to .pbix files in Desktop.
  • A label does not change who can open the item inside Power BI; access is still decided by workspace roles, permissions and RLS. Its value is in protecting data when it leaves: exports to Excel, PowerPoint, PDF and .pbix files carry the label and, if the label includes encryption, its protection.
  • Downstream inheritance: when a report is built on a labeled semantic model, the label can propagate; the tenant setting controls inheritance and mandatory labeling.
  • A mandatory label policy forces users to choose a label before saving or publishing.
  • Users can downgrade a label only if the policy allows it, usually with a justification.
  • Labels can be applied automatically by the admin through default labels.
Need Right tool
Hide rows from a user RLS
Hide a column or table Object-level security
Keep the Excel export classified and encrypted Sensitivity label with protection
Let an analyst build on a model Build permission
Show a certified badge Endorsement

Worked example: protect a confidential report

Statement. HR publishes a report on salary bands. The data may be seen by HR only. Exports must stay protected when saved to a laptop.

Solution.

  1. Put the report in an HR-only workspace; grant HR groups the Viewer role or give an HR app.
  2. Apply the Confidential – HR sensitivity label (with encryption for HR only) to the semantic model and the report.
  3. Create an RLS role if HR business partners may see only their own units.
  4. Disable export or "Publish to web" where governance requires it.

Why not the alternatives. A label alone does not stop a user with workspace access from reading the report. RLS alone does not protect a file once exported. Hiding the report in an app navigation is not a security control.

5. Governance practices that the exam expects

  • Use security groups for roles, audiences, RLS membership and Build permission.
  • Separate development and production workspaces and promote through deployment pipelines.
  • Endorse trusted models (promote, certify) and educate users to reuse them.
  • Review who has access regularly from Manage access and Manage permissions.
  • Use lineage and impact analysis before changing shared models.
  • Limit Publish to web, export and sharing with tenant settings handled by the Power BI administrator.

6. Pitfalls and exam tips

  • RLS = rows, OLS = tables and columns. Hiding a column is not security.
  • RLS is configured in two places: roles in Desktop, members in the service.
  • RLS does not apply to editors. Testing as the author always shows all rows; use View as.
  • USERPRINCIPALNAME() is the recommended function for dynamic RLS in the service.
  • A viewer in no role sees nothing; a viewer in several roles sees the union.
  • Build permission is what enables building on a shared model and Analyze in Excel.
  • Sensitivity labels protect content on export; they do not grant or deny access in the service.
  • Do not confuse sharing (item permissions), apps (audiences) and workspace roles.

7. Mini case study

Situation. Adventure Works shares a "Global Sales" semantic model. Requirements: (1) regional directors see only their region; (2) the same model is certified and reused by 12 report authors in other workspaces; (3) a monthly Excel export of the report goes to the board and must remain classified Confidential; (4) the BI team needs to edit the model; (5) a contractor must read a single report only.

Questions. Design the security.

Solution (commented).

  1. Regional directors. A dynamic RLS role using a DirectorRegion mapping table and USERPRINCIPALNAME(). Assign the group Regional-Directors in the service. Give them Viewer or an app only.
  2. Reuse. Certify the model through an authorized certifier and grant Build to the group Report-Authors. They do not need workspace membership.
  3. Board export. Apply the Confidential label to the model and report so that exported Excel files inherit it.
  4. BI team. Workspace Contributor (or Member for the lead). They bypass RLS by design, so they are not testers of RLS: use View as.
  5. Contractor. Read permission on that report only, without Reshare and without a workspace role.

Common wrong answers. Giving directors Contributor "so that they can explore" (RLS disappears); hiding columns to protect rows; building 12 static roles; applying a label and believing it blocks access; using Publish to web for the contractor.

Key terms

  • Item permission: right on a single item (Read, Reshare, Write, Build).
  • Build permission: right to create content on a semantic model.
  • Row-level security (RLS): DAX-based row filter attached to a role.
  • Static / dynamic RLS: fixed filter versus filter based on the signed-in user.
  • USERPRINCIPALNAME(): DAX function returning the user's UPN.
  • View as: Desktop and service feature to test roles.
  • Object-level security (OLS): hides tables or columns from roles.
  • Sensitivity label: Purview classification and protection applied to content.
  • Least privilege: grant only what is needed.

Summary checklist

  • I can list the security layers and what each one decides.
  • I can grant Read, Reshare, Write and Build and know when each applies.
  • I can write a static and a dynamic RLS filter and test it with View as.
  • I know roles are created in Desktop and members assigned in the service.
  • I know RLS does not apply to Admin, Member and Contributor and does not hide columns.
  • I can explain what sensitivity labels do on export and what they do not do.
  • I can design a least-privilege setup with security groups.

Official sources