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.
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.