Need Official Guidance on Resolving “Unable to Combine Data” Error in Power BI Service

[Stefan-Mladenov]

Hi everyone,

During the development of Power BI reports, I frequently encounter a recurring issue. In certain cases, due to specific requirements, I need to reference other tables in my M code. While everything refreshes and works perfectly in Power BI Desktop, the same report fails to refresh in Power BI Service, returning the error:

“Unable to combine data”

I understand that this error is related to different default and non-configurable privacy settings and protections in the Power BI Service environment. Sometimes, I manage to solve the issue—other times, I don’t. What’s particularly frustrating is that even when I do fix it, I can’t pinpoint why it worked.

Typically, I resolve it by tweaking small parts of the problematic query segment—such as:

• Adding Table.Buffer to break query folding,

• Wrapping steps with try ... otherwise for error handling,

• Or embedding the referenced table directly into the query logic so I’m not referencing an external query/table.

However, these fixes feel like trial-and-error rather than a reliable, official solution.

Now, I want to reach a definitive answer:
Is there a consistent and officially recommended approach to prevent and solve the “Unable to combine data” error in Power BI Service when referencing other queries is essential for the report's logic?

Please note that this table referencing is not arbitrary—it is necessary for the business logic and cannot be removed.

Any insights from the Power BI community or Microsoft Support on how to consistently and officially handle this issue would be highly appreciated.

Thanks in advance!

[Poojara_D12 · Accepted solution]

Hi @Stefan-Mladenov 

In API-based scenarios where no on-premises data gateway is used, and dynamic query referencing is essential, the most reliable way to prevent the “Unable to combine data” error in Power BI Service is to ensure all API calls and referenced queries share the same privacy level—ideally marked as “Public”—and avoid crossing privacy boundaries between queries. In Power BI Desktop, go to File > Options and Settings > Data Source Settings, locate all related web/API sources, and explicitly set their privacy levels to Public if the data isn't sensitive. Then republish the model to Power BI Service.

Additionally, structure your queries so they all reference a shared base function or query, which ensures Power BI treats them as one unified source during evaluation. You can also flatten or buffer intermediary results using Table.Buffer at strategic points to prevent Power BI from triggering separate evaluations or partitions. Avoid using try ... otherwise to patch errors, as it often hides the root problem and can still trigger privacy errors during service refresh. If the API response is complex, consider extracting reusable logic into Power BI dataflows, which often handle privacy evaluation more gracefully and allow reusing tables with clearer lineage and less error-prone merging.

By aligning privacy settings across API queries, using shared base functions, and buffering results where folding isn’t needed, you can consistently avoid this error in the Power BI Service—even without a gateway.

[v-kpoloju-msft · Accepted solution]

Hi @Stefan-Mladenov,

Thank you for reaching out to the Microsoft fabric community forum. Additionally, thank you to @Poojara_D12, for his input regarding this issue. I have identified several alternative workarounds that may assist in resolving the thread.

The "Unable to combine data" error in Power BI Service is primarily due to strict privacy level enforcement, which differs from the behaviour in Power BI Desktop. In the Service, Power BI prohibits data combination across sources with incompatible or undefined privacy levels, even if the queries are within the same file. 

This issue arises when referencing one query/table from another, as Power BI interprets it as a cross-source data combination that breaches privacy isolation rules.

Use Table.Buffer Wisely: When referencing another query, wrap it in Table.Buffer at the point of use to materialize the table and break folding:

let

    Buffered = Table.Buffer(SourceTable),

    Result = Table.SelectRows(OtherTable, each [ID] = Buffered[ID])

in

    Result

Minimize Query Dependencies: Flatten complex query chains where possible to reduce dependency evaluation issues. Embed Logic Directly: Instead of referencing an entire query, embed only the necessary logic or values into the consuming query.

Align Privacy Levels: Ensure all data sources involved have compatible privacy levels (e.g., Organizational or Public) to avoid privacy conflicts. Utilize Power BI Dataflows: For larger or more complex logic chains, consider using dataflows to offload logic and avoid combining queries within the same dataset.

The Power BI Service enforces data privacy at runtime and prevents unsafe data combinations. Although workarounds such as Table.Buffer or try...otherwise can be useful, the most dependable solution is to restructure your query logic to avoid unsafe combinations and ensure privacy level alignment.

Kinly refers to the below following documentation links for better understanding:
Combine files (binaries) in Power BI Desktop - Power BI | Microsoft Learn
Data refresh in Power BI - Power BI | Microsoft Learn
Table.Buffer - PowerQuery M | Microsoft Learn

Also please refer to the below solved thread which is useful:
Solved: Unable to combine data - Power BI Service Refresh ... - Microsoft Fabric Community

If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly.

Thank you for using the Microsoft Community Forum.

[Poojara_D12]

Hi @Stefan-Mladenov 

The “Unable to combine data” error in Power BI Service happens due to stricter privacy level enforcement, even when things work fine in Power BI Desktop. The official and consistent solution is to use an on-premises data gateway and enable the “Ignore privacy levels” option in the dataset’s settings—only in trusted environments. Also, make sure all queries reference the same source or a shared base query, and use Table.Buffer wisely to stop Power BI from combining data across isolated partitions. Avoid masking the issue with try ... otherwise, and consider using dataflows to simplify complex logic. These steps help prevent this error reliably.

[Stefan-Mladenov]

Thank you for the explanation!

However, in our project we are not using an on-premises data gateway because we’re delivering data to Power BI via API. The data is fetched directly using web-based API calls, so there's no local data source involved that would require a gateway.

Given this setup:

• The option to "Ignore privacy levels" via a gateway isn't applicable.

• Yet we still need to reference tables dynamically within the query logic.

In such API-based scenarios, what would be the official recommendation to reliably avoid the "Unable to combine data" error without using a gateway?

Again, referencing other tables or queries is a necessary part of our logic (not optional), so we’re looking for a robust and reusable solution that works in the Power BI Service environment.

[Poojara_D12 · Accepted solution]

Hi @Stefan-Mladenov 

In API-based scenarios where no on-premises data gateway is used, and dynamic query referencing is essential, the most reliable way to prevent the “Unable to combine data” error in Power BI Service is to ensure all API calls and referenced queries share the same privacy level—ideally marked as “Public”—and avoid crossing privacy boundaries between queries. In Power BI Desktop, go to File > Options and Settings > Data Source Settings, locate all related web/API sources, and explicitly set their privacy levels to Public if the data isn't sensitive. Then republish the model to Power BI Service.

Additionally, structure your queries so they all reference a shared base function or query, which ensures Power BI treats them as one unified source during evaluation. You can also flatten or buffer intermediary results using Table.Buffer at strategic points to prevent Power BI from triggering separate evaluations or partitions. Avoid using try ... otherwise to patch errors, as it often hides the root problem and can still trigger privacy errors during service refresh. If the API response is complex, consider extracting reusable logic into Power BI dataflows, which often handle privacy evaluation more gracefully and allow reusing tables with clearer lineage and less error-prone merging.

By aligning privacy settings across API queries, using shared base functions, and buffering results where folding isn’t needed, you can consistently avoid this error in the Power BI Service—even without a gateway.

[Stefan-Mladenov]

Thank you for the detailed explanation.

Regarding the first part—setting all related API sources to “Public”—that was already assumed to be done correctly, yet the error still occurred. Also, using Table.Buffer is something I’ve already incorporated as part of the trial-and-error process when restructuring problematic parts of the code.

However, the part you mentioned about using Power BI Dataflows to extract reusable logic and handle privacy evaluation more gracefully is something I haven’t tried yet, and it does sound like a promising direction—especially for improving query lineage and reducing merge-related errors.

I’ll explore refactoring the more complex logic into dataflows to see if that resolves the issue in a cleaner and more sustainable way.

I’d also really appreciate if anyone else with experience on this topic could confirm whether this approach worked for them—or suggest any other reliable solution that consistently avoids the “Unable to combine data” error in API-based scenarios without a gateway.

Thanks again to everyone contributing!