You’re building a Power Query that pulls data from two different sources (maybe an Excel file and a web API) and suddenly you see this:

Formula.Firewall: Query ‘MyQuery’ (step ‘Source’) references other queries
or steps, so it may not directly access a data source.
Please rebuild this data combination.

Or this other variant that shows up when combining data sources:

Formula.Firewall: Query ‘MyQuery’ (step ‘Source’) is accessing data sources
that have privacy levels which cannot be used together.
Please rebuild this data combination.

If you have ever stared at those messages wondering what on earth Power Query is complaining about, you are in good company. The Formula.Firewall error is widely considered one of the most confusing and poorly explained errors in Excel and Power BI. The message sounds almost philosophical; it gives you zero practical guidance on what to actually do.

This guide will change that. You will leave with a deep understanding of why this error exists, exactly what triggers it, and every practical method to resolve it, from the quick fix to the architecturally correct solution.

1. What Is the Formula.Firewall, and Why Does It Exist?

The Formula.Firewall, officially called the Data Privacy Firewall, is a security mechanism built into the Power Query engine. Its sole purpose is to prevent your queries from accidentally leaking sensitive data from one data source into another.

That sounds reasonable in theory. But why would that ever happen accidentally? The answer lies in one of Power Query’s most powerful (and least understood) features: Query Folding.

The Root Cause: Query Folding

Query folding is what happens when Power Query translates your M code transformations, including filters, merges, sorts, and renames, into native operations against the original data source. For example, if you connect to a SQL Server table and apply a filter, Power Query may “fold” that filter back into the SQL query so the filtering happens on the server before data is even sent to Excel. This is a huge performance feature.

Here is where things get dangerous. Imagine this scenario:

• You have an internal Excel file containing employee payroll data, marked as Private or Organizational.
• You write a query that uses a payroll figure from that file as a parameter to call an external public web API (say, a currency converter).
• Because of query folding, Power Query might actually send the payroll value as part of the web request.
• The external API now receives your confidential salary data. That is a data leak.

Power Query cannot tell the difference between intentional and accidental data leakage. So it blocks the entire operation. That blockage is the Formula.Firewall error.

KEY INSIGHT: The Formula.Firewall is not a bug or an obstacle. It is a security guardian preventing silent, unintentional data leakage caused by query folding. Understanding this is the foundation of fixing it correctly.

2. How Power Query Partitions Work (The Engine Under the Hood)

To properly understand the two error types, you need to understand how the Power Query engine organizes query evaluation. This is rarely documented clearly, so pay attention here.

What Is a Partition?

When Power Query evaluates a query, it does not process it as one monolithic block. Instead, the Firewall engine divides the query, and all its dependencies, into units called partitions. A partition is a group of one or more query steps that the engine evaluates as a single unit.

The most granular partition possible is a single step. The largest partition can span multiple queries. The key rules the Firewall enforces are:

• A partition may either access compatible data sources directly, OR reference other partitions through a buffer.
• A partition cannot do both at the same time.
• When one partition references another, the Firewall inserts a special buffer function called Value.Firewall between them. This severs the direct connection, preventing any further folding between sources.

Think of partitions as isolated compartments on a ship. Goods can move between compartments, but only through a controlled manifest. No direct pipe runs from one compartment to another, so a leak in one compartment cannot flood the others.

Why This Causes Errors

The Formula.Firewall error fires when your query structure violates the partition rules. There are two ways this happens, producing two distinct error messages.

3. The Two Formula.Firewall Error Types: Decoded

This is where most guides fail you: they treat both errors the same, but they are different problems requiring different solutions.

Error Type 1: References Other Queries or Steps

Formula.Firewall: Query ‘QueryName’ (step ‘StepName’) references other
queries or steps, so it may not directly access a data source.
Please rebuild this data combination.

This error means your query structure is trying to both access a data source AND reference another query (another partition) in the same step. The Firewall cannot insert its buffer under these conditions, so it shuts everything down.

Classic real-world trigger: You have a helper query that returns a file path or URL. A second query uses that helper to build a dynamic connection. The second query references the helper query (another partition) while also trying to open a data source, thereby violating the rule.

Error Type 2: Privacy Levels Cannot Be Used Together

Formula.Firewall: Query ‘QueryName’ (step ‘StepName’) is accessing data
sources that have privacy levels which cannot be used together.
Please rebuild this data combination.

This error means two data sources with incompatible privacy levels are being evaluated in the same partition. For them to coexist safely in one partition, their privacy levels must allow bidirectional data sharing; meaning both are Public, or both are Organizational. Any other combination blocks evaluation.

Error Type	Root Cause	Primary Fix
References other queries or steps	Query accesses data source AND references another partition in same step	Flatten/restructure queries
Privacy levels incompatible	Two data sources with incompatible privacy settings in same partition	Set matching privacy levels OR ignore privacy

4. Privacy Levels Explained: The Four Settings

Privacy levels are the classification system Power Query uses to decide what data can flow where. There are four settings, and choosing the wrong one for a data source will trigger errors. Here is what each one means:

Privacy Level	What It Means	Typical Use Case
None	No privacy level has been assigned. This is not the same as ignoring privacy. Power Query will prompt you to set one.	Data source not yet configured
Private	Data is highly sensitive. It cannot be combined with or shared with any other data source, not even another Private source.	Personal/confidential data you never want to share
Organizational	Data belongs to your organization and can only be combined with other Organizational or Private sources.	Internal databases, SharePoint, internal APIs
Public	Data is openly available and can be combined freely with any other source.	Public websites, open APIs, downloaded public datasets

IMPORTANT! Private data is the most restrictive. Even two Private sources cannot be combined with each other. If you mark your internal SQL database as Private, it cannot combine with your Private Excel file. Use Organizational instead for internal sources you need to join together.

The compatibility rule for combining sources within a single partition is:

• Public + Public = Compatible
• Organizational + Organizational = Compatible
• Private + Anything = Not compatible
• Public + Organizational = Not compatible (Public data could leak Org data through folding)

5. Fix #1: The Quick Fix: Ignore Privacy Levels

This is the fastest fix and the one most people reach for first. It tells Power Query to skip all privacy checking entirely for this workbook.

How to Do It in Excel

• Open your workbook in Excel
• Go to Data → Get Data → Query Options
• In the left panel, under Current Workbook, click Privacy
• Select “Ignore the Privacy Levels”
• Click OK
• Refresh your query

How to Do It in Power BI Desktop

• Go to File → Options and Settings → Options
• Under the CURRENT FILE section in the left panel, click Privacy
• Select “Ignore the Privacy Levels and potentially improve performance”
• Click OK
• Refresh your query

WARNING! This fix works in Excel and Power BI Desktop. However, it does NOT work when you publish to the Power BI Service and schedule a data refresh. The Service ignores this setting for security reasons. If your queries need to refresh in the cloud, this fix alone will not be enough.

When Is This Fix Appropriate?

• You are working in Excel or Power BI Desktop only (no cloud refresh needed)
• You are fully confident that no sensitive data will be accidentally passed between sources
• You are in early development or prototyping and just need the query to run
• All your data sources are internal to your organization

Never use this fix in production Power BI reports that refresh in the Service, or in any environment where real sensitive data is in play.

6. Fix #2: The Proper Fix: Set Correct Privacy Levels

Rather than disabling the Firewall, this approach configures it correctly. You tell Power Query the true nature of each data source, and it enforces the rules intelligently.

How to Set Privacy Levels in Excel

• Go to Data → Get Data → Data Source Settings
• Select the data source you want to configure
• Click Edit Permissions
• Under the Privacy Level dropdown, choose the appropriate level
• Click Save, then Close
• Repeat for each data source
• Refresh your query

How to Set Privacy Levels in Power BI Desktop

• Go to File → Options and Settings → Data Source Settings
• Select the data source
• Click Edit Permissions
• Set the Privacy Level dropdown to the correct value
• Click OK

PRO TIP: For most corporate scenarios: set internal databases, SharePoint sites, and internal Excel files to Organizational. Set public web APIs and external websites to Public. Avoid Private unless you have a specific reason, as it prevents combining data even with other internal sources.

Parent URL Privacy Level Inheritance

A subtlety that catches many users: Power Query assigns privacy levels at the URL domain level, not at the specific endpoint level. This means if you set a privacy level for https://api.example.com, it applies to all sub-paths like https://api.example.com/data/table1 as well. You may need to set the privacy level on the parent domain, not just the specific endpoint you are querying.

7. Fix #3: The Architectural Fix: Flattening Your Queries

This is the most powerful and most correct fix; it is the one that will work in every environment including the Power BI Service. It solves the root cause rather than bypassing security.

What Is Query Flattening?

Flattening means restructuring your queries so that each query accesses its data source directly, rather than obtaining source connection details from another query. This ensures each partition is self-contained with a single, directly accessible data source, satisfying the Firewall’s rules by design.

The Classic Problem: Dynamic Parameters from Another Query

The most common scenario that triggers Error Type 1 is building a dynamic file path or URL. Here is the problematic pattern:

// Query 1: FilePath (reads cell A1 from Excel worksheet)
let
Source = Excel.CurrentWorkbook(){[Name=”Settings”]}[Content],
path = Source{0}[FilePath]
in
path

// Query 2: MyData (BROKEN, because it references FilePath query
let
Source = Excel.Workbook(File.Contents(FilePath), null, true),
…
in
…

The second query references the FilePath query (a different partition) while also calling File.Contents (a data source access). This violates the partition rule and fires the error.

The Flat Fix: Direct Access in Each Query

The solution is to eliminate the reference to the helper query and instead have each query read the parameter directly from the source:

// MyData (FIXED: reads the path directly, no cross-query reference
let
SettingsTable = Excel.CurrentWorkbook(){[Name=”Settings”]}[Content],
FilePath = SettingsTable{0}[FilePath],
Source = Excel.Workbook(File.Contents(FilePath), null, true),
…
in
…

Now the query accesses the Excel workbook (for the Settings table) and the target file, both in the same partition, with compatible privacy levels. The Firewall is satisfied.

Flattening Web API Queries

The same principle applies to web API calls. Instead of building a URL in one query and referencing it in another, build the URL inline:

// BROKEN PATTERN
// Query 1: BaseURL = “https://api.example.com/data”
// Query 2: uses BaseURL from Query 1 (triggers firewall)

// FIXED PATTERN: build URL inline in one query
let
BaseURL = “https://api.example.com/data”,
Source = Json.Document(Web.Contents(BaseURL)),
…
in
…

8. Fix #4: Advanced: Using Buffer Functions

In some complex scenarios, complete flattening is not practical; perhaps you genuinely need to build a dynamic list of URLs from one source and then query each one. In these cases, you can use M’s built-in buffering functions to force Power Query to materialise an intermediate result into memory, severing the query folding chain.

Table.Buffer and List.Buffer

These functions load a table or list fully into memory. Once buffered, the data is treated as if it came from no source at all; this breaks the lineage back to the original data source. This allows you to pass the buffered values safely to other queries without triggering the Firewall.

// Buffer the intermediate result to break query folding chain
let
Source = Sql.Database(“server”, “db”),
StockTable = Source{[Schema=”dbo”,Item=”Stocks”]}[Data],
Buffered = Table.Buffer(StockTable), // <– Severs folding chain
WithPrices = Table.AddColumn(Buffered, “Price”,
each Json.Document(Web.Contents(“https://api.prices.com/”,
[Query=[ticker=[Ticker]]])
)[price]
)
in
WithPrices

After Table.Buffer, the data is in memory. When the custom column accesses the web API per row, no SQL data is being “leaked” through query folding, because the folding chain has been broken by the buffer. The Firewall allows this.

ADVANCED TIP: Table.Buffer also has a performance benefit: it prevents Power Query from re-querying the data source for each row when used in certain iterative operations. Use it both as a Firewall fix and as a performance tool.

9. Power BI Service vs. Desktop: Critical Differences

This is where many developers get burned. A query works perfectly in Power BI Desktop with privacy levels ignored, gets published, and then fails on the scheduled cloud refresh. Here is why:

Environment	Ignore Privacy Setting Works?	Recommended Fix
Excel (Desktop)	Yes	Any fix works
Power BI Desktop	Yes	Any fix works for local refresh
Power BI Service (Gateway)	No; setting is ignored	Must use query flattening or correct privacy levels
Power BI Service (Cloud)	No; setting is ignored	Must use query flattening or correct privacy levels

The Power BI Service enforces privacy levels regardless of what you configured in Desktop. This is an intentional security decision; you cannot disable the Firewall in the cloud. If your queries need to refresh in the Service, the only durable solutions are query flattening (Fix #3) or setting genuinely correct privacy levels (Fix #2).

10. Common Real-World Scenarios and Solutions

Scenario 1: Dynamic File Path from a Named Range

Problem: A user stores a file path in cell B2 of a sheet, and a query reads that cell to dynamically load a different workbook. This triggers Error Type 1.

Solution: Read the named range and the target file in the same query (flatten). Set both the current workbook and the target file to Organizational privacy level.

Scenario 2: Currency Conversion from Public API

Problem: A query combines internal financial data (Organizational) with live exchange rates from a public API (Public). Error Type 2 fires because Organizational and Public are incompatible in the same partition.

Solution: Either (a) set the API to Organizational privacy level if the same partner works within your organization, OR (b) buffer the internal financial data with Table.Buffer before passing values to the API call, OR (c) accept the ignore privacy option if no truly sensitive data is involved.

Scenario 3: Iterating Through a List of API URLs

Problem: Query 1 gets a list of product IDs from SQL. Query 2 builds URLs from those IDs and calls a web API for each. Error Type 1 fires because Query 2 references Query 1 (another partition) while directly accessing the web.

Solution: Use Table.Buffer or List.Buffer on the result of Query 1 before referencing it in Query 2. This breaks the folding chain and lets the Firewall allow the combination.

Scenario 4: SharePoint + External API Combination

Problem: Combining SharePoint list data (Organizational) with an external public REST API (Public). The Firewall flags incompatible privacy levels.

Solution: Set SharePoint to Organizational and the external API to Public. Then either buffer the SharePoint data before passing to the API, or restructure the query so each source is in its own initial step before being merged.

Scenario 5: Parameter Query from Excel Table

Problem: A query reads a date from an Excel table and uses it as a URL parameter to call a web service. Error Type 1 fires.

Solution: Read the date directly from Excel.CurrentWorkbook() within the same query, build the URL inline, and make the Web.Contents call in the same set of steps. No cross-query reference needed.

11. Decision Guide: Which Fix Should You Use?

Use this decision tree when you encounter the error:

Your Situation	Recommended Fix
Development/prototyping, no cloud refresh needed	Fix #1 (Ignore privacy) is acceptable temporarily
All sources are internal corporate data	Fix #2: Set all to Organizational, enable combining
Combining internal + public web data, no cloud refresh	Fix #2: Set levels correctly (Org + Public usually needs buffering)
Reports publish to Power BI Service with scheduled refresh	Fix #3 (Flatten queries): the only reliable option
Complex iterative API calls from a dynamic list	Fix #4 (Table.Buffer/List.Buffer) combined with Fix #3
Error appears suddenly after previously working fine	Check if a new query was added that changed partition structure

12. Debugging Tips: How to Diagnose the Error Faster

Use Query Dependencies View

In the Power Query Editor, go to View → Query Dependencies. This shows a visual map of how your queries reference each other. Any query that has both a direct data source arrow AND a reference arrow from another query is your likely culprit.

Use Query Diagnostics (Power BI)

In Power BI Desktop, Power Query Editor → Tools → Start Diagnostics. Run your query, then stop diagnostics. The resulting Diagnostics table includes a Partition Key column that shows exactly how the Firewall divided your query into partitions. This is invaluable for understanding which steps are in which partitions.

Read the Error Message Carefully

The error message always tells you the exact query name and step name that triggered the problem. Write them down. Then look at that specific step in the Power Query Editor. Ask: does this step both access a data source AND reference another query? If yes, that is your fix target.

Check Privacy Level of Parent URLs

If you set privacy levels and still get Error Type 2, check whether you set the level on the exact URL that Power Query is using. A parent domain may have a different setting that overrides the specific endpoint you configured.

13. What Not to Do: Common Mistakes

• Do not blindly click through the “Edit Permissions” prompt without thinking. Setting everything to Private makes the problem worse, not better.
• Do not assume that because it works in Desktop it will work in the Service. Always test cloud refresh separately.
• Do not restructure your queries without understanding which partition the problematic step belongs to. Blind restructuring often moves the error rather than fixing it.
• Do not confuse the two error types. One is about query structure; one is about privacy level compatibility. The fix that works for one may not work for the other.
• Do not use Table.Buffer everywhere as a blanket fix. It breaks query folding and can dramatically slow down queries against large databases that rely on server-side filtering.

14. Summary: Everything You Need to Know

The Formula.Firewall error is Power Query’s security system protecting against unintentional data leakage, made necessary by query folding. It fires when your query structure violates partition rules (Error Type 1) or when data sources have incompatible privacy levels in the same partition (Error Type 2).

The four fixes, from quick to architecturally sound:

• Fix #1: Ignore privacy levels: Fast, works in Desktop only. Not viable for cloud refresh.
• Fix #2: Set correct privacy levels: The right way when your source classifications genuinely differ. Works everywhere.
• Fix #3: Flatten queries: The most durable solution for Error Type 1. Eliminates cross-partition references.
• Fix #4: Buffer intermediate results: For complex iterative patterns where full flattening is not practical.

For any query that needs to refresh in the Power BI Service, invest the time in Fix #3. For Excel-only workbooks where you control all data sources, Fix #2 or even Fix #1 may be perfectly appropriate.

The Formula.Firewall is not your enemy; it is a feature that makes Power Query production-ready in enterprise environments. Once you understand the partition model it enforces, you will stop fighting it and start designing queries that work with it from the start.

Found this guide helpful?
Share it with a colleague who has hit this error, or bookmark it for when you do.

FAQ: Power Query Formula.Firewall Error

These questions reflect the exact phrases real users type into Google when they encounter this error. Adding this FAQ section with proper schema markup (FAQ schema) significantly increases the chance of earning a featured snippet or People Also Ask placement in search results.

Q: What is the Formula.Firewall error in Power Query?

The Formula.Firewall error is triggered by Power Query’s Data Privacy Firewall, a built-in security system that prevents sensitive data from one source being accidentally leaked into another through a mechanism called query folding. It appears when your query structure violates the Firewall’s partition rules, or when two data sources with incompatible privacy levels are combined in the same query partition.

Q: Why does the Formula.Firewall error appear suddenly on a query that was working before?

This usually happens because something changed in your query structure or environment. Common triggers: you added a new helper query that created a cross-partition reference; a data source URL changed slightly, invalidating its stored privacy level; you connected to a new data source without setting its privacy level; or a colleague editing the same workbook/report introduced a new dependency. Open the Query Dependencies view (View > Query Dependencies in Power Query Editor) to spot new or unexpected references.

Q: What is the difference between the two Formula.Firewall error messages?

There are two distinct variants. The first, “references other queries or steps, so it may not directly access a data source,” means your query is trying to both access a data source AND reference another query partition in the same step, which is structurally forbidden. The second, “accessing data sources that have privacy levels which cannot be used together,” means two sources with incompatible privacy classifications (e.g. Organizational + Public) are in the same partition. The fixes are different: the first requires query restructuring; the second requires correcting privacy level settings.

Q: What is the fastest way to fix the Formula.Firewall error in Excel?

The fastest fix is to go to Data > Get Data > Query Options > Privacy (under Current Workbook) and select “Always ignore Privacy Level settings for this file”. This disables the Firewall for that workbook. Important caveat: this only works in Excel and Power BI Desktop. If you publish to the Power BI Service and schedule a cloud refresh, this setting is ignored and the error will return.

Q: How do I fix the Formula.Firewall error in Power BI Service (scheduled refresh)?

The ignore privacy setting does not work in the Power BI Service; it is always enforced in the cloud regardless of your Desktop setting. The only solutions that work for cloud refresh are: (1) set the correct privacy levels for each data source via File > Options > Data Source Settings so that all sources in the same partition are compatible, or (2) restructure your queries so each query accesses its data source directly without cross-query references (called query flattening). Query flattening is the most reliable long-term approach.

Q: What privacy level should I set for my internal company database?

Set internal data sources, such as SQL databases, SharePoint, internal APIs, and internal Excel files, to Organizational. This allows them to be combined with each other freely. Avoid setting internal sources to Private, as Private sources cannot be combined with any other source, not even another Private one. Reserve Private only for truly isolated data you never intend to join with anything else.

Q: Can two Private data sources be combined in Power Query?

No. Private is the most restrictive privacy level and means the data cannot be shared with or combined with any other data source, including another Private source. If you need to combine two internal data sources, set both to Organizational instead.

Q: What is query folding and why does it cause the Formula.Firewall error?

Query folding is when Power Query translates your M code transformations (filters, merges, sorts) back into native queries against the original data source; for example, pushing a filter back into a SQL WHERE clause so it runs on the server. This is great for performance, but it creates a security risk: if two data sources are connected through folding, data from a sensitive source could silently be sent to an external service as part of a folded query. The Formula.Firewall exists specifically to detect and block this. When it cannot safely allow folding between sources, it raises the error.

Q: What does Table.Buffer do and how does it help with the Firewall error?

Table.Buffer loads a table entirely into memory and severs its connection to the original data source. Once buffered, the data has no lineage; Power Query no longer knows where it came from. This breaks the query folding chain, which means the Firewall can no longer construct a path that would leak the buffered data to another source. It is especially useful when you need to iterate through rows and call an external API per row, using values from an internal database. Buffer the internal data first, then use it safely in the external call.

Q: Does setting privacy levels to Public fix the Formula.Firewall error?

It can fix Error Type 2 (incompatible privacy levels), but it is the wrong approach for sensitive data. Setting an internal database or confidential file to Public tells Power Query it is safe to share that data with any other source, which is the opposite of what you want for private corporate data. Only set a source to Public if the data is genuinely publicly available information, like a public API or open government dataset.

Q: Why does my query work in Power BI Desktop but fail after publishing?

This is almost always because you enabled “Ignore Privacy Levels” in Desktop, which bypasses the Firewall locally. When the report is published to the Power BI Service, that setting is not respected; the Service always enforces privacy level checks for security reasons. The fix is to either set correct, compatible privacy levels for all data sources, or restructure your queries to eliminate cross-partition references (query flattening). Both approaches will work in both Desktop and the Service.

Q: How do I combine an internal SQL database with a public REST API in Power Query without the Firewall error?

The correct approach depends on your refresh environment. In Desktop with no cloud refresh: set SQL to Organizational and the API to Public, then use Table.Buffer on the SQL data before passing values to the API. For cloud refresh: flatten the query so both source accesses happen in isolated steps, or buffer the SQL result to break the folding chain. Setting SQL to Organizational and the REST API to Public, combined with Table.Buffer, is the most reliable pattern for this scenario.

Q: The error message says “Please rebuild this data combination.” What does that actually mean?

Microsoft’s guidance is frustratingly vague. “Rebuild this data combination” effectively means: restructure your query so that each partition either accesses a data source OR references another partition, but not both. In practice, this usually means flattening your queries (reading parameters directly rather than from another query), or setting privacy levels so that the sources being combined are compatible. There is no single “rebuild” button; you need to diagnose which step is violating the partition rule and restructure accordingly.

Q: Is the Formula.Firewall error a bug in Excel or Power BI?

No; it is an intentional security feature, not a bug. The Firewall was designed to prevent silent data leakage caused by query folding, which could otherwise expose sensitive internal data to external services without the user realising it. That said, the error message itself is widely criticised for being unhelpful and confusing. The underlying mechanism is sound; the user experience around it is not.