Sharing Power BI Reports with External Users – Part 1: Understanding the Problem and Core Concepts

Sharing Power BI reports with external users is a common but often misunderstood scenario. While it may seem simple on the surface, doing it properly and securely involves many moving parts. I’ve already published a video on this topic, which turned out longer than expected because of the number of details involved.

To make this blog easier to follow and more digestible, I’ve broken the content into a three-part blog series. Each part covers a focused area of the topic:

Part 1 (this blog): Understanding the Problem and Core Concepts This post explains why external sharing can be tricky, the key requirements to get it working, important terminology, user roles, and how the whole process fits together.

Part 2: Hands-On Guide to Setup and Sharing A step-by-step walkthrough of how to share reports across tenants, covering licensing, admin portal settings, inviting guest users, and how report access looks from the guest’s side.

Part 3: Sensitivity Labels, Encryption, and Secure Sharing An in-depth look at what happens when Microsoft Purview sensitivity labels are applied, including access control, encryption, and key admin settings you may need to adjust for secure collaboration.

If you are someone who prefers video over reading, you can watch the full walkthrough here 👇.

Introduction

Are you a Power BI developer or someone in a BI or finance team who needs to share reports with customers, partners, or vendors? If they are not part of your Microsoft 365 tenant, things get a bit more complex than just clicking the “Share” button.

This is a common need, especially in consulting scenarios, but doing it securely and correctly takes more than people often think. It involves both technical setup and a clear understanding of roles and terminology.

Continue reading “Sharing Power BI Reports with External Users – Part 1: Understanding the Problem and Core Concepts”

Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 2 – Implementation

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:

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!

Continue reading “Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 2 – Implementation”

Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 1 – Core Concepts

Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models - Part 1 - Core Concepts

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:

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.

Continue reading “Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 1 – Core Concepts”

Microsoft Fabric: Resolving Capacity Admin Permission Issues in Automate Capacity Scaling with Azure LogicApps

Resolving Capacity Admin Permission Issues in Automate Capacity Scaling with Azure LogicApps

A while back, I published a blogpost explaining how to use Azure LogicApps to automate scaling Microsoft Fabric F capacities under the PAYG (Pay-As-You-Go) licensing option. Some of my followers reported an issue with their Capacity Admin settings when running the LogicApp solution. The issue was that their capacity admins disappeared after they had run the LogicApps to upscale or downscale the capacity. After some investigation, I found out what the problem was. At the same time, some of my other followers suggested a fix which involved hardcoding the admins into the solution. While this would work in some cases, it is not a practical solution in the long run, as the admin settings may evolve over time. This makes the solution hard to maintain and unreliable. Back then, I suggested using the APIs and an HTTP action in a new LogicApps solution. This blog is the continuation of the previous blog and a quick and easy fix that ensures the automation runs smoothly with minimal to no manual work or maintenance afterwards. I have also published a tutorial video on YouTube explaining the process from the beginning (which was already covered in my previous blog, so I do not explain it here again) which you can watch here:

A Reminder of the Previous Solution

I suggest you read my blog about automating Fabric capacity scaling with Azure LogicApps as it provides a step-by-step guide to implement the solution. But if you have already implemented, or you are just after the fix, jump to the next section. The following image shows how the original solution works:

Automate Scaling Microsoft Fabric F Capacities with Azure LogicApps
Automate Scaling Microsoft Fabric F Capacities with Azure LogicApps

Here is a quick explanation of how it works:

  1. The Trigger runs the workflow automatically every hour.
  2. The Read a Resource, which is an Azure Resource Manager operation, reveals information about a resource that, in our implementation, is a Microsoft Fabric Capacity.
  3. A condition to check the Status of the capacity. If the capacity is Paused (the condition is true), then do nothing. This is needed as this method only works when the capacity is Active.
  4. If the capacity is Active (the condition is false), then check the current time to see if it is between 2pm and 4pm. This is the timeframe for which we want to upscale the capacity.
  5. If the condition is True, then upscale the capacity to F8 using another ARM operation: Create or update a resource.
  6. If the condition is False, then set the capacity SKU to F2.

The solution works fine if you do not have any Capacity Admin settings either on Azure Portal or on Admin Portal on Microsoft Fabric. But in many cases, we indeed have capacity admins. Let’s see what the issue is.

The Problem

The issue arises when we add some capacity administrators; that are wiped after running the above solution in its current implementation. The following image shows the Capacity Admin settings on both portals:

Fabric Capacity Admins on Azure Portal and Fabric Admin Portal
Fabric Capacity Admins on Azure Portal and Fabric Admin Portal

The reason if that the Create or update a resource also updates the properties of the resource with the ones we define in LogicApps. Therefore, if we do not add any capacity admins, we literally empty the existing capacity admins. Let’s run the solution again to understand why this is happening. The following image shows my capacity admins are wiped out after running my LogicApp workflow:

Capacity Admins deleted after running LogicApps
Capacity Admins deleted after running LogicApps

The issue is also demonstrated in the tutorial video on YouTube:

Continue reading “Microsoft Fabric: Resolving Capacity Admin Permission Issues in Automate Capacity Scaling with Azure LogicApps”