Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks work through a distinction that trips up many data teams when designing secure BI environments: the difference between Role-Level Security and Row-Level Security, and how each one applies differently depending on where in the stack the access control needs to happen. The conversation is practical and specific, covering how these two mechanisms work in Azure and Data Lake environments and where Power BI fits into a complete security architecture.
For any team responsible for ensuring that users see the right data and only the right data, this episode provides a clear and actionable framework for designing that access correctly from the start. See how Blue Margin’s Managed Analytics & Insights builds role-based and row-level security into every reporting engagement, ensuring that the right people see the right data without exposing what they should not.
What This Episode Covers
Role-Level Security (0:51 – 1:31)
Role-Level Security governs access at the file or folder level within a data lake. An HR employee accessing HR folders is the straightforward example: access is granted or restricted based on the role the user holds within the organization, typically managed through directory groups like Active Directory. This is the appropriate mechanism for controlling which parts of the data lake a user can reach, but it operates at the file level rather than the record level.
Row-Level Security in the Data Lake (1:40 – 2:02)
Row-Level Security restricts visibility to specific records within a dataset rather than controlling access to files or folders. Implementing this at the data lake level is fundamentally difficult because access to a file in a data lake typically means visibility to all of the data within that file. The architecture of a data lake is not designed to enforce record-level filtering, which means a different layer of the stack needs to handle that responsibility.
Implementing Row-Level Security in Power BI (3:06 – 3:56)
Power BI is the recommended layer for implementing Row-Level Security. By creating models and rules within the report that filter data based on the identity of the signed-in user, the reporting layer enforces the record-level access controls that the data lake cannot. This approach keeps the data lake as a raw storage environment while delegating the nuanced access filtering to the tool that is built to handle it.
Data-Driven Security (6:39 – 7:38)
The most flexible and scalable approach to Row-Level Security is data-driven security, where users are associated with specific records, such as deals or clients, directly within the data itself. Rather than relying on manually maintained group permissions that require administrative updates every time an assignment changes, data-driven security allows the access rules to update dynamically as the underlying data changes. The result is a security model that stays current without requiring ongoing maintenance every time the business reorganizes or reassigns accounts.
Best Practices
The hosts offer two rules of thumb that are worth treating as defaults rather than guidelines. First, if a user has access to a file in a data lake, assume they can see everything inside it and design accordingly. Second, if the goal is to restrict data access at the record level, do not provide raw data lake access to those users at all. Route them through a reporting layer like Power BI where Row-Level Security can be enforced reliably. Trying to implement record-level filtering at the data lake layer is the architecture mismatch that causes security gaps.
Who It’s For
This episode is worth your time if you are a data engineer or solutions architect designing a secure data environment in Azure and need to understand where each type of access control belongs in the stack, a Power BI developer implementing Row-Level Security and wanting a clearer picture of why it is handled at the reporting layer rather than upstream, a technology or security leader evaluating the access control architecture for a data platform that needs to serve users with different visibility requirements, or any organization that has given users raw data lake access and is now trying to understand whether that decision created security exposures it did not intend.
Why It’s Worth a Listen
The Role versus Row distinction is one of those conceptual gaps that seems minor until a security design decision is made based on a misunderstanding of which mechanism applies where. This episode closes that gap clearly and connects each concept to the specific layer of the architecture where it should be implemented, which is more useful than a definition that stops at what each term means.
The data-driven security recommendation is the most forward-looking part of the conversation. Manual group permission management is a maintenance burden that grows with organizational complexity and falls behind every time the business changes faster than the permissions do. Building access rules into the data itself is a more durable architecture for environments where user-to-record assignments change frequently, and understanding why that approach is preferable changes how security requirements get translated into technical design.
And the best practice around raw data lake access is worth treating as a design principle rather than a guideline: if record-level filtering is a requirement, the reporting layer is where it belongs. Designing around that principle from the start avoids the more difficult conversation of trying to add record-level security to a data lake architecture that was not built to enforce it.
