Is this a bug? -- Found something while working with my company's capacity

[ARUNnambiar123]

So recently we had a overhaul to how we manage our BI and in the effort, we renamed all our workspaces to a standardized naming convention.

In this process some reports were reported to be broken, on closer inspection > I found out that this break only happens to DIRECT QUERY + Dataset to Dataset connection.

Basically if I had a report directly connected to a dataset (in direct query mode) in a different workspace, and the workspace was renamed > it would automatically reflect in the report too without any issues (I believe in this scenario Group ID is used instead of workspace name).

It also works if dataset is connected to multiple datasets in direct query mode, it would adjust the workspace name change.

But a very few reports, that had a single source + a local model for maybe measure table etc, couldnt recognize this workspace name change and the visuals broke.

Thought this was interesting and could share my experience with the community and Microsoft.

[v-hashadapu · Accepted solution]

Hi @ARUNnambiar123 , Thank you for reaching out to the Microsoft Community Forum.

In Power BI, composite models, the ones where a report connects to another dataset in DirectQuery mode and also has its own local model store the workspace name directly inside their connection string. When a workspace is renamed, that connection string doesn’t automatically update. As a result, the model keeps trying to reach the old workspace name, which no longer exists and that’s why visuals fail with the connection could not be made error.

This doesn’t affect every report because not all connections are built the same way. Reports that connect directly to another dataset without adding a local model typically use the workspace ID behind the scenes. Since the ID doesn’t change when you rename a workspace, those reports continue to work fine. But once a local model is introduced, Power BI stops relying solely on the ID and instead stores the workspace name explicitly, which is why only those composite models break.

The fix is straightforward, though tedious if you have many reports. For each affected PBIX file, open it in Power BI Desktop and reconnect it to the dataset in the newly renamed workspace. That forces Power BI to rewrite the connection string with the correct workspace path. If you have a large number of reports, you can automate this with Tabular Editor or PowerShell by replacing the old workspace name in the connection string across all affected models.

Composite model guidance in Power BI Desktop - Power BI | Microsoft Learn

Use composite models in Power BI Desktop - Power BI | Microsoft Learn

Connect to semantic models in Power BI - Power BI | Microsoft Learn

[ARUNnambiar123]

Thanks for the explaination Hashadapu!

[ARUNnambiar123]

Basically it doesnt recognize the old workspace name anymore (the above screenshot is incomplete to mask data.

[ARUNnambiar123]

That is my suspicion aswell Mohit, thanks for reaffirming it. This has made a very big overhead for me as I have to manually go and reselect the dataset from correct workspace for many reports (or rename the workspace to its old name), haha. I hope Microsoft see's this too.

If it was a widely happening issue, probably it would've felt like its by design. This doesnt as it works for all cases except composite models.

[mohitkumawat]

Hi @ARUNnambiar123 ,

That is a very insightful observation and a great piece of information to share with the community.

Probably the code that checks and updates connection string after a workspace is renamed, has been designed in such way to alter workspaceName component only for simple externally sourced dataset. When it hits a Composite Model (which is essentially just a new, local Power BI model) it may either ignore or update what the workspace Name should be for the remote Direct Query source.

The visuals break because the underlying M query that references the remote data is still pointing to the old, non-existent workspace name.