An occasional Direct Query connection error with the Power BI semantic model when using the RLS role

[TatsianaS]

License type: Pro

The data model consists of:

• Users, Orgs tables, which are part of another Power BI dataset 'SecurityRoles' that is linked to the current main report. So there is Direct Query connection to these tables. We've put these security tables into the separate DataSet to not impact the main report if any updates in the user access.
• the table dimOrganization is imported into the current main report;

RLS role filter is set up at dimOrganization and looks like: 

VAR _CurEmp= CALCULATE(SELECTEDVALUE(Users[userid]), Users[email]=USERPRINCIPALNAME ())   /*find EmpID of logging user*/
VAR _Org = CALCULATETABLE(VALUES(Orgs[OrgID]), Orgs[EmpID]=_CurEmp)   /*find OrgID by the current user*/
RETURN If(COUNTROWS(_Org) > 0,  [OrgCode] IN _Org, true() )

As a result, the RLS role works but sometimes the users get the error with connection to DQ table like this:

An error was encountered during the evaluation of the row level security expression on the table dimOrganization Error message: OLE DB or ODBC error. A connection could not be made to the data source with Name of {"protocol":"analysis-services","address":{"server": "power bi"://"api.powerbi.com/v1.0/myOrg/Main%Report, "database":"DataSet SecurityRoles"}, "authentication":null, "query":null}

Have you encountered this issue before, or do you have any ideas on how to resolve it?

I would appreciate any response.

[SolomonovAnton · Accepted solution]

Why the RLS sometimes breaks

Your role filter on dimOrganization calls two tables (Users, Orgs) that live in a remote Direct Query source (“SecurityRoles” semantic model). In a composite model this is officially unsupported—an RLS rule defined in the local model cannot reference a table that sits in another source group, and local RLS never flows to remote tables. :contentReference[oaicite:0]{index=0}

When the expression engine tries to open a connection to the remote semantic model during role evaluation it sometimes finds that model busy (refreshing, paused, hitting capacity-concurrency limits, or the viewer lacks Build permission). The engine then surfaces the generic “A connection could not be made … analysis-services” message you see. Similar threads report the identical stack trace on composite models that query another dataset. :contentReference[oaicite:1]{index=1}

How to verify the root cause

• Open Impact analysis & Lineage for the main report and make sure the chain shows only 3 hops at most (the documented limit).
• Check the refresh history of the “SecurityRoles” dataset. If the failure windows overlap its scheduled/ on-demand refresh, that’s your smoking gun.
• Look in Capacity Metrics → Query wait time; spikes around the error time imply concurrency contention.
• Confirm every consumer has at least Read + Build permission on the “SecurityRoles” semantic model (needed for chained queries).

Recommended design patterns

1 · Keep RLS completely local (simplest)

1. Import the small Users and Orgs tables into the main model (or switch them to Dual mode if you still need live look-ups).
2. Create relationships Users[EmpID] → Orgs[EmpID] and Orgs[OrgID] → dimOrganization[OrgID].
3. Use a minimal role on the Users table:

[Email] = USERPRINCIPALNAME()

The relationship graph will propagate the filter to dimOrganization; no cross-source calls are issued.

2 · Or push security upstream

If you must maintain the separate SecurityRoles dataset, define the RLS inside that model and grant only Build/Read permissions to the downstream report. The local model then need not reference the user table and can rely on the remote engine to enforce its own rules (note: those rules will not filter imported tables in the main model, so this only works if every table you want secured lives in the upstream dataset).

3 · Operational mitigations (quick fixes)

• Move the SecurityRoles refresh schedule outside business hours.
• Turn on Large Model Storage Format for the security dataset to reduce processing lock time.
• If you are on Premium, raise the Max concurrency setting or split the security model onto a dedicated capacity.

Next steps to test

• Clone the PBIX, import the security tables locally, re-publish to a test workspace, add yourself to the role, and validate that the error disappears.
• Watch the Refresh History and Capacity Metrics for at least one business day for any residual failures.
• Once stable, migrate the change to production and retire the cross-source RLS logic.

---

Need a lightweight alternative? Use a query parameter to pull the two security tables as Import once every 15 minutes—refresh is milliseconds because they are tiny, but they stay local for RLS.

✔️ If my message helped solve your issue, please mark it as Resolved!

👍 If it was helpful, consider giving it a Kudos!

[TatsianaS]

@SolomonovAnton , @v-echaithra Thank you for response. We'll try your solutions.

[v-echaithra · Accepted solution]

Hi @TatsianaS ,

Thank you for reaching out to Microsoft Fabric.

Intermittent Directquery connection errors during RLS evaluation in Power BI, especially with composite models and linked datasets, often stem from timing or latency issues, authentication context problems, and inherent limitations of applying RLS across linked datasets. Since your security tables are accessed via DirectQuery from a separate dataset, transient connectivity drops, token refresh delays, or service throttling can cause these errors. To mitigate this, consider importing the security tables into the main dataset to avoid cross-dataset dependencies, simplifying the RLS logic to reduce query complexity, or combining user-to-organization mappings into a single imported table. Additionally, ensure the data gateway and data source connections are stable, monitor for patterns in error occurrences, and avoid relying solely on viewer permissions in workspaces by publishing reports as apps with controlled access. If issues persist despite these changes, reaching out to Microsoft support is advisable, as some service side constraints may contribute to these intermittent failures.
Create a simplified test report with just the security tables and RLS logic to see if errors persist. This helps identify if the problem is with the RLS expression or the interaction with the main model.
Ensure that the linked SecurityRoles dataset is fully refreshed and that user permissions haven’t changed recently. Stale or inconsistent permissions can cause failures during RLS evaluation.
If possible, increase timeout settings on your data gateway or source to allow longer-running DirectQuery calls during RLS filtering.

Please refer to these related blog and thread regarding this issue.
Row-Level Security on a DirectQuery to Power BI dataset composite model: My Findings - RADACAD
Solved: OLE DB or ODBC error. A connection could not be ma... - Microsoft Fabric Community

Hope this helps.
Best Regards,
Chaithra E.

[SolomonovAnton · Accepted solution]

Why the RLS sometimes breaks

Your role filter on dimOrganization calls two tables (Users, Orgs) that live in a remote Direct Query source (“SecurityRoles” semantic model). In a composite model this is officially unsupported—an RLS rule defined in the local model cannot reference a table that sits in another source group, and local RLS never flows to remote tables. :contentReference[oaicite:0]{index=0}

When the expression engine tries to open a connection to the remote semantic model during role evaluation it sometimes finds that model busy (refreshing, paused, hitting capacity-concurrency limits, or the viewer lacks Build permission). The engine then surfaces the generic “A connection could not be made … analysis-services” message you see. Similar threads report the identical stack trace on composite models that query another dataset. :contentReference[oaicite:1]{index=1}

How to verify the root cause

• Open Impact analysis & Lineage for the main report and make sure the chain shows only 3 hops at most (the documented limit).
• Check the refresh history of the “SecurityRoles” dataset. If the failure windows overlap its scheduled/ on-demand refresh, that’s your smoking gun.
• Look in Capacity Metrics → Query wait time; spikes around the error time imply concurrency contention.
• Confirm every consumer has at least Read + Build permission on the “SecurityRoles” semantic model (needed for chained queries).

Recommended design patterns

1 · Keep RLS completely local (simplest)

1. Import the small Users and Orgs tables into the main model (or switch them to Dual mode if you still need live look-ups).
2. Create relationships Users[EmpID] → Orgs[EmpID] and Orgs[OrgID] → dimOrganization[OrgID].
3. Use a minimal role on the Users table:

[Email] = USERPRINCIPALNAME()

The relationship graph will propagate the filter to dimOrganization; no cross-source calls are issued.

2 · Or push security upstream

If you must maintain the separate SecurityRoles dataset, define the RLS inside that model and grant only Build/Read permissions to the downstream report. The local model then need not reference the user table and can rely on the remote engine to enforce its own rules (note: those rules will not filter imported tables in the main model, so this only works if every table you want secured lives in the upstream dataset).

3 · Operational mitigations (quick fixes)

• Move the SecurityRoles refresh schedule outside business hours.
• Turn on Large Model Storage Format for the security dataset to reduce processing lock time.
• If you are on Premium, raise the Max concurrency setting or split the security model onto a dedicated capacity.

Next steps to test

• Clone the PBIX, import the security tables locally, re-publish to a test workspace, add yourself to the role, and validate that the error disappears.
• Watch the Refresh History and Capacity Metrics for at least one business day for any residual failures.
• Once stable, migrate the change to production and retire the cross-source RLS logic.

---

Need a lightweight alternative? Use a query parameter to pull the two security tables as Import once every 15 minutes—refresh is milliseconds because they are tiny, but they stay local for RLS.

✔️ If my message helped solve your issue, please mark it as Resolved!

👍 If it was helpful, consider giving it a Kudos!