Overview
In this episode of The Dashboard Effect, Brick Thompson and Landon Oaks break down Role-Based Access Control, one of the most important and most frequently underestimated aspects of any business intelligence deployment. The conversation covers both the organizational thinking required before any technical work begins and the implementation details that determine whether a security model holds up in practice.
For any team that has either skipped this work or handed it entirely to IT without the right business context, this episode offers a clearer framework for getting it right. See how Blue Margin’s Managed Analytics & Insights builds role-based security into every reporting engagement, ensuring that the right people see the right data without exposing what they should not.
What This Episode Covers
Understanding RBAC as a Business Decision (0:45 – 2:44)
The hosts are direct about where RBAC work has to start: with the business, not the technology. Defining who should see which data requires mapping organizational hierarchies and understanding what each role, store manager, district manager, regional director, and so on, actually needs access to in order to do their job. That mapping is a business decision, and getting it wrong at this stage creates problems that are expensive to fix after the technical implementation is already in place.
Technical Implementation (3:46 – 6:40)
The most reliable approach is to pull security attributes directly from ERPs or HR systems, which serve as the authoritative source of truth for employee roles and responsibilities. Managing permissions in Excel is a common shortcut that creates ongoing risk: it is prone to human error, difficult to keep current, and impossible to audit reliably. Modern cloud environments like Microsoft Entra allow security groups to be nested in ways that handle complex organizational hierarchies without requiring manual maintenance of individual permissions.
Filtering and Testing (6:40 – 8:48)
At the technical level, RBAC works by filtering database rows based on a user’s attributes or group membership, ensuring each person sees only the data their role permits. The hosts emphasize that rigorous testing before any rollout is not optional. Running a security model past a small, trusted group first is the only reliable way to confirm that no sensitive data is accidentally exposed before the system goes live across the organization.
Who It’s For
This episode is worth your time if you are a BI or data engineer responsible for implementing security in a Power BI or similar environment, a business or operations leader who needs to understand why data access decisions require your input before the technical work begins, an IT or security professional evaluating how to manage permissions in a modern cloud BI environment, or any organization preparing to roll out dashboards to a multi-level workforce where different roles require different views of the same underlying data.
Why It’s Worth a Listen
RBAC tends to get treated as a technical checkbox rather than a design problem, and that framing is where most implementations run into trouble. The hosts reframe it clearly: the business logic has to come first, and the technology follows from it. That sequencing matters, and getting it backwards is one of the more common and costly mistakes in BI deployments.
The advice to pull security attributes from HR or ERP systems rather than maintaining a separate permissions file is practical and often overlooked. Organizations that manage access in spreadsheets spend a disproportionate amount of time keeping those spreadsheets current and dealing with the consequences when they are not. Building on a system of record eliminates that overhead and makes the security model more trustworthy by default.
And the emphasis on testing before rollout is the kind of advice that sounds obvious until a team skips it and discovers mid-launch that a regional manager can see data they should not. This episode makes the case for taking that step seriously, which is worth hearing before it becomes a lesson learned the hard way.
