Combining a local Excel file with an enterprise SQL Server database inside a single Power Query query frequently triggers a Formula.Firewall error. This occurs because the Mashup Engine blocks local worksheet data from being passed into a SQL query, preventing unauthorized data transmission to remote servers.
Quick Answer:
Separate the data ingestion into two distinct staging queries. Load the local Excel table in Query A and the SQL Server table in Query B without any inter-query cross-references. Then, build a third query (Query C) that merges Query A and Query B. This eliminates cross-step privacy firewall violations.
Understanding the Collision Mechanism
When querying SQL Server, Power Query uses a technique called query folding. The engine attempts to convert transformations, such as filtering rows or joining tables, directly into native T-SQL statements sent to the server.
If your query merges a SQL table with a local Excel table or uses a local cell value to filter SQL rows, the mashup engine encounters two fundamentally different security zones:
- The SQL Server Database: Typically designated as Organizational or Public.
- The Local Excel Workbook: Often designated as Private or None.
The engine’s data privacy firewall assumes the worst-case scenario: that running the combined step might send private local data into a SQL WHERE clause or join predicate across the network. To protect local data integrity, the engine aborts execution with a Formula.Firewall failure.
The Permanent Structural Workaround: Staging Queries
The standard way to resolve this without compromising enterprise security policies is to decouple the extraction steps from the join step.
Step 1: Create the Local Excel Staging Query
- In Power Query, ingest your local table using standard parameters.
- Name this query
Staging_LocalData. - In the left query list, right-click
Staging_LocalDataand uncheck Enable Load (this keeps it in memory without duplicating it in the sheet).
Step 2: Create the SQL Server Staging Query
- Connect to your database via Data > Get Data > From Database > From SQL Server Database.
- Apply necessary server-side filters to let folding occur on the remote server.
- Name this query
Staging_SQLData. - Right-click
Staging_SQLDataand uncheck Enable Load.
Step 3: Create the Consolidated Merge Query
- Go to Home > Merge Queries > Merge Queries as New.
- Select
Staging_SQLDataas the primary table andStaging_LocalDataas the secondary table. - Match your join columns and select the join type.
- Name this query
Final_Combined_Reportand click Close & Load.
By ensuring neither staging query references the other in its source steps, the firewall allows the mashup engine to pull both datasets into local memory first before executing the merge in client RAM.
The M-Code Firewall Trap: Inlined Functions
A common mistake is embedding an extraction step inside an M-code query step like this:
let
SourceSQL = Sql.Database("dbserver.company.com", "SalesDB"),
LocalFilter = Excel.CurrentWorkbook(){[Name="FilterParam"]}[Content]{0}[Column1],
FilteredSQL = Value.NativeQuery(SourceSQL, "SELECT * FROM Orders WHERE Region = '" & LocalFilter & "'")
in
FilteredSQL
This inline syntax fails every time the firewall is enabled. The variable LocalFilter accesses the local workbook in the exact same step execution block where Value.NativeQuery attempts to establish an external connection.
To resolve native query credential or syntax issues caused by parameterized SQL inputs, refer to Troubleshooting Native Database Queries and the “Permission Denied” error.
What If Staging Fails?
If separating queries into staging tables still yields a firewall break:
- Verify Source Permissions: Go to Data > Get Data > Data Source Settings. Ensure that both your local workbook path and your SQL database connection are assigned the exact same privacy level, preferably Organizational.
- Review Fast Combine Settings: If company policy allows, use Fast Combine to bypass validation overhead. Follow the steps in How to configure “Fast Combine” to bypass security overhead.
- Database Driver Validation: If your SQL Server connection itself fails during the refresh handshake, verify your provider settings using Fixing “ODBC Connection Failed” when importing SQL to Excel.