How to implement tenant-based RLS in Power BI when users authenticate via ERP (not Power BI)?

[a_thiefffffffff]

We recently updated our semantic model strategy for financial reporting in a multi-tenant environment. Initially, we planned to use a single semantic model for all reports, but as client numbers will grow and this will cause performance and concurrency issues when multiple clients refreshed or created reports simultaneously. The new approach is to create separate semantic models per report type (e.g., AR, AP, P&L), which all clients of a tenant can access. However, Row-Level Security (RLS) remains a challenge, as users access reports embedded in our ERP and must only see their own tenant’s data and never other tenants’ data or tables. We’re looking for guidance on implementing secure, scalable RLS for embedded multi-tenant analytics, whether dynamic RLS by TenantId is sufficient, or if dataset-level isolation per tenant is preferable, and any Fabric best practices for this scenario.

[v-aatheeque]

Hi @a_thiefffffffff 

Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.

[v-aatheeque]

Hi @a_thiefffffffff 

Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.

[a_thiefffffffff]

Hello, sorry for the delayed response. The requirments were changed and i have updated my question.
Please go through it once and share ur views accordingly.

[v-aatheeque]

Hi @a_thiefffffffff 

Thanks for clarifying that users are authenticating through your ERP. In this setup, the key is to ensure Power BI receives the correct Entra identity when embedding. You can achieve this with EffectiveIdentity in Power BI Embedded, which lets your ERP pass the user’s Entra UPN  into the dataset.

From there you can implement dynamic RLS by maintaining a Tenant Security table (TenantID - UPN/GroupID) and filtering your fact tables accordingly. This way, each tenant only sees their own data  even though they’re logging in via ERP.

If your ERP doesn’t natively integrate with Entra ID, you will need to configure it so that the Entra identity is passed through during embedding , otherwise RLS won’t apply correctly.

[tayloramy]

Hi @a_thiefffffffff, 

How exactly is the data accessed in the ERP? 

What is the storage mode of the models? 

If the models are in import mode, then RLS needs to be handled in the model itself, which would mean that the ERP needs to somehow pass the user's identity back to the model when a user is accessing it. 

If the model is in DirectLake mode, then RLS can happen at the fabric data store level (either SQL RLS at a warehouse, or OneLake Security RLS at a lakehouse) but the ERP still needs to pass through the identity of the user. 

[a_thiefffffffff]

Hello, sorry for the delayed response. The requirments were changed and i have updated my question.
Please go through it once and share ur views accordingly.

[Poojara_D12]

Hi @a_thiefffffffff 

The recommended pattern is identity-based dynamic RLS using Entra ID (Azure AD), not hard-coded tenant IDs or app-level filters. You create a Tenant Security table in the model that maps ClientTenantID → Entra User Principal Name (or Entra Group ID), relate it to your fact tables on TenantID, and write an RLS rule like

[UPN] = USERPRINCIPALNAME() or CONTAINSROW(Security[GroupId], USEROBJECTID()).

When clients sign in through your ERP and Power BI is embedded with SSO (EffectiveIdentity), Power BI passes the user’s Entra identity into the dataset, and the same semantic model securely filters each tenant’s data. This scales cleanly to hundreds of tenants, avoids duplicating models, and keeps all isolation enforced inside the Power BI semantic layer.

[a_thiefffffffff]

Hello, sorry for the delayed response. The requirments were changed and i have updated my question.
Please go through it once and share ur views accordingly.