Dependency tree
Drill into what every report, page, visual and measure consumes from your model — and how much space you'd save by removing each one.
What it is
The Dependency tree is a Measure Killer view that walks the relationships between your semantic model, reports, pages, visuals, and the columns and measures they consume — in either direction. For every element in the tree it shows how much of the model that element actually uses, and how much space you would reclaim if it were removed.
It complements the standard Where-used table: where Where-used answers “is this column used?”, the Dependency tree answers “what does this thing depend on, and what would removing it actually save me?”.
Picking a mode
When you open the Dependency tree, you choose the entry point for the walk. Each mode starts at a different level of the report/model hierarchy.
There are five modes, covered one by one below.
Full view
Full view shows the complete hierarchy of dependencies between every element — starting from the model and report and drilling down to columns and measures. From any node you can:
- See every measure and column used by a visual, and the columns referenced by those measures (recursively).
- Search by column or measure name to jump to every place it is used, directly or indirectly, anywhere in the model or report.

Report mode
When a single model is connected to several reports, Report mode shows how much of the model each report actually uses — and how much of that usage is exclusive to that report. The exclusive portion is the Potential savings: the space you would reclaim from the model if that report were deleted.

In the example above, Get data paginated exclusively consumes 5.15% of the model. Removing that report would shrink the model by that amount, because every column it relies on is unused by any other report.
Page mode
Page mode applies the same idea one level deeper — instead of listing reports, it lists every page across them. Useful for finding the one page that pulls in a long tail of otherwise-unused columns.

Visual mode
Same logic, one level deeper still: every visual on every page, with the columns and measures it consumes and the savings you would gain by removing it. Lets you spot the single visual that’s pinning a heavy column in place.

Measure mode
For measures we don’t have a direct on-disk size, so we approximate one based on the total size of all the columns the measure depends on (directly or via other measures). The number is an estimate, useful for ranking measures by impact — not a literal byte count.

How Potential savings is calculated
The Potential savings column appears in every mode and represents the space that would be freed if you removed the element on that row. It is the sum of the on-disk size of every column that is only reachable through that element — including columns pulled in indirectly by the measures or calculated columns it uses.
Because the metric chains through measures and calculated columns, the same physical column can contribute to several different elements’ savings — but it is only freed for real once every consumer of it is gone. That’s why the savings of a parent node is usually larger than the sum of its children: the parent owns extra columns that no single child uses on its own.
Related
- Find and remove unused measures and columns — the workflow that turns Dependency tree insights into a smaller model
- End-to-end lineage (source → report) — tenant-wide lineage, one level up from the per-model Dependency tree
- Best-practice analysis (reports + models) — other cleanup signals beyond unused / used