Forum Discussion
Issue with Refresh After Take Over – SSO-Enabled Direct Query Dataset
Hi bdpr_95,
You’re hitting a known limitation/behavior: the model contains calculated tables/columns that reference a DirectQuery source using SSO, and in the Power BI Service those scenarios require an explicit (shareable) cloud connection with granular access control. The original publisher can refresh because the dataset is still bound to their connection; after “Take Over,” the Service enforces connection ownership/permissions and blocks refresh for the new owner until they’re granted Use permission on that explicit connection (or the model is changed). See Microsoft’s overview of granular access control and shareable cloud connections: blog and doc. Calculated tables over composite/DirectQuery sources also have specific service-side constraints: doc.
Some things to try:
- Create/Bind an explicit Shareable Cloud Connection (SCC) for the SSO DirectQuery source in the dataset’s settings (Service > Semantic model > Settings > Gateway connections > Cloud connections > “Maps to” > Create a connection). Then grant the colleague “Use” permission on that connection. Docs: create a new connection from the model’s settings, create & share SCC.
- Have the colleague Take Over again (or just refresh) after they’ve been granted Use on the SCC. With granular access satisfied, Service refresh should succeed.
- If you purposely need SSO but also use calculated tables/columns that depend on DQ, consider moving that logic to Power Query, source SQL (Import), or DAX measures (no calculated table), or refactor to avoid calculated tables over DQ to other semantic models. Guidance: composite models & calculated table caveats. Community threads with the exact error: example 1, example 2.
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
Hello !
Thank you for posting on Microsoft Fabric community.
PBI service can’t refresh a semantic model if any calculated table or column depends on a DQ source that uses SSO. PBI Desktop still works because it runs entirely under your local identity, but the service has to materialize those calcs during refresh and SSO passthrough blocks it.
After take over, the dataset is often no longer bound to the original author explicit connection and without a proper connection binding the service throws the exact message you saw.
The original author likely had the dataset bound to an explicit connection they own (or they had SSO disabled for that connection) and when your colleague took over, the dataset either lost that binding or they don’t have use this connection permission.
The quickest thing you can do, in the workspace go to manage connections and gateways and add a new connection to the source (OAuth2/service principal/managed identity as applicable) and don’t enable SSO for this connection. Grant the new owner use this connection (granular access control) and in the dataset settings, go to data source credentials and choose edit and bind the dataset to this explicit connection, then refresh.
Hi AmiraBedh, thanks for your response. The key point here is: if I do that, will the Row Access Policy defined in my data source still be applied in Power BI? That’s an important aspect to consider. I believe the best alternative in this case is to eliminate the calculated columns, correct?
Hi bdpr_95 !
If you switch from SSO passthrough to an explicit connection, your database side row access policies that rely on the end user identity will no longer personalize per user and the source will see the single connection identity. You need then have to re implement equivalent RLS in Power BI.
But if you keep SSO, the source continues to enforce its per user as designed and the blocker is only the calculated tables or columns that reference SSO DirectQuery.