You set up a Power Query connection, everything looks right, and then you hit Refresh. The data disappears, shrinks to a fraction of what it was, or throws an error that tells you almost nothing useful. You refresh again. Same result.
This is one of the most frustrating Power Query experiences because the problem is rarely obvious and the error messages are often vague. The real cause is almost always one of a small set of specific issues: a changed source schema, a broken file path, misconfigured privacy settings, or a query step that silently filters out rows when the source changes in a way Power Query did not expect.
This guide diagnoses each cause systematically, explains exactly why it happens, and gives you a fix for each one. It also covers how to build queries that are more resilient to source changes so the problem does not keep coming back.
Why Power Query Refresh Fails in the First Place
Power Query does not store your data. It stores the instructions for retrieving and transforming it. Every time you refresh, Power Query re-executes those instructions from scratch against the current state of your source.
This means that if anything about your source has changed since you built the query, the instructions may no longer apply cleanly. A column that was renamed, a file that was moved, a server that now requires different credentials, a privacy setting that blocks a data combination: any of these will cause refresh to fail or return incomplete results, and Power Query will not always tell you which one is responsible.
Understanding this distinction between stored data and stored instructions is the key to diagnosing refresh problems. You are not fixing corrupted data. You are fixing a mismatch between your instructions and your current source.
Cause 1: The Source File Path Has Changed
This is the most common cause of Power Query refresh failures for queries built on Excel files, CSV files, or folders. When you first connect to a file, Power Query hardcodes the full path to that file into the query. If the file is moved, renamed, or the folder structure changes, every refresh will fail with a file not found or path does not exist error.
This also happens when a workbook is shared. You build the query on your machine with a path like C:\Users\YourName\Documents\data.xlsx. A colleague opens the same workbook and refreshes it. Their machine has no such path. The query fails immediately.
How to identify it
Open the Power Query Editor (Data > Queries and Connections, then double-click your query). In the Applied Steps panel on the right, click the first step, usually called Source. Look at the formula bar. You will see a hardcoded file path. If that path no longer matches where the file actually lives, this is your problem.
How to fix it
The cleanest fix is to replace the hardcoded path with a parameter. This lets you update the path in one place without editing the query itself.
To do this, go to Home > Manage Parameters > New Parameter in the Power Query Editor. Name it something like FilePath, set the type to Text, and enter the correct current path as the current value. Then go back to your Source step, click the gear icon next to it, and replace the hardcoded path with your new parameter.
For shared workbooks, a more robust approach is to store the file path in a named cell on a worksheet, then have Power Query read that cell as its source path. This way each user can update the path in the cell without touching the query.
Prevention
Keep source files in a shared network location or cloud folder (SharePoint, OneDrive) that uses a consistent path across all machines. Avoid building queries against files stored in user-specific local directories if the workbook will ever be used by anyone else.
Cause 2: The Source Schema Has Changed
This is the cause that loses you data silently, with no error message. If a column in your source was renamed, reordered, added, or removed since you built the query, Power Query may continue to refresh without throwing an error, but the output will be wrong.
The most common scenario: a column called Revenue gets renamed to Total Revenue in the source. Power Query has a step that references Revenue by name. On refresh, it cannot find that column. Depending on how that step is written, it either throws an error, returns null for the entire column, or silently drops all rows that relied on that value.
Another common scenario: a new column is added to the source before an existing column. Any steps that reference columns by position rather than name will now be pulling data from the wrong column entirely, again with no error.
How to identify it
Open the Power Query Editor and step through your Applied Steps one by one from the top. Watch for any step that references a specific column name that no longer exists in the source, or any step that uses column index positions. Steps to check carefully include Removed Columns, Renamed Columns, Changed Type, and any filtering steps.
If a step shows a yellow warning triangle or the data preview looks wrong at that step, that is your point of failure.
How to fix it
For a renamed column, update the step that references the old name. Click the gear icon next to the affected step and update the column name to match the current source. Alternatively, edit the formula directly in the formula bar.
For steps that reference column positions, rewrite them to reference column names instead. Position-based references are fragile by design and should be avoided in any query that runs against a source that might change.
If columns are being added or removed frequently from your source, consider adding a step early in your query that explicitly selects only the columns your query needs. This acts as a filter that ignores unexpected new columns and makes the query more predictable.
Prevention
After building any query that relies on specific column names, document those column names. If your source is a file owned by someone else, establish an agreement that column names will not change without notice. For internal sources you control, treat column names as a contract and rename them only deliberately.
Cause 3: Privacy Level Settings Are Blocking the Refresh
This is the cause that produces the most confusing error messages. You may see errors like “Formula.Firewall: Query references other queries or steps and so may not directly access a data source,” or the refresh simply returns no data with a vague permissions message.
Power Query has a privacy levels system designed to prevent sensitive data from leaking between sources. When you combine data from two sources with different privacy levels, Power Query may block the combination entirely rather than risk exposing data inappropriately.
The problem is that the default privacy settings are often too conservative for internal use. Two tables from the same Excel workbook can trigger a privacy conflict if their privacy levels are not set consistently.
How to identify it
If your query combines data from more than one source (two different files, a file and a database, a file and a web API), privacy levels are a likely cause of any refresh failure that produces a Formula.Firewall error or a permissions-related message.
Go to Data > Queries and Connections, right-click your query, and choose Properties. Then go to File > Options and Settings > Data Source Settings. Check whether privacy levels have been set for each source involved in your query.
How to fix it
For each data source in your query, set an appropriate privacy level. In the Power Query Editor, go to File > Options and Settings > Query Options > Privacy. You can also set privacy levels per source in Data Source Settings.
The three levels are Public (data can be shared freely), Organizational (data can be shared within the organization but not publicly), and Private (data cannot be combined with other sources without explicit permission).
For internal workbooks where all sources are within your organization, setting all sources to Organizational typically resolves Formula.Firewall errors without compromising security.
If you are working on a personal workbook with no sensitive data and the privacy restrictions are causing problems without any real security need, you can set the privacy level to Ignore Privacy Levels in Query Options. Be aware that this disables the protection entirely, so only use it when you are confident no sensitive data is involved.
For a deeper explanation of the Formula.Firewall error specifically, including how the privacy evaluation engine works, see the dedicated guide on the Power Query Formula.Firewall error on this site.
Prevention
Set privacy levels deliberately when you first create each data source connection rather than leaving them unset. Unset privacy levels cause Power Query to prompt you during refresh, which interrupts automated refreshes and scheduled refreshes in Power BI.
Cause 4: Query Steps Are Silently Filtering Out Rows
This is the cause that is hardest to spot because everything appears to work. The refresh completes, no error is shown, but you have fewer rows than you expect. Sometimes dramatically fewer.
The most common reason is a filter step that was created when the source had a specific set of values, and those values have since changed. For example: you filtered a status column to keep only rows where the value was “Active”. The source later changed that value to “active” (lowercase). Power Query text filters are case-sensitive by default. Every row with “active” is now filtered out silently.
Another common reason is a data type change step that fails quietly. If a column that was previously all numbers now contains some text values (perhaps blank cells or error codes introduced upstream), a Changed Type step may convert those values to errors and then a subsequent Remove Errors step may delete those rows without any visible warning.
How to identify it
Step through your Applied Steps one at a time and watch the row count shown in the bottom left of the data preview window. If the row count drops sharply at any step, that step is filtering or removing rows. Check whether the filter condition still matches your current data exactly, including case, spacing, and data type.
Pay particular attention to steps named Filter Rows, Removed Errors, and Changed Type. These are the most common silent row killers.
How to fix it
For case-sensitive text filters, either update the filter value to match the current casing in the source, or add a step before the filter that normalizes the case using Text.Lower or Text.Upper so the filter is no longer sensitive to casing differences.
For data type errors removing rows, investigate why the source column now contains non-numeric values. If those values are legitimately missing or represent errors in the source, handle them explicitly with a Replace Errors step before the Changed Type step, replacing errors with null rather than letting them propagate and get silently removed.
Prevention
Avoid hardcoded filter values wherever possible. If you must filter on a specific text value, normalize the column case first. Review your Applied Steps after any known source change to check whether the row count at each step still makes sense.
Cause 5: The Data Source Credentials Have Expired or Changed
This cause applies mainly to queries connected to external databases, web APIs, SharePoint lists, or cloud services. When your credentials expire or the password for a database connection changes, Power Query cannot authenticate against the source and the refresh fails.
The error message usually mentions authentication, credentials, or access denied, but sometimes it surfaces as a generic refresh error with no obvious indication that credentials are the cause.
How to identify it
Go to Data > Queries and Connections, right-click the affected query, and choose Data Source Settings. Check whether the credentials shown are current. If the connection uses Windows authentication, check whether your account still has access to the source.
In Excel, you can also go to File > Options and Settings > Data Source Settings and click Edit Permissions to review and update credentials for each source.
How to fix it
Click Edit Permissions on the affected data source and re-enter the current credentials. If the source uses an API key that has rotated, update the key in the query Source step or in the parameter that stores it.
For database connections where the password changes regularly, consider using Windows authentication rather than SQL authentication if your environment supports it, since Windows credentials are managed centrally and do not require manual updates in Power Query when passwords change.
Prevention
Use Windows authentication or service account credentials with long-lived tokens wherever possible. Avoid storing credentials that expire frequently in Power Query connections that run on a schedule.
Cause 6: The Query Is Pulling from the Wrong Table or Sheet
This applies to queries built on Excel files or databases where the source structure has changed. If a query was built against a specific sheet named “Data” and that sheet was renamed, or built against a specific table name that was changed, the Source step will fail or pull from an unexpected location.
A subtler version of this: the query was built against a named Excel Table inside a workbook, but someone converted that Table back to a plain range. Power Query can no longer find the Table by name and either errors or pulls the entire sheet instead.
How to identify it
In the Applied Steps panel, click the Source step and look at the formula bar. Check the table or sheet name referenced against what actually exists in the source file. If the names do not match, or if a Table has been converted to a range, this is your cause.
How to fix it
Click the gear icon next to the Source step and reselect the correct sheet or table from the navigator. If the Table was converted to a range, either recreate the named Table in the source (Insert > Table) or update the Source step to reference the sheet directly and navigate to the correct range.
Prevention
Treat named Tables and sheet names in source files as fixed references once a Power Query connection has been built against them. If renaming is necessary, update the query Source step immediately after renaming.
Diagnosing Any Refresh Problem: A Systematic Approach
When a Power Query refresh fails or returns wrong data and you are not sure which cause applies, use this sequence:
- Open the Power Query Editor and check the Source step first. Confirm the file path, server name, or connection details still point to a valid, accessible source.
- Refresh the preview inside the editor (Home > Refresh Preview). This runs the query in the editor and shows errors at the exact step where they occur, which is far more informative than refreshing from the worksheet.
- Step through Applied Steps from top to bottom. Watch for the row count changing unexpectedly, yellow warning triangles, or steps that show errors in the data preview.
- Check Data Source Settings for credential issues and privacy level conflicts.
- If you see a Formula.Firewall error, go directly to privacy level settings for all sources involved in the query.
- If the row count is wrong but there are no errors, focus on filter steps and Changed Type steps.
Refreshing inside the editor rather than from the worksheet is the single most useful diagnostic habit to develop. The editor shows you exactly where in the query execution the problem occurs. The worksheet just shows you the final result, or an error with no location information.
Building Queries That Are Resilient to Source Changes
Most refresh problems are predictable and preventable. A few practices applied when you first build a query significantly reduce how often you have to debug them later.
Use parameters for file paths. Never hardcode a file path directly in the Source step of a query that will be used by more than one person or moved between machines. A single parameter that holds the path makes updates trivial.
Reference columns by name, not position. Any step that selects, removes, or reorders columns using positional logic will break silently when new columns are added to the source upstream. Always reference columns by name.
Normalize text before filtering. Add a Text.Lower transformation on any text column before applying a filter that depends on exact text matching. This makes your filters case-insensitive by default and prevents silent row loss when source casing conventions change.
Handle errors explicitly before they cause row loss. Add a Replace Errors step before any Changed Type step on columns that might contain mixed or unexpected values. This converts errors to null and keeps rows in the dataset rather than letting them be silently removed.
Set privacy levels when you create the connection. Do not leave privacy levels unset. Unset levels cause Power Query to make conservative assumptions that often block legitimate data combinations.
Document your source schema dependencies. Keep a note of which column names, sheet names, and table names your query depends on. If you are the one changing the source, check this list before renaming anything.
Quick Reference: Refresh Problems and Their Causes
| Symptom | Most Likely Cause | Where to Look |
|---|---|---|
| Error: file not found or path invalid | File path changed | Source step in Applied Steps |
| Error: Formula.Firewall or permissions | Privacy level conflict | File > Options > Privacy |
| Error: column not found | Source schema changed | Applied Steps, any step referencing a column name |
| Fewer rows than expected, no error | Silent filter or type error removing rows | Filter Rows, Changed Type, Removed Errors steps |
| Error: access denied or authentication | Expired or changed credentials | Data Source Settings > Edit Permissions |
| Error: table or sheet not found | Source renamed or Table converted to range | Source step navigator |
| Query works on your machine but not others | Hardcoded local file path | Source step, replace with parameter |
Frequently Asked Questions
Why does Power Query lose data after refresh?
Power Query does not store data. It stores the instructions for retrieving it. If anything about your source has changed since the query was built, such as a renamed column, moved file, or updated filter value, the instructions may no longer apply correctly and the result will be missing or incomplete data.
Why does Power Query show fewer rows after refresh?
The most common cause is a filter step or a Changed Type step that is silently removing rows. Open the Power Query Editor, step through the Applied Steps one at a time, and watch the row count at the bottom of the preview. The step where the row count drops unexpectedly is your point of failure.
What causes the Power Query Formula.Firewall error?
The Formula.Firewall error is caused by a privacy level conflict between two or more data sources in your query. Power Query blocks the combination to prevent data from leaking between sources. Fix it by setting explicit privacy levels for each source in File > Options and Settings > Data Source Settings.
Why does Power Query work on my machine but not on someone else’s?
The most common cause is a hardcoded file path in the Source step. The path points to a location that exists on your machine but not on theirs. Replace the hardcoded path with a parameter or store the path in a named worksheet cell so each user can set it independently.
How do I stop Power Query from breaking when my source changes?
Use parameters for file paths, reference columns by name rather than position, normalize text columns before filtering, set privacy levels explicitly when creating connections, and handle type errors before they cause rows to be removed. These practices make queries resilient to the most common source changes.
Why does Power Query refresh fail with no error message?
A silent failure usually means a filter or transformation step is removing all rows without throwing an error. Open the Power Query Editor and use Refresh Preview to run the query inside the editor, then step through Applied Steps to find where the row count drops to zero.
Edvald Numani is an Excel specialist and data professional who has spent years being the go-to person colleagues call when spreadsheets need fixing. He started Excel Bell to put that same help in writing, through practical guides, tutorials, professional templates, and tools built for real-world use. No filler, no recycled theory, none of the clutter that dominates most Excel content online, just real solutions for real spreadsheet problems.