If you’ve set up row level security in Power BI before, you know the usual drill: open the semantic model, add a role, write a DAX filter. But once your data lives inside a Microsoft Fabric OneLake structure, there’s a better way to do this. You can implement it directly in OneLake instead, so that every object built on top of that data, your lakehouse, your SQL analytics endpoint, your semantic model, and your report, all follow the same security setup automatically. Define it once, upstream, and everything downstream inherits it. This is called OneLake security, and in this post I’ll walk through exactly how to set up row level security (RLS) this way, from the lakehouse all the way to your Power BI report.
What Is OneLake Security (Video: 0:00)
When your data lives inside a Microsoft Fabric OneLake structure, there’s a better way to set up row level security than defining it inside your Power BI semantic model. You can implement it directly in OneLake instead, so that every object built on top of that data, your lakehouse, your SQL analytics endpoint, your semantic model, and your report, all follow the same security setup automatically. Define it once, upstream, and everything downstream inherits it. This is called OneLake security.
Quick Recap: What Is Role Level Security (Video: 1:01)
If you’ve watched previous videos on role level security and dynamic role level security, this will feel familiar. In short, role level security is the configuration you define so that each user only sees their own slice of the data, a sales manager for California sees California’s sales, a sales manager for another state sees that state’s data, and so on. You define this as row-level filtering logic, which is why it’s called row level security.
Traditionally, this has been applied inside the Power BI semantic model, with static and dynamic RLS options available depending on your scenario. But now that Fabric stores all your data in a single unified layer called OneLake, there’s a better option: define the security once inside OneLake, and let every object built on top, semantic model, lakehouse, warehouse, SQL analytics endpoint, and report, inherit that same configuration. No more configuring security separately at every layer. Your SQL developers, your self-service Power BI users, and your end users all fall under the same governed security setup.
Prerequisites for OneLake Security (Video: 3:08)
There are a few configurations you need in place before OneLake security will work.
First, this is a Fabric-specific capability, so your data needs to be inside a Fabric lakehouse, which means a Fabric workspace associated with a Fabric capacity. The capacity size doesn’t matter, F2, F4, F64, this works the same regardless of SKU.
In the example setup used here, the lakehouse contains four related tables: Customer, Geography, Product, and Fact Internet Sales. Querying the SQL analytics endpoint directly (SELECT DISTINCT [English Country Region Name] FROM DimGeography) shows the underlying country values: United States, France, Germany, Canada, Australia, and United Kingdom, useful context for the row level security rule built later in this post.
Direct Lake on OneLake vs Direct Lake on SQL (Video: 5:04)
This is a genuinely critical point: when you create your semantic model with the intention of implementing OneLake security, you should use Direct Lake on OneLake as the storage mode, not Direct Lake on SQL. There are real differences between the two, and Direct Lake on OneLake gives you the most flexibility for this scenario. Direct Lake on SQL has its own set of configurations that are useful elsewhere, but for row level security specifically, Direct Lake on OneLake is the strongly recommended option.
The example semantic model isn’t a fully star schema model (Geography is connected through Customer rather than being part of it directly), but the relationships still filter correctly in one direction: filtering Geography filters Customer, which in turn filters Fact Internet Sales.
Setting the Data Access Mode to User Identity (Video: 6:57)
Beyond choosing Direct Lake on OneLake, there’s one more required setting. Under your SQL analytics endpoint, go to Security, then Data Access Mode Configuration, then Data Access Mode Settings. Set this to User Identity Access Mode, rather than Delegated Identity.
Delegated identity effectively runs everything under a single service account. User identity access mode, by contrast, captures who the actual logged-in user is and applies security based on that identity. This setting is essential for row level security to work correctly, since without it, the semantic model has no way to know which user is querying and therefore can’t apply a personalized filter. It’s likely that most semantic models will default to this mode in the future, given how central it is to this kind of governed security setup.
Building and Sharing the Report (Video: 8:00)
With the semantic model built (Direct Lake on OneLake, User Identity access mode), a simple report was created on top of it: a column chart showing sales amount by country, and a table visual breaking sales down by country and state. At this point, without any security configured yet, the report shows every country and state in the dataset.
Sharing the workspace with a test user (via Manage Access, using an Org App is the recommended sharing method, covered in more detail in a separate video), with Viewer access granted, sets up the scenario for the next section.
What Happens Without OneLake Security Configured (Video: 9:33)
Opening the report as that test user, in a separate browser session with Viewer access only, initially produces an error. The message indicates the user doesn’t have access to the underlying data. This happens precisely because User Identity access mode is enabled, it correctly requires the user to actually have access to the underlying data, and at this point, that access hasn’t been granted yet. This is the exact gap that OneLake security fills.
Creating a Role in OneLake Security (Video: 10:10)
This is the core of the whole setup. Under Manage OneLake Security, there’s always a default Reader role with access to every table in the semantic model, the test account used here already sits at that permission level. Simply adding the new user to that default role would give them access to everything, which isn’t the goal.
Instead, create a new role. In this example, it’s named “Australia Canada Role,” intended for users who should only see sales data for Australia and Canada. Choose Grant (as opposed to Deny) permission, and select Read access, since this role is meant for querying data, not writing to it.
Writing the SQL Row-Level Filter (Video: 11:44)
The next step defines exactly which data this role can access. Choosing “Selected Data” (rather than “All Data,” which applies no row level security at all) opens an Edit option where you pick the specific table and column to filter.
In this case, the filter applies to the Geography table, on the country name column. Selecting that table opens a Data Access tab, where the actual filtering logic is written, this time as a SQL statement rather than the DAX expression used in traditional Power BI RLS. The syntax is case-sensitive, keywords in lowercase may not show an error immediately but will fail when you try to save, so it’s worth being careful here. The working filter used in this example is:
SELECT * FROM Geography WHERE [English Country Region Name] IN ('Canada', 'Australia')
Column level security can also be configured from the adjacent tab if needed, though this particular video focuses only on row level security.
Applying Security Across Related Tables (Video: 13:48)
Filtering the Geography table alone isn’t sufficient, since sales amounts live in the Fact table and customer records live in the Customer table, not in Geography itself. Each additional table needed by the role has to be selected as well. You can apply row level security filters to multiple tables individually if needed (see dynamic RLS with Exclude and Include rules and dynamic RLS with NOT IN or NOT EQUAL rules for more advanced multi-table RLS patterns in Power BI), or simply select the remaining tables without an additional filter if Geography is the only table that needs one.
After selecting the required tables and clicking Add Data, the resulting configuration is reviewed: Geography is the only table with an explicit row level filter, but thanks to the model relationships, that filter propagates correctly to the related tables as well.
Assigning Members to the Role (Video: 15:04)
The final step in defining the role is specifying its members. Best practice here is to assign security groups rather than individual users, since adding or removing someone from a security group when they join or leave a team automatically updates every place that group is referenced. For this demo, the specific test user was added directly to illustrate the behavior.
Testing the Report as the Restricted User (Video: 16:07)
After creating the role, refreshing the report (the security configuration typically applies quickly, though timing can vary) shows the difference clearly. The original, unfiltered report showed every country with total sales of $29 million. After the OneLake security role takes effect, the same test user now sees only Canada and Australia, and only the states within those two countries, with sales totals adjusted accordingly. Crucially, none of this required defining any row level security inside the semantic model itself, the security defined once in OneLake flowed through automatically.
Testing the SQL Analytics Endpoint (Warehouse) (Video: 17:02)
The same restricted user querying the warehouse directly, rather than going through the report or semantic model, sees the identical restriction. Running:
SELECT DISTINCT [Country Name] FROM DimGeography
returns only Canada and Australia, exactly matching the report-level restriction. This confirms the core value of OneLake security: the same row level security rule applies consistently across the semantic model, the report, and direct SQL queries against the warehouse or lakehouse, all from a single configuration point.
Why OneLake Security Matters (Video: 18:03)
OneLake security isn’t limited to this one scenario either, it also works with mirrored sources and shortcuts, with its own set of configuration details worth covering in future videos, along with column level and object level security, which follow a similarly straightforward setup.
The core benefit is architectural: instead of defining security separately at the object level, in the warehouse, in the lakehouse, and in the semantic model, you define it once at the base data layer, and every object built on top inherits that configuration automatically. This is a significantly more governed approach, and considerably easier to maintain. When something needs to change, there’s exactly one place to update it, rather than hunting down every object where security logic was duplicated.
Summary (Video: 19:04)
That’s OneLake security in a nutshell: one configuration, applied at the data layer, followed by every object built on top of it. If you’ve been maintaining separate RLS setups across your semantic model, warehouse, and lakehouse, this is worth the switch. If you try this and get stuck, let me know in the comments, I read every one of them.
Related Reading on RADACAD
- Dynamic Row Level Security with Power BI Made Simple
- Dynamic Row-Level Security in Power BI with Exclude and Include Rules
- Dynamic Row-Level Security in Power BI with NOT IN or NOT EQUAL Rule
- Microsoft Fabric Lakehouse
- Power BI Direct Lake, What Is It and Why It Is Important
- Mirroring Snowflake in Fabric: Supercharged Analytics at No Extra Costs
- Saying Yes to Fabric OneLake Shortcuts, No to Duplicate
About Reza Rad
Reza Rad is a Microsoft Regional Director and a 16-year consecutive Microsoft Data Platform MVP, recognized as one of the world’s leading voices on Power BI and Microsoft Fabric. He is co-founder of RADACAD, a Microsoft Gold Partner delivering Power BI and Fabric consulting and training to organizations across 80+ countries, and co-founder of the Difinity Conference and the Power BI & Fabric Summit. Reza has authored more than 10 books on Power BI and Microsoft BI technologies, published over 1,000 technical articles, and personally trained thousands of data professionals worldwide. Whether you need a full analytics architecture built from the ground up, a stuck DAX formula or performance issue solved, or a team trained from the basics to advanced Fabric implementation, Reza and the RADACAD team offer both hands-on consulting and structured training to get you there. Learn more at radacad.com.
Reza is author of more than 14 books on Microsoft Business Intelligence, most of these books are published under Power BI category. Among these are books such as Power BI DAX Simplified, Pro Power BI Architecture, Power BI from Rookie to Rock Star, Power Query books series, Row-Level Security in Power BI and etc.
He is an International Speaker in Microsoft Ignite, Microsoft Business Applications Summit, Data Insight Summit, PASS Summit, SQL Saturday and SQL user groups. And He is a Microsoft Certified Trainer.
Reza’s passion is to help you find the best data solution, he is Data enthusiast.
His articles on different aspects of technologies, especially on MS BI, can be found on his blog: https://radacad.com/blog.