Power Query Circular Reference: Causes and Fixes

A Power Query circular reference happens when a query depends on itself, either directly or through other queries, so Power Query cannot determine a starting point for the calculation. Find the loop in the query dependencies, then break it by making each query depend only on an independent source or on an earlier step in a one-way chain.

What a circular reference means in Power Query

Power Query evaluates a set of queries and steps that can depend on one another. Those dependencies must form a directed, acyclic graph: a path can branch, but it cannot eventually lead back to the query or step where it began. A circular reference is a loop in that dependency graph.

For example, suppose a query named SalesSummary references CleanSales, while CleanSales references SalesSummary. Neither query can be evaluated independently because each needs the other’s result. The same problem can occur inside a single query if an M expression refers back to a value that depends on that expression.

This is different from an ordinary query reference. It is normal for several reports to reference one shared staging query, or for one query to build on another. The problem is the return path: A depends on B, and B eventually depends on A.

How query dependencies work

In Excel for Microsoft 365 on Windows, Power Query stores each query as a sequence of transformations written in the M language. A query can read an external source, a workbook table, or another query. When one query references another, Power Query must evaluate the referenced query before it can produce the dependent result.

Imagine a simple, healthy chain: an imported source feeds a cleaned-data query, which feeds a summary query. The summary depends on the cleaned data, and the cleaned data depends on the source; no query points back upstream. You can also branch the cleaned data into separate summaries. Branching is not circular as long as those branches do not feed back into their own inputs.

In the Power Query Editor, a query created with the Reference command depends on the query it references. A duplicated query starts with copied transformation steps, but it can still create a cycle later if you edit its source to point to a dependent query. The labels Reference and Duplicate describe how a query is created; they do not guarantee that the final dependency structure is safe.

Common causes of a circular reference

Two queries reference each other. A query may be changed to use another query that already relies on the first one.
A query reads its own loaded output. For example, a query loads results to an Excel table, and its source is then changed to read that same output table from the workbook.
A shared helper query is pointed downstream. A staging query intended to supply other queries may accidentally be changed to reference one of its own downstream reports.
A step refers to the wrong step or query. Editing M code or choosing an incorrect item in the formula bar can make a value depend on a later result that eventually depends on it.
Renaming or reorganizing obscures the relationship. Names alone do not create a cycle, but similar names can make it easier to select the wrong query while changing a source or reference.

A frequent misconception is that a query becomes circular merely because it uses the same external source as another query. Two separate queries can read the same CSV file, database table, or independent Excel input table without forming a cycle. The issue is a dependency path that returns to itself, not simply shared input data.

How to find the loop

Start by identifying which query reports the error and whether the error appears during preview, refresh, or load. Then inspect the dependency graph rather than changing random applied steps. In Excel for Microsoft 365 on Windows, open the Power Query Editor from Data > Get Data > Launch Power Query Editor. In the editor, select View > Query Dependencies to see how queries connect.

Locate the query named in the error or the query that fails to refresh.
Follow its incoming dependencies to see which queries or sources it needs.
Continue tracing upstream until you find a connection that leads back to the starting query.
Check the Source step and the query names used in later steps for an unintended reference.
Inspect any Excel workbook tables used as sources, especially tables that are also destinations for query output.

The diagram may show a longer loop than the error message suggests. For example, MonthlyReport might reference CleanedOrders, CleanedOrders might reference AllOrders, and AllOrders might accidentally reference MonthlyReport. Trace the whole path; changing only the first visible connection may leave another route back to the same query.

If the diagram is crowded, inspect queries one at a time in the Queries pane and review the Source step and Applied Steps list. You can also open Advanced Editor to read the M code. Do not delete steps just because they appear late in the list: first determine which query or step actually introduces the return dependency.

Practical ways to break the cycle

The right fix is to restore a one-way flow from source data to transformations to outputs. Common approaches include:

Point the source to the original input. If a query is reading its own loaded result, change it to read the original worksheet input table or external source instead.
Create a staging query. Keep one query responsible for importing and preparing shared source data, then have downstream reports reference that staging query. The staging query must not depend on those reports.
Move shared logic upstream. If two queries need the same transformation, put the shared steps in a separate base query and let both queries reference that base.
Remove the accidental reference. Edit the Source step or M expression so it points to the intended source or an earlier, independent query.
Separate input and output tables. Give the manually maintained source table a distinct role from the table where query results are loaded. Do not use a query’s own output as its input unless the process is deliberately designed around a separate snapshot or external stage.

After changing the dependency, use Close & Load or Close & Load To as appropriate, then refresh the affected queries. If the query loads to a worksheet table, confirm that its destination does not overwrite the input table it reads. Refresh All is available from Excel’s Data tab, but it will not fix a dependency loop by itself.

A concrete example: source table versus output table

Suppose an Excel workbook contains a manually maintained table called SalesInput. A query imports SalesInput, removes blank rows, and loads the result to a separate table called SalesClean. A report query can safely reference the cleaned query and group its rows by region. The flow is SalesInput to the cleaning query to the report.

Now imagine the cleaning query’s Source step is changed to read SalesClean, the table created by that same query. The query needs its previous output to calculate its next output, but that output cannot exist until the query has run. That self-dependency is the problem. The direct repair is usually to restore SalesInput as the source, or to create a genuinely independent input table or file and point the query there.

Changing the query name from SalesClean to CleanedSales will not solve this kind of cycle if the Source step still reads the query’s own output. Names help people understand the design, but the actual source and reference links determine whether the dependency graph loops.

What a circular reference is not

Power Query circular references are not the same as circular formulas in worksheet cells. Excel’s iterative calculation setting, available through Excel Options, concerns worksheet formula calculations; turning it on does not make a circular Power Query dependency valid. The two features have different calculation systems.

A slow refresh, a privacy-level warning, a credentials prompt, or a query folding issue also does not automatically mean there is a circular reference. Those problems can have their own causes. A circular-reference diagnosis should be supported by a dependency path that returns to the query or step being evaluated, or by an explicit cyclic-reference error.

Likewise, referencing the same source from multiple queries is usually not circular. If each query reads an independent source and neither query depends on the other, the graph has multiple branches, not a loop. This distinction matters because removing useful references or duplicating every query can make a workbook harder to maintain without fixing the real cause.

How to prevent the problem in a workbook

Give queries names that describe their role, such as Source_Orders, Staging_Orders, and Report_ByRegion. A consistent naming scheme makes it easier to distinguish original inputs from transformed outputs. Avoid using a loaded result table as an input table unless there is a clear, separate step that makes the input independent of the current refresh.

Keep a predictable direction: sources feed staging queries, staging queries feed analysis queries, and analysis queries feed loaded outputs. For a shared transformation, create one base query and let multiple downstream queries use it. Do not make the base query depend on one of the reports it supplies.

When editing M code, check the dependency of each referenced query and step rather than relying only on names. Before changing a query’s source to a workbook table, confirm whether that table is an independent input or an output created by the same query chain. A quick review of Query Dependencies after a significant redesign can catch a loop before a full refresh fails.

Frequently Asked Questions

Can two Power Query queries reference each other?
No. If Query A depends on Query B and Query B depends on Query A, neither has an independent starting result. Break the loop by moving shared logic to a separate upstream query or by correcting one query’s source.

Does using Reference in Power Query cause a circular reference?
No. Reference creates a dependency on the selected query, which is a normal way to build a query chain. It becomes circular only if that dependency eventually leads back to the query that is doing the referencing.

Can a query read a table it loaded to the same workbook?
It can read workbook tables, but reading its own output as its input can create a self-reference. Use a separate source table or another independent input, and keep the query’s load destination separate from that input.

Will renaming a query fix a circular reference?
Usually not. Renaming may make the design clearer, but it does not change the underlying dependency links. Correct the Source step or the reference that creates the loop.

Does Excel iterative calculation fix a Power Query cycle?
No. Iterative calculation applies to certain circular worksheet formulas, not to Power Query’s query-dependency graph. The query cycle must be removed or redesigned.

Try it: the Date Difference Calculator: days, months, years and weekdays between two dates, with the DATEDIF formulas.

More in How-to basics

Sources: Function behaviour and menu paths: Microsoft Support documentation for Excel. Method & sources

Spotted an error in this guide? Let us know.