Issue with Refresh After Take Over – SSO-Enabled Direct Query Dataset

[bdpr_95]

Hi everyone,

We're facing an issue with a semantic model in Power BI Service.

In summary:

• The original author published the semantic model and is able to refresh the report using their credentials.
• However, when a colleague tries to take over the dataset and refresh it manually using their own credentials, they receive the following error:

"We cannot refresh this dataset because the dataset contains calculated tables or calculated columns based on data from a Single Sign-on (SSO)-enabled Direct Query data source. Please configure the dataset to use an explicit connection with granular access control to access this data source and then try again."

We’ve already validated that both users have the same access to the data source. Additionally, the user who gets the error in Power BI Service is able to refresh the semantic model successfully in Power BI Desktop.

Can anyone help us understand:

• Why is one user able to refresh while the other gets this error?
• What steps can we take to resolve this issue?

Thanks in advance for your support!

[v-achippa]

Hi @bdpr_95,

Thank you for reaching out to Microsoft Fabric Community.

Thank you @AmiraBedh and @tayloramy for the prompt response. 

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa

[v-achippa]

Hi @bdpr_95,

We wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa

[v-achippa]

Hi @bdpr_95,

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa

[tayloramy · Accepted solution]

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:

1. 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.
2. 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. 
3. 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.

[AmiraBedh]

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.

https://powerbi.microsoft.com/en-us/blog/enabling-granular-access-control-for-all-data-connection-ty...

[bdpr_95]

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?

[AmiraBedh]

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.