Building a cross-platform SQL Server → Power BI lineage/impact tool — is this solving a real problem

[adityamore32]

Hi all — looking for honest feedback from people who manage larger Power BI environments alongside SQL Server, since I want to sanity-check an idea before investing more time in it.

The problem I'm trying to solve:
In enterprises with a lot of legacy SQL Server (stored procedures, views) feeding Power BI datasets, nobody seems to have a reliable way to answer: "If I drop/rename/change the type of this column, what breaks downstream?" Today this seems to get handled by manually grepping SQL code, tribal knowledge, or just shipping the change and waiting to see what breaks.

What I'm prototyping:
A tool that:

• Scans SQL Server (sys.dm_sql_referenced_entities) to find which views/procedures reference which columns.
• Parses the Power BI dataset model (via the extracted .tmdl files from a .pbix, using the sourceColumn property, or via the REST API/XMLA for live datasets) to map SQL columns to dataset columns.
• Builds a dependency graph so you can search a column and instantly see every downstream SQL object, dataset, measure, and (eventually) visual/report page that depends on it.
• Also aims to flag columns that appear genuinely unused (not in any visual, measure, RLS rule, sort-by-column, tooltip, or drill-through across every report on a shared dataset) as safe-to-review-for-deletion candidates — always with a human approving the actual delete, never automatic.

Where I know Power BI already has native coverage, and I don't want to overclaim:

• Refresh failure notifications and refresh history are already native.
• Power BI's own lineage view shows dataset → report/dashboard relationships within Power BI.
• My understanding is none of this extends upstream into the SQL Server layer, or predicts impact before a SQL-side change ships — that's the gap I think this fills. Genuinely want to know if I'm wrong about that.

Questions for the community:

1. If you manage Power BI + SQL Server together, is "what breaks if I change this column" a real recurring pain point for you, or is it rare enough that manual checking is genuinely fine?
2. Are there existing tools/features I'm missing that already solve this well (Purview, third-party lineage tools, etc.) that would make this redundant?
3. For those on DirectQuery/composite models vs. Import mode — does the "what breaks downstream" problem feel different or worse for you?
4. Would automatic "safe to delete" candidate detection (human-approved, not automatic execution) be something you'd actually use, or does it feel too risky no matter how it's framed?
5. Any war stories about a schema change that silently broke a report you'd be willing to share? (Trying to gut-check how common/costly this actually is.)

Appreciate any honest pushback — including "this already exists" or "not worth building" — I'd rather find out now than after building it out further.

@Parchitect , @Zanqueta , @jaryszek  Need help

[v-csrikanth]

Hi @jaryszek 
We would like to inquire whether have you got the chance to check the solutions provided by other users in commiunity to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.

Thank you.

[jaryszek]

Hello,

I explored this area previously. As far as I know, there is no single mature tool that reliably checks the full impact of a renamed on-premises SQL Server column across SQL objects, Power Query, the Power BI semantic model, DAX, reports, and individual visuals.

There are tools that cover parts of the problem. Tabular Editor can analyze semantic-model dependencies, Power BI provides lineage and impact analysis at the artifact level, and Purview or third-party lineage tools can cover parts of the upstream data flow. However, the complete end-to-end check still seems fragmented.

You may also want to look at the open-source PBIP Lineage Explorer:

https://github.com/JonathanJihwanKim/pbip-lineage-explorer

It can trace dependencies from Power BI visuals through DAX, model columns, and Power Query back to source columns, including rename chains. However, it does not appear to independently scan the complete SQL Server dependency layer across tables, views, and stored procedures, so your SQL-side integration could still provide real value.

Without a complete lineage tool, I would also recommend keeping schema contracts and source code under version control. For example, teams can keep the current expected table schemas in CSV files with fields such as schemaName, schemaVersion, fieldName, dataType, and nullable, while Git preserves the full history of changes. SQL views and stored procedures, together with PBIP/TMDL/PBIR files, should also be version-controlled and reviewed through pull requests.

This would not replace impact analysis, but it would make schema changes traceable, reviewable, and much safer.

[adityamore32]

Thank you for your reply, @jaryszek .

I really appreciate your time and effort in looking into this.

[jaryszek]

No problem, you can share how yoy solved it after