Managing and optimising shared semantic models in Microsoft Fabric, with a focus on securing access, is essential in today’s data-driven world. These models are the backbone of an organisation’s analytics, providing consistent and scalable insights across teams. Whether you’re an experienced professional or just starting with Microsoft Fabric, understanding how to manage access to shared semantic models is key to delivering impactful insights.
This blog focuses on the core concepts that are vital for building a strong foundation. These concepts are pivotal for a correct and successful implementation of shared semantic models. Without a solid grasp of these basics, it can be challenging to navigate the complexities of advanced configurations or ensure secure and efficient use of semantic models within Microsoft Fabric.
I originally planned to cover this topic in one blog, but it turned out to be too much for a single post. Splitting it into two parts allows me to explain everything clearly without making it overwhelming. Here’s what the series covers:
- Part 1 (This blog): Core Concepts
- Part 2 (Next blog): End-to-End Implementation of Shared Semantic Models
- Configuring Fabric Admin Portal Settings
- Managing OLS and RLS in Shared Semantic Models
- Permissions on Semantic Models
By the end of this blog, you’ll understand the basics of managing and optimising secured access to shared semantic models in Microsoft Fabric.
If you prefer a video format, check out the tutorial on YouTube:
For those who enjoy reading the details, keep scrolling!
Requirements
Before diving into the implementation of shared semantic models in Microsoft Fabric, it’s important to understand the prerequisites. This process has specific licensing and role requirements, which are outlined below:
- At least Power BI Pro license: This is the minimum required license because Workspace functionality is available only with a Pro or higher license. For large semantic models you will required Power BI Premium Per User (PPU) or a Fabric Capacity.
- Microsoft Fabric Administrator role: Necessary for configuring semantic model discoverability in the Admin Portal.
- At least Workspace Member role: Required to set permissions on the semantic models.
- At least Workspace Contributor role: Needed to assign users and security groups to RLS (Row-Level Security) and/or OLS (Object-Level Security) roles.
Ensure that you have the proper licenses and roles assigned before starting the implementation to avoid any disruptions or limitations in managing shared semantic models.
Workspace Management and its Role in Shared Semantic Models
Workspace management is a fundamental aspect of building a robust data platform, especially when dealing with shared semantic models. In Microsoft Fabric, workspaces serve as containers that group related items including Notebooks, Dataflows, Lakehouses, semantic models, reports, dashboards, and other assets, allowing teams to collaborate effectively while maintaining clarity and structure.
However, organisations often face challenges in managing workspaces effectively. Ensuring proper access control and security for sensitive data is critical, especially when multiple teams use shared workspaces. Balancing self-service BI needs with centralised governance can also be complex, requiring clear policies to prevent issues like data duplication or inconsistent report versions. Additionally, organising assets in a way that aligns with business functions, projects, or data domains is crucial for scalability and ease of discovery, particularly in environments with hundreds of workspaces.
Effective workspace management becomes even more critical when dealing with shared semantic models, as these models are the foundation for consistent, trustworthy analytics across the organisation. Poorly managed workspaces can lead to fragmentation of data models and undermine the consistency that semantic models aim to provide, which I refer to as Modern Data Silos.
Workspace management by itself is a wide topic requiring blog series of its own, so I leave it for future blogs and tutorial videos.
So it is crucial to understand why separating semantic models from their connected reports is essential for building a scalable and maintainable data platform. Before we dive into the the details let’s take a moment to understand what shared semantic models are.
What are Shared Semantic Models and Why are they Important?
A shared semantic model is a semantic model that is discoverable and accessible outside of its hosting workspace. This means that reports and other analytics artefacts connected to this semantic model can reside in different workspaces. Unlike traditional, siloed models where reports and data models are tightly coupled within the same workspace, shared semantic models enable cross-workspace collaboration, facilitating a more scalable and modular approach to managing data assets.
Shared semantic models are the foundation of consistent and reliable data analysis within an organisation. These models define the structure, relationships, and business logic of data, creating a unified source of truth that ensures all reporting and analytical tools draw from the same definitions. This eliminates discrepancies caused by multiple versions of logic or calculation and promotes alignment across departments.
Understanding shared semantic models is essential because they address several key organisational needs:
- Consistency Across Reports: Shared semantic models ensure that all reports and dashboards using the model display consistent metrics by centralising business logic and definitions. This approach reduces confusion and errors caused by conflicting data interpretations.
- Improved Collaboration: Shared models allow cross-functional teams to work together seamlessly by enabling access to a single, validated data model. Teams in different departments or locations can develop reports specific to their needs without duplicating or recreating data models.
- Scalability and Reusability: Instead of duplicating models across multiple workspaces, a shared semantic model enables organisations to scale their analytics efforts. As the data model evolves, updates automatically reflect in all connected reports, reducing maintenance overhead.
- Governance and Control: Shared models simplify governance by centralising where business rules and transformations are maintained. This improves control and ensures that all analytics adhere to organisational standards, supporting compliance and data quality initiatives.
- Performance Optimisation: By separating the model from its reports, resource utilisation can be optimised, particularly in large-scale analytics environments. For instance, organisations can host computationally intensive models in dedicated capacities while allowing reports to operate in less resource-intensive environments.
Given their role in enhancing consistency, collaboration, scalability, and governance, shared semantic models are a critical component of a modern data platform.
The following diagram shows how a shared semantic model works:
While the concept of shared semantic models may seem straightforward, implementing them effectively requires meticulous attention to detail and coordination across different roles within the organisation, such as developers, report writers (contributors), and administrators. Here’s how.
Roles Involved in Implementing Shared Semantic Models
Implementing shared semantic models is a collaborative effort requiring the involvement of multiple roles within the organisation. Each role contributes to ensuring that the models are secure, accessible, and aligned with organisational goals. Here’s how these roles play a part:
Power BI Developers
Power BI developers are central to implementing the semantic models, as they design and maintain the models themselves. One of the primary objectives is to securely eliminate modern data silos, enabling everyone in the organisation to discover and access a unified source of truth. Developers must implement Row-Level Security (RLS) and Object-Level Security (OLS), while the Administrators take care of role assignments to ensure users only access the data they are authorised to view. Developers are also responsible for optimising the performance of the semantic models to support multiple users and connected workspaces.
Report Writers (Contributors)
Report writers, or contributors, are users who connect to shared semantic models to create content such as reports, dashboards, or analytics outputs. They often use tools like Microsoft Excel or Power BI to connect to these models. While shared semantic models provide them with a single source of truth, report writers must only see the data relevant to their roles, as dictated by RLS and/or OLS. Additionally, they are responsible for storing their reports and other outputs in the designated workspaces, ensuring alignment with organisational standards. Effective collaboration with developers is crucial to clarify reporting requirements and ensure data consistency across all reports.
Administrators
Administrators play a vital role in maintaining the infrastructure and enforcing governance for shared semantic models. Depending on the organisation’s size and governance framework, various administrative roles are involved:
- Fabric Admins: These administrators oversee the entire Fabric tenant, managing settings and configurations through the Fabric Admin Portal. Their responsibilities include enabling or restricting features, monitoring resource usage, and ensuring tenant-level security compliance. Read more about Fabric Admins here.
- Domain Admins: In organisations that utilise Domains to segment data assets and governance policies, Domain Admins manage all aspects related to their assigned domains. This includes assigning permissions, maintaining domain-level security, and ensuring compliance with organisational governance policies. Learn more about domains and domain roles here.
- Workspace Admins: These administrators manage individual workspaces, ensuring proper organisation and security of all items including semantic models. They are responsible for granting and revoking item permissions, and managing access to workspaces. Workspace Admins are critical in ensuring that shared semantic models and connected reports are appropriately managed.
Understanding User Roles on Workspaces and Its Relation to Semantic Models
As explained earlier, a shared semantic model is when the semantic model is stored in a workspace (like Workspace A in the following diagram) and its connected reports are in a different workspace (like Workspace B).
The users accessing the workspaces have one of the following roles:
- Admin: Full control over the workspace, including managing members, permissions, and settings.
- Member: Ability to create, edit, and delete different items within the workspace.
- Contributor: Can add and edit items but cannot manage workspace settings or members.
- Viewer: Read-only access to some items within the workspace including reports, paginated reports, and dashboards.
Learn more about workspace roles here.
It is important to note that the items in workspaces inherit permissions from their workspaces roles. For example, a user with Viewer role on Workspace A will inherently have read-only access to the data of a semantic model in this workspace. Have a complete understanding of item permissions and their relation to workspace roles is crucial to successfully implement shared semantic models without compromising security and compliance. So I strongly advise reading the official documentation of the Permission Model in Microsoft Fabric here.
What Workspace Roles and Semantic Model Permissions are Required
Now that we understand the workspace roles and item permission model, we can implement accessing the semantic models in various methods depending on security and data governance requirements. One of the most common scenarios is when we want the report writers to access only specific semantic models with RLS and/or OLS stored in Workspace A and NOT all semantic models within this workspace. The report writers must follow RLS and/or OLS rules during the report development. This scenario is when the workspace contains other semantic models which should not be accessed by the same group of users. In this case:
- Report Writers:
- Do not have any roles on Workspace A.
- Have Build permission on the semantic model which gives the users read-only access to the data and allows them to build reports on top of the semantic model. Read more about semantic model permissions here.
- Must be assigned to the required RLS and/or OLS roles on the semantic model.
- Must have Contributor role on Workspace B to save the reports. The End Users of the reports.
- End Users:
- Must either have Viewer role on Workspace B, or the report is shared with them or delivered to them via Org apps.
- Must be assigned to the required RLS and/or OLS roles on the semantic model.
The following diagram represents this Scenario:
Now that we have a full understanding of the scenario, we can proceed with implementing it effectively (which I cover in my next blog), ensuring that both security and governance requirements are met while enabling seamless collaboration across teams.
Conclusion
In this blog, we explored the core concepts of shared semantic models in Microsoft Fabric, including their importance, requirements, and the roles needed to implement them. By understanding how workspaces, roles, and permissions interact, you can lay a strong foundation for leveraging shared semantic models effectively.
In the next blog, we will dive deeper into the end-to-end implementation of shared semantic models. This includes configuring the Fabric Admin Portal, managing Row-Level Security (RLS) and Object-Level Security (OLS), and setting up the required semantic model permissions. Stay tuned for actionable insights and detailed steps to master this process!
As always, I would love to hear your thoughts and experiences, so be sure to share them in the comments below!
Follow me on LinkedIn, YouTube, and X (formerly Twitter).
