Power BI semantic models have the option to set up row-level security (RLS). And this includes Direct Lake Power BI semantic models in Microsoft Fabric!
Editing a Direct Lake semantic model and editing it on the web can be used interchangeably! Previously any XMLA edit would mean you couldn’t edit on the web anymore and RLS UI is now available to set up RLS on Direct Lake semantic models when editing them on the web!
Prerequisites:
- Turn on your Microsoft Fabric trial or have access to a paid Microsoft Fabric capacity.
- Create a workspace and make sure it’s in the Trial or Fabric capacity.
- Create a Lakehouse and populate delta tables with data.
- Create a New semantic model from the Lakehouse or SQL analytics endpoint or Warehouse.
- Turn on editing of data (semantic) models for the workspace.
Workspace Settings > Power BI > General > Data model settings

A critical part not to forget is that RLS should be used with a fixed identity.
The default link between the Direct Lake semantic model and the Lakehouse relies on single sign-on authentication. This means that whoever views the report accesses the Lakehouse delta table data using their credentials. However, it’s advisable to switch this to a fixed identity setup. In a fixed identity scenario, the model owner configures their credentials within the semantic model settings, ensuring they’re consistently utilized regardless of the viewer. The Role-Level Security (RLS) in the semantic model still recognizes the viewer and enforces the relevant RLS rules for that user. Nevertheless, the model accesses the Lakehouse table data using the fixed identity credentials to present the visuals in the report.
To change to fixed identity:
- Go to the workspace, find the semantic model, and in the context menu choose Settings.
- Expand Gateway and cloud connections.
- In the drop down you should see “Single Sign-On”. Choose New connection.
- Enter the name, choose OAuth 2, click Edit credentials (to add your credentials), then Create.

- Important step! Again, expand Gateway and cloud connections and change it to the new connection you just created!

- Click Apply.
- Finally, go back to the workspace and refresh the semantic model.

Add row-level security (RLS)!
- Go to the Fabric workspace, right-click the semantic model, and choose Open data model. If it’s greyed out, be sure to check your workspace settings.
- To add the RLS, go to Manage roles from the ribbon or right-clicking the Roles section in Model Explorer.
- Click “New”, give the Role a name. Here I called mine RLS for Australia.
- Click on the table you want to limit by RLS, here I picked the geo table.
- Now I can specify a column and value to limit it by. I choose Country as the column, then limited it to Australia.

- I could Switch to DAX editor instead too by clicking that button.

- Save the Role.
- To assign who is limited by this RLS, go to the Assign tab. Here I also added Demo account as my audience to be limited to only seeing data for Australia. Then Save and Close.

Let’s do some testing of the RLS:
The View as is not available in web modeling, but you can still utilize this feature once you have created a report and published it to the same workspace.
- Go back to the Fabric workspace, right-click the semantic model, then choose Security.

- Now you should see the Row-Level Security page.

- It is very subtle, but if you hover over the role, in my case, RLS for Australia (1), ellipsis will appear with the option to Test as role!

- Click this and if you see an error, then make sure you
- Set up the semantic model as fixed identity instead of single-sign on.
- Have a report created on this semantic model in the workspace.
- And finally, if those are both ok, simply refresh the page and try again! (small bug!)
- Now you should see the report filtered correctly!

- At the top you can change which report you want to check.

- And you can even change to a different role.

Now to share and test this RLS with Demo account:
The way you share the report matters. Giving the audience viewer role on the workspace may be sharing too much, as if that is where the Lakehouse is, they can now go to the Lakehouse and see all the rows of data. They will still be limited when they view the report, but it’s essentially a gate without a fence. Giving the audience viewer permission via the organizational app means you can now be specific on what reports in the workspace they can see as well, which gives your gate a nice fence.
- I created a report in the Power BI service (I could have created it in Power BI Desktop with a live connection and published the report too).

- I now share my report as in a Power BI app.

And share it with just Demo user or the whole organization.

This ensures viewer access to the report only, through the semantic model that I set up the RLS on, and not the Lakehouse directly (where they are not limited on what they can see). For them to see any data in the report, the semantic model should be accessing the data in the Lakehouse using fixed identity as noted above, as the semantic model needs credentials of someone who does have access to the data.
Alternatively, I could add my Demo user account to the workspace as a Viewer. As a viewer, Demo will see the report limited per the RLS rules on the semantic model. In this case, only seeing Australia’s data. But especially for Direct Lake, this is not recommended. The Lakehouse is also an artifact in the same workspace. This means Demo can go to the Lakehouse and see data for all countries, if they wanted to. The semantic model only impacts downstream artifacts, such as reports. Upstream artifacts are not limited by the semantic model RLS. Other workspace roles, such as Member, Contributor, and Admin, can edit the workspace semantic models, so users with those roles are also not limited by RLS.
I can give the published app link to my Demo account.

- Now if I log in as Demo and view the same report using the app link, I see only Australia!

If they instead see this error “You don’t have permission to view the content of Direct Lake table”, then you may not have changed the semantic model connection to a fixed identity.

Additional things to keep in mind.
- The RLS is only applied to the semantic model and its downstream reports (check the lineage view). If I added Demo to the workspace as viewer, they can go to the Lakehouse or SQL analytics endpoint and still see all countries data. I would need to set up additional RLS at that layer to limit what they see there. Alternatively, I should publish the report in an app and give Demo viewer permission only to the report as part of that process, so they can’t access the Lakehouse directly.
- If RLS is set up for Demo at the upstream layer of the SQL analytics endpoint, then unfortunately Direct Lake will fallback to DirectQuery. Not only can the report be slower but also keep in mind that the RLS/OLS defined at the SQL Analytics Endpoint will apply too, in addition to the semantic model RLS.
- The default connection from the Direct Lake semantic model to the Lakehouse is single sign on. This means the person looking at the report will access the Lakehouse tables using their credentials. You can change this to be a fixed identity. Fixed identity is when the model owner goes into the semantic model settings and specifies their credentials to be used no matter who is looking at the report. The RLS in the semantic model will still know who is looking at the report and apply the semantic model RLS rules for that user. However data will be accessed with the fixed identity credentials to load the visuals from the Lakehouse.
Priyanka P Amte