Row-Level Security (RLS) in Power BI had been one of those features I understood conceptually but had never
fully implemented end-to-end. I knew the theory: one report, one dataset, different users seeing different
data. What I hadn't done was build the entire solution myself and validate it with real users and real
security groups. So I decided to create a simple lab using a SharePoint Online list of volunteers and see
how the whole process worked from beginning to end.
The SharePoint list was intentionally simple. It contained volunteer records with names, locations, and a
few other attributes. The sample data included volunteers from Iowa, Texas, and Florida. The goal was
straightforward: Iowa managers should only see Iowa volunteers, Texas managers should only see Texas
volunteers, and everyone should use the same Power BI report.
I connected Power BI Desktop to the SharePoint list and created a simple table visual showing First Name,
Last Name, State, and City. At that point, every volunteer appeared in the report. Nothing was filtered and
everyone would see the same data. This established the baseline before introducing security.
Next, I opened the Manage Roles feature in Power BI Desktop and created my first role named IowaOnly. Rather
than doing anything complicated, I created a filter that simply returned records where State equaled Iowa. I
then created a second role named TexasOnly that filtered the data to Texas records. The goal wasn't to build
enterprise-grade security right away. The goal was simply to understand how RLS worked under the
hood.
One of the most useful features in Power BI Desktop turned out to be View As. This allowed me to simulate
what a user would see if they belonged to a specific role. When I selected the IowaOnly role, the report
immediately changed to display only Bob Jones and John Doe. The Texas and Florida volunteers disappeared.
Switching to the TexasOnly role showed only Carol and Dave. That was the first real "aha" moment because the
report itself never changed. The same report simply returned a different set of records depending on the
security role being applied.
Once local testing was successful, I published the report to Power BI Service. This is where the exercise
became less about reporting and more about governance. RLS isn't really a reporting feature. It's an
identity and security feature. The challenge shifts from building visuals to determining who should be able
to see which data.
To make the solution more realistic, I created an Entra ID security group called Volunteer Power BI - Iowa
Managers. Rather than assigning users directly to the Power BI role, I assigned the group to the role. This
immediately demonstrated one of the strengths of integrating Power BI with Microsoft 365. User management
stays in Entra ID while data visibility is controlled in Power BI. The role assignment became IowaOnly →
Iowa Managers Group → Users.
Of course, the project wouldn't have been complete without a little troubleshooting. Initially, I added my
administrator account to the security group and tested the report. To my surprise, I could still see all
records. My first thought was that RLS wasn't working. After some investigation, I realized I was testing
with the workspace administrator account. It turned out to be a useful lesson: administrators are often poor
test accounts because elevated permissions can complicate security validation.
To properly test the configuration, I created a separate user account named Shaun Member and temporarily
assigned a Power BI Pro license. The account was added to the Iowa Managers security group and granted
Viewer access to the workspace. This setup closely matched the way a real end user would interact with the
report.
When I signed in as the test user and opened the report, everything worked exactly as intended. Only Iowa
volunteers appeared. Texas and Florida records were completely hidden. The entire chain had been validated:
SharePoint list, Power BI dataset, RLS role, Entra security group, user membership, and filtered report
output. Seeing only the authorized records was a satisfying confirmation that the design worked from end to
end.
What surprised me most was how much this exercise resembled SharePoint administration and governance work.
The technical implementation was actually relatively easy. The harder part was thinking about users, groups,
permissions, ownership, and security boundaries. The report itself was one small part of the solution.
Identity and governance were the bigger picture.
By the end of the lab, I had gone far beyond simply reading about Row-Level Security. I had designed roles,
tested them locally, published them to the service, integrated them with Entra security groups, and
validated the solution using a separate user account. More importantly, I gained a better understanding of
how Power BI fits into the larger Microsoft 365 ecosystem.
This lab used simple, static roles such as IowaOnly and TexasOnly. In a production environment, I would
likely move toward dynamic RLS using a security mapping table and USERPRINCIPALNAME() to automatically
determine which records a user should see. But for a first implementation, keeping the design simple made it
much easier to understand the moving parts and follow the security chain from beginning to end.
Sometimes the best way to learn a technology is not by reading documentation or watching a tutorial, but by
following one question to its logical conclusion. For this project, that question was simple: how do I let
people use the same report while only seeing the data they're authorized to view? The answer turned out to
be a surprisingly enjoyable journey through Power BI, Entra ID, security groups, governance, and Row-Level
Security. 🐦🐦