Measure Killer Measure Killer

Plan a database schema change without breaking Power BI

Before renaming or dropping a table, view or column at the database level, find every Power BI semantic model and dataflow whose refresh will break — and confirm exactly which fields are at stake.

When to run this

You’re about to:

  • Rename a table, view or column in a SQL Server / Warehouse / Lakehouse.
  • Drop a column that “nobody uses any more” — or so the warehouse team thinks.
  • Split or restructure a view that several reports might be reading.

Before the change goes out, you want a definitive answer to: “Which Power BI semantic models and dataflows will fail their next refresh because of this, and which fields does the change affect?”

Step 1 — find the affected semantic models and dataflows

  1. Open Measure Killer in Limited Tenant Analysis (or full Tenant Analysis for tenant-wide scope).
  2. Go to the Lineage tab and locate the data source you’re about to change — your SQL Server, Lakehouse, Warehouse, etc.
  3. Every downstream item that reads from that source appears underneath — semantic models and dataflows. Select what you want to scan in the Selection tab. Running both gives the full picture, since a dataflow often sits between the source and a semantic model.
  4. Run the analysis. The M expressions tab becomes active.
  5. Search the M expressions for the table or view name. Every semantic model and dataflow whose Power Query references it appears in the results.

Include dataflows even when you’re only worried about reports. A semantic model that doesn’t reference the source directly can still break when the source schema changes — because its upstream dataflow does. Adding dataflows to the scan catches that indirect dependency.

Lakehouse + SQL analytics endpoint. If some downstream items connect through the SQL analytics endpoint instead of the Lakehouse directly, the SQL endpoint shows up as its own data source. Search both to catch everything.

Step 2 — confirm column-level usage

The M-expression search in Step 1 works at the query / table level — it tells you which models and dataflows reference the source table, but it doesn’t go down to the individual column. To check column-level usage you have to step into each affected model:

  1. Click Analyze models in the top ribbon.
  2. Select one of the affected models.
  3. Click View model usage.

You land in Measure Killer’s standard column-level lineage view for that model — every field (visible and hidden), used or unused, with every visual, measure and downstream reference traced.

Repeat for each affected model. Once you’ve confirmed which fields are actually in use, you have a precise impact list.

Coming soon — one-step column lineage from source to visual

The two-step workflow above exists because today’s column-level lineage runs inside a single semantic model — to extend it across the tenant, you have to drill into each model.

That changes with the next major release. Column-level lineage from data source through dataflows, semantic models and reports down to the individual Power BI visual is in active development — see Source-to-visual lineage for the roadmap.

When it ships, the same schema-change question is answerable in a single search: pick a column at the source, see every visual (across every dataflow and model it passes through) that ultimately depends on it — no per-model drill-down required.