In Power BI, what causes Power Query's Formula.Firewall error and how do you fix it?

## What the firewall is protecting against Power Query folds work into sources wherever it can. That is normally what you want — but it means a value from one source can end up *inside a query text sent to another source*. Filter a customer list from a confidential HR workbook and merge it against an external vendor's database, and a folded implementation could send those confidential names to the vendor's server in a `WHERE … IN (…)` clause. Nothing malicious happened; the optimiser simply did its job. The **data privacy firewall** exists to prevent exactly that. It analyses how queries reference one another before evaluation and refuses combinations it cannot prove safe. Its errors are therefore not bugs but refusals, which is why "just retry" never helps. ## The two messages, which have different causes **The partition message.** *"Query 'X' (step 'Y') references other queries or steps, so it may not directly access a data source. Please rebuild this data combination."* This one has nothing to do with which privacy levels you chose. The firewall splits evaluation into partitions and requires each partition to be one of two kinds: a partition that *accesses a data source*, or a partition that *references other queries*. A single query that does both — connects to SQL Server and also feeds a parameter value taken from another query into that connection — cannot be classified, and is refused. The fix is structural, and it is a good habit regardless of the firewall: split the query in two. - A **source query** that does nothing but connect and return raw data. - A **transform query** that references the source query and does all the shaping and combining. When the offending value is a parameter fed into a connection (a server name, a date bound, an API path assembled from another query), promote it to a real Power Query parameter rather than reading it out of a query mid-flight. **The privacy-level message.** *"Formula.Firewall: Query 'X' is accessing data sources that have privacy levels which cannot be used together."* Each data source gets a privacy level: **Private** (never shared with any other source), **Organizational** (shareable with other Organizational sources but not Public ones), **Public**, or **None** (not yet classified). Combining a Private source with anything else is refused by design. The fix is to classify the sources honestly — usually marking internal databases and internal file shares Organizational so they may be combined with each other — rather than reflexively marking everything Private. ## Where the settings live matters as much as what they are Privacy levels are stored per data source, per environment. Setting them in Power BI Desktop fixes your local refresh and does nothing for the Service: a scheduled refresh through an on-premises data gateway evaluates the same combination on the gateway host, under the privacy levels configured for that gateway's data sources. A report that refreshes perfectly on a laptop and fails in the Service with a firewall error is the signature of this mismatch, and it is the version of the problem that reaches production. Power BI Desktop also offers, per file, an option to ignore privacy levels and combine sources anyway. It genuinely resolves the error and it genuinely removes the protection — the potential leak the firewall was preventing becomes possible. Use it knowingly, on sources where cross-source exposure carries no consequence, and never as a default reflex on a file touching regulated data. ## The performance angle nobody mentions first Even when the firewall permits a combination, enforcing privacy can be expensive: to guarantee no value crosses, the engine may buffer data locally rather than let a filter fold into the other source. So a combination that squeaks past the firewall can also be dramatically slower than the same logic would be with both datasets in one source. That is a further argument for the structural answer: if the two datasets need to be joined routinely, land them in the same warehouse and join them there, so Power Query reads one already-combined source and never has to reason about crossing at all. ## How to approach it in an interview Say what the firewall is for before saying how to silence it. The strong answer is: understand which two sources are being combined; restructure into source-plus-transform queries so no partition both connects and references; classify privacy levels deliberately and set them wherever the refresh actually runs; and treat "ignore privacy levels" as an informed exception rather than the fix. The weak answer is "turn off privacy levels", which is also, unfortunately, the most common one on the internet.