This blog series complements a YouTube tutorial I published earlier this month, where I quickly covered the scenario and implementation of shared semantic models in Microsoft Fabric. However, I realised this topic demands a more detailed explanation for those who need a deeper understanding of the processes and considerations involved in one of the most common enterprise-grade BI scenarios.
In organisations with strong security and governance requirements, implementing shared semantic models is vital to ensure seamless and secure access to data. These organisations often split roles across various teams responsible for productionising analytics solutions. Typically, they have strict Row-Level Security (RLS) and Object-Level Security (OLS) implemented in their semantic models. The goal is to enable two key groups within the organisation:
- Report Writers: They must access the semantic models securely. This means having sufficient permissions to create reports while ensuring access is restricted to only the relevant objects and data.
- End-Users: They need access to trustworthy and relevant information without dealing with underlying complexities. All the heavy lifting should be managed behind the scenes.
The first blog laid the groundwork by covering all the essential core concepts necessary for successfully implementing this scenario. It also provided a clear explanation of the roles involved in the process.
Blog Series Overview
Initially, I planned to cover everything in one post. However, the scope turned out to be too large, so I split it into two parts to ensure clarity and avoid overwhelming readers. Here’s what the series includes:
- Part 1 (Previous blog): Core Concepts
- Part 2 (This blog): End-to-End Implementation of Shared Semantic Models
By the end of this blog, you will apply the understanding from the previous post to a real-world scenario, managing secure access to shared semantic models in Microsoft Fabric, and implement the solution step-by-step.
If you prefer a video format, check out the tutorial on YouTube:
For those who enjoy diving into the details, let’s get started!
End-to-end Implementation of Shared Semantic Models
Implementing shared semantic models in Microsoft Fabric requires a well-structured approach to balance security, governance, and accessibility. In this section, we build upon the architecture discussed in the previous post. This architecture is designed to accommodate the unique needs of enterprise-grade BI environments, where roles are clearly split between those responsible for creating and managing the semantic models, the report writers leveraging these models for reporting and analytics, and the end users of these reports. This approach ensures robust Row-Level Security (RLS) and Object-Level Security (OLS) mechanisms are in place while enabling seamless collaboration across the organisation.
The architecture focuses on centralising governance within the semantic model layer, with clear distinctions between development and consumption roles. This allows report writers to connect to the shared models securely without gaining access to sensitive data beyond their scope. End-users, in turn, benefit from a simplified experience, accessing only the relevant and trustworthy insights without needing to understand the complexities behind the scenes. The preceding diagram illustrates this architecture and provides a visual reference.
Configuring Fabric Admin Portal Settings
The Fabric Admin Portal serves as the central hub for managing your Microsoft Fabric tenant settings, including those critical to the operation of shared semantic models. Proper configuration is vital to ensure these models function securely and efficiently within your organisation. In this particular scenario we need to enable the Use semantic models across workspaces in the Microsoft Fabric Admin Portal. This setting enables the functionality that allows shared semantic models to be accessed by users across different workspaces in your tenant.
In practical terms, this setting ensures that:
- Centralised Semantic Models: A semantic model developed and deployed in one workspace can be securely connected to reports, dashboards, and other artefacts in different workspaces. This promotes reuse, reduces duplication, and ensures consistency in data definitions and calculations across the organisation.
- Secure Data Sharing: By enabling this setting, you maintain governance and security through the application of Row-Level Security (RLS) and Object-Level Security (OLS), ensuring that users accessing the shared semantic models only see the data and objects they are authorised to view.
- Improved Collaboration: Report writers and analysts in different teams can connect to the same semantic model without needing to duplicate data or calculations, fostering a collaborative and efficient environment while maintaining strict data security.
To manage this setting, you need the Microsoft Fabric Administrator role.
Here are the steps to configure the settings:
- Click the Settings button.
- Select the Admin portal link.
- Navigate to Tenant settings.
- Search for semantic models.
- Under Workspace settings, expand Use semantic models across workspaces.
- Enable the toggle.
- Choose how to apply this setting (best practice is enabling it for specific security groups).
- Click Apply.
Enabling this setting is crucial for shared semantic models to work across workspaces. Skipping this step would result in an unsuccessful implementation.
Grant Build Permission on Semantic Models
To enable report writers to create reports on top of a shared semantic model, they need to have Build permission on the semantic model. This permission allows them to connect to the semantic model, and build reports without exposing sensitive data. Without this step, report writers would not be able to connect to the shared semantic models, blocking them from creating the required reports.
To configure semantic model permissions you must have at least Member role on the workspace.
The following steps explain how to grant Build permission on a semantic model:
- Navigate to the desired workspace.
- Hover over the desired semantic model and click the ellipsis button.
- Click the Manage permissions option.
- Click the Add user button.
- Type in and select the desired security group or user.
- Tick the Allow recipients to build content with the data associated with this semantic model option and remove all other options (unless required in your scenario).
- Click the Grant access button.
After granting the permission you must see the permission on the Direct access tab.
To change the permission for an existing user or group, click the ellipsis button in front of the group and change their permission as shown in the following image:
So far, we have the required setup for the report writers to access the semantic model. But they will not be able to create reports if the accessed semantic model contains Row-Level Security (RLS) or Object-Level Security (OLS) unless we assign them to the required RLS/OLS role(s). This takes us to the next section.
Role Assignment for RLS/OLS in Microsoft Fabric
As mentioned earlier, report writers will not be able to create reports from an accessed semantic model if the semantic model has Row-Level Security (RLS) or Object-Level Security (OLS) applied. The reason is that, by default, users or security groups not assigned to the appropriate RLS/OLS roles are denied access to the restricted data or objects. This default behaviour ensures security but prevents report writers from accessing the necessary data to create reports. To assign users or security groups to the relevant RLS/OLS roles, we must have the Contributor role on the workspace hosting the semantic model. The following steps outline how to perform these assignments to enable access while maintaining governance and security:
- Navigate to the desired workspace.
- Hover over the semantic model and click the ellipsis button.
- Select the Security option.
- Select a desired role.
- Enter and select a user name or a security group.
- Click the Add button.
- Click the Save button.
So far we have granted all necessary rights to the report writers to create reports from a shared semantic model. The next step for the report writers is to save the reports in a workspace. This takes us to the next section.
Add Workspace Contributor Role to Report Writers
At this stage, the report writers have all the necessary permissions to create new reports from the shared semantic models. The next step is to ensure they can save these reports in a designated workspace. For this, the report writers need to be assigned at least the Contributor role on the workspace where the reports will be saved.
It is important to note that this workspace is separate from the one hosting the semantic models. While the semantic model resides in a centralised workspace for governance and security, the reports are typically saved in workspaces dedicated to specific teams, projects, or departments. Assigning the Contributor role ensures that report writers have the necessary permissions to create, edit, and manage reports within the designated workspace, while maintaining compliance with security and governance best practices. To assign the Contributor role, you must have at least the Member role on the workspace where the reports will be saved.
Follow these steps:
- Navigate to the desired workspace.
- Click the Manage access option.
- Click the Add people or groups button.
- Type in and select the name of the user or security group.
- Select the Contributor role from the dropdown.
- Click the Add button.
Note
To change the workspace role for existing people or groups, you must have the Admin role on the workspace. However, to add new people or groups, having the Member role is sufficient.
Required Access for the End-Users
At this point, everything is set for the report writers to create and save reports securely using the semantic models without compromising security and governance. The final step is to grant the necessary access to the end-users so they can view the reports.
Depending on the content delivery method approved in your organisation, end-users may need the Viewer role on the workspace where the reports are stored if you intend to give them direct access to the workspace. For scenarios involving sharing individual reports or using Organisational Apps, the required permissions and settings may differ. To keep this scenario simple, I will assume you are comfortable granting the end-users a Viewer role on the reporting workspace. Since the steps to assign this role are nearly identical to those explained in the previous section, I won’t repeat them here.
Finally, ensure the end-users are assigned to the appropriate RLS/OLS roles on the semantic model. Without this, they will only see blank reports. The process for assigning these roles is detailed in the Role Assignment for RLS/OLS in Microsoft Fabric section of this blog, so it is not repeated here.
Conclusion
Implementing shared semantic models in Microsoft Fabric requires careful planning and precise configuration to ensure security, governance, and accessibility across the organisation. In this two-part blog series, we explored the foundational concepts and end-to-end implementation steps for one of the most common enterprise-grade BI scenarios. The previous blog focused on the core concepts, including workspace management, user roles, and the importance of shared semantic models. In this post, we built on that foundation by walking through the detailed implementation process, from configuring the Fabric Admin Portal to granting permissions and ensuring the right roles are assigned to report writers and end-users.
This series goes beyond the corresponding tutorial video on YouTube, offering more in-depth explanations and practical guidance for those who want to fully understand how to manage shared semantic models effectively in a secure and governed environment.
As this is my last blog of 2024, I want to take a moment to wish you all a very happy New Year and a strong, successful start to 2025. Thank you for reading and being part of this journey!
Follow me on LinkedIn, YouTube, and X (formerly Twitter).
