This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Manage and secure Power BI (15–20%)
--> Secure and govern Power BI items
--> Configure Access to Semantic Models
Note that there are 10 practice questions (with answers and explanations) at the end of each topic. Also, there are 2 practice tests with 60 questions each available on the hub below all the exam topics.
Overview
Configuring access to semantic models (formerly known as datasets) is a core responsibility of a Power BI Data Analyst and a key topic within the “Manage and secure Power BI (15–20%)” domain of the PL-300 exam. This topic focuses on how access to data models is controlled, shared, governed, and secured so that users can interact with data appropriately—without compromising data integrity or confidentiality.
For the exam, you should understand how semantic models are shared, who can access them, what level of access they have, and how security is enforced at both the model and row level.
What Is a Semantic Model in Power BI?
A semantic model is the business-ready representation of data in Power BI. It includes:
- Tables, relationships, and hierarchies
- Measures, calculated columns, and KPIs
- Data formatting and metadata
- Security rules (such as Row-Level Security)
Semantic models are published to the Power BI Service and act as the foundation for reports, dashboards, and analysis.
Access Control Concepts You Must Know
Workspace Roles
Access to semantic models is primarily governed by workspace roles in the Power BI Service:
| Role | Capabilities Related to Semantic Models |
|---|---|
| Viewer | Can view reports and read data (if permitted) |
| Contributor | Can create and edit content, including reports |
| Member | Can publish, update, and share semantic models |
| Admin | Full control, including managing permissions and security |
Exam Tip: Viewers cannot create new reports from a semantic model unless Build permission is explicitly granted.
Semantic Model Permissions
Semantic models support item-level permissions, separate from workspace roles.
Key permissions include:
- Read – Allows users to view data used in reports
- Build – Allows users to create new reports using the semantic model
- Reshare – Allows users to share the semantic model with others
These permissions can be assigned to:
- Individual users
- Security groups
- Microsoft Entra ID (Azure AD) groups
Best Practice: Grant access using security groups instead of individual users for scalability and easier management.
Build Permission (Highly Exam-Relevant)
Build permission is one of the most tested concepts in this topic.
With Build permission, users can:
- Create new reports using the semantic model
- Use the model in Excel (Analyze in Excel)
- Use the model via external tools (when allowed)
Without Build permission:
- Users can view reports
- Users cannot create new reports from the model
Build permission can be granted:
- Automatically through workspace role (Member/Admin)
- Manually on the semantic model
- Via sharing settings
Sharing Semantic Models
Semantic models can be shared in several ways:
- Through workspace access
- By directly sharing the semantic model
- By publishing reports that use the model
- Via Power BI Apps
When sharing, you can choose whether recipients:
- Can build new content
- Can reshare the model
- Are restricted by existing security rules
Exam Scenario: A user can view a report but cannot create their own—this often indicates missing Build permission.
Row-Level Security (RLS)
Row-Level Security restricts which rows of data a user can see within a semantic model.
Key RLS concepts:
- Roles are defined in Power BI Desktop
- DAX filters control row visibility
- Users or groups are assigned to roles in the Power BI Service
- RLS applies to all reports using the model
Types of RLS:
- Static RLS – Fixed filters (e.g., Region = “West”)
- Dynamic RLS – Filters based on the logged-in user (e.g., USERPRINCIPALNAME())
Important: RLS is enforced at the semantic model level, not the report level.
Object-Level Security (OLS) (Awareness Level)
While not deeply tested, you should be aware that Object-Level Security can:
- Hide tables, columns, or measures from specific users
- Be configured using external tools (e.g., Tabular Editor)
OLS complements RLS but is more advanced and typically managed by model developers.
Certified Dataset / Endorsed Semantic Models
To support governance, Power BI allows semantic models to be endorsed:
- Promoted – Indicates the model is reliable and ready for reuse
- Certified – Officially validated and approved by data owners or admins
Endorsements help users:
- Identify trusted data sources
- Avoid using unofficial or duplicate models
Exam Tip: Certification requires specific tenant permissions and approval workflows.
Power BI Apps and Semantic Models
When distributing content via a Power BI App:
- Access to the semantic model is controlled through the app
- Users can be allowed to connect to the underlying semantic model
- RLS still applies
Apps provide a controlled, read-only distribution method while maintaining centralized security.
Common Exam Scenarios
You may be asked to determine:
- Why a user cannot build a report from an existing model
- How to allow self-service reporting without giving full workspace access
- How to restrict data visibility for different users
- Which permission or role best fits a business requirement
Key Takeaways for the PL-300 Exam
- Semantic models are secured through workspace roles and item-level permissions
- Build permission is essential for report creation and analysis
- Row-Level Security controls data visibility per user
- Use groups, not individuals, for scalable access control
- Endorsed and certified models support governance and trust
- Security is applied at the semantic model level, not per report
Just a FYI … this topic emphasizes balancing self-service analytics with strong data governance, a recurring theme throughout the PL-300 exam.
Practice Questions
Go to the Practice Questions for this topic.
The Data Community 