Your Options for Implementing Row-Level Security on Power BI

In Ferris Bueller’s Day Off (1986), teen troublemaker Ferris pushes his best friend Cameron into a dilemma: take his father’s prized Ferrari for a joyride and risk being caught, or leave it untouched and miss out on the adventure of a lifetime. Neither option is perfect – one trades safety for speed, the other speed for safety.

Power BI customers often face a similar conundrum when choosing how to load data. Using DirectQuery gives you access to live data but has a significant performance impact on dashboards. Since, as the name implies, the source database is queried directly, any security policies that exist natively on the source database also apply in Power BI. With Import mode, on the other hand, dashboards load very quickly. However, data is only as fresh as the last import. And since the data is copied in full from the source into Power BI’s in-memory engine, security policies that exist on the source aren’t passed onto Power BI, introducing risk. 

Power BI’s connection modes force data teams into a tradeoff between speed and security. But this doesn’t have to be the case. In this blog we’ll explore how, like our friend Cameron, data teams can drive their dad’s Ferrari without the security risks that come with it. 

No dashboards were harmed in the making of this film.

As with most dilemmas, the answer to the question of whether to use DirectQuery or Import mode is, you guessed it, “it depends.” It’s often necessary to use Import Mode in situations where you can’t afford the performance detriment of DirectQuery mode. In this case, any row-level security policies that exist in the original data sources will no longer apply to the data once in Power BI. 

Row-level security (RLS) restricts access to data such that rows will only be shown to data users who are authorized to access it. This is critical for enforcing least privilege, ensuring your sensitive data is as secure as possible, and complying with security regulations. 

The following are your options for implementing RLS on Power BI in Import Mode:

Power BI has native functionality for implementing RLS policies using DAX, or Data Analysis Expressions. Data Analysis Expressions (DAX) is a library of functions and operations that can be combined to build formulas and expressions in Power BI, analysis services, and Power Pivot in Excel data models. Using DAX, data teams can implement RLS based on roles (this capability is not available in Power Pivot in Excel). These policies apply to both specific and related rows, and access is limited by simply not returning results on the allowed row set. 

Part of the reason data teams might get stuck on the implementation of RLS on Power BI is the need for users to learn DAX. While DAX syntax isn’t complicated, it’s still another language that BI analysts and report builders need to learn. DAX models are also tightly coupled to the data model as well as the visual widgets invoking the DAX, leading to multiple points of potential failure. The industry consensus is that DAX is simple, but not easy to use, and commonly causes headaches and frustration.  

DAX is also very difficult to scale. Managing translations to the DAX, including the need to add or modify permissions, is a lengthy and involved process. Using DAX to implement and modify RLS on Power BI consumes a significant amount of data teams’ time and efforts. It can work on very small data sets, but quickly becomes a full-time job.

These problems would no longer exist if there was a way to manage RLS on Power BI without the need to write DAX expressions.

Satori simplifies Power BI enforcements by using attribute-based access controls (ABAC) to dynamically design, deploy, and manage the DAX expressions and lookup tables that power Power BI’s filtering capabilities. This means you can set up rules and conditions based on attributes such as user role, department, geographical location, etc. These attributes dynamically filter data based on who is accessing the Power BI reports or dashboards. 

ABAC using Satori provides greater flexibility and scalability compared to traditional static access controls. As organizational needs evolve or as new attributes become relevant (such as new user roles or projects), these can be easily incorporated into the access control rules without significant overhead. 

Satori assigns attributes for ABAC in many ways that reduce the friction associated with implementing RLS for Power BI. This reduces the time that data teams need to spend configuring data access. Satori enables data teams to implement RLS through the use of specific attributes, including on Power BI. 

ACME Corp wants to filter data and access based on user location. 

Without DAX implementation in reports, controlling access to specific data fields requires editing the query directly. These filters can be based on specific criteria or conditions, such as excluding certain rows or columns based on user attributes. BUT…and this is a big but…this means the data loaded into the report is pre-filtered, and thus if different users need access to different data, multiple reports would need to be built. This can grow exponentially and is exactly why Power BI has implemented DAX modeling for RLS. 

In this example, Satori reduces the time and simplifies the implementation of ABAC using a Geographic RLS filter. 

Satori looks at the identity provider to determine if the user has permissions for specific states. 

Satori checks if the user has the “state” attribute configured in the IdP. If they do, they get a “state” filter. If they don’t, no rows are returned on this protected Power BI report. This creates a security approach that prevents accidental data leakage, including from internal sharing of reports.  

Satori imports this variable and records that the user has a “WA” state attribute configured in the IdP. 

Satori has added RLS to the report, producing the following Power BI view for the current user.

A different user with different permissions, in this case authorization to a wide range of states, gains access to all data. This shows the dynamic ability of using Satori with Power BI where different users with different access privileges are automatically granted access to that data, quickly and easily.

Like Cameron with his dad’s Ferrari, data teams working with Power BI often feel forced into a tradeoff: speed or security. When speed is of the essence, Import Mode requires additional effort to ensure sensitive data is secure. Native RLS using DAX offers control but creates friction, scaling challenges, and unnecessary risk. With Satori, that choice disappears. By applying attribute-based access controls dynamically, Satori lets organizations enforce row-level security at scale, without drowning in DAX expressions or managing endless report versions.

Now, as part of Commvault, Satori’s capabilities are embedded within a broader data protection ecosystem, strengthening the ability of enterprises to safeguard sensitive information. 

To see how Satori can simplify RLS on Power BI and help your organization get AI-ready, book a demo with one of our experts.