Why does my report show no data source of its own?

Because standard Power BI reports do not have one — they connect to a semantic model, and the model holds the actual data source connections. Only paginated reports connect directly to sources. Any lineage exercise that queries reports for data sources and stops there will come back mostly empty; you have to resolve standard reports through their model.

Does the built-in lineage view work across workspaces?

Only barely. The lineage view is scoped to one workspace at a time; cross-workspace dependencies (a report in workspace A on a shared model in workspace B) appear as external references you must chase manually. There is no tenant-wide lineage picture and no export, which is what makes source-decommissioning projects painful with built-in tooling alone.

How do I find every report that uses a specific SQL Server?

Invert the lineage map: collect data source connections for every semantic model (and paginated report) in the tenant, filter to the server or database being changed, then walk back to the models and the reports built on them. That requires tenant-wide datasource metadata — from scanner/datasource APIs you script yourself, or from a governance tool that already keeps the map current.

Power BI Data Lineage for Impact Analysis

Lineage answers two questions that come up in every BI estate. Forward: "if we change this database, what breaks?" — the impact-analysis question that precedes any migration or decommissioning. Backward: "where does this number actually come from?" — the trust question auditors and executives ask. Power BI has the metadata to answer both; it just does not hand it to you assembled.

The shape of Power BI lineage

The chain is: data source → semantic model → report → app audience. The critical nuance is that standard reports own no connections — they inherit everything from their model, so the model layer is where real lineage lives. Paginated reports are the exception: they connect to sources directly and must be mapped separately. Miss either rule and the lineage picture is quietly wrong.

Method 1 — The workspace lineage view

Every workspace has a built-in lineage view: a visual graph from sources through models to reports and dashboards. For understanding one workspace it is genuinely useful. Its limits: one workspace at a time, cross-workspace dependencies shown only as stubs, nothing exportable, and no way to search "everything touching server X" across the tenant.

Method 2 — Datasource and scanner APIs

The REST APIs expose the underlying facts — per-model and per-paginated-report data source entries with type and connection details, and the admin scanner API returns the same at tenant scale:

# Data sources of one semantic model
GET /v1.0/myorg/datasets/{datasetId}/datasources

# Direct connections of a paginated report
GET /v1.0/myorg/reports/{reportId}/datasources

This is snapshot tooling: run it tenant-wide and you have today’s map. To keep it true you own iteration across thousands of items, API paging and limits, storage, and re-running it on a schedule — lineage goes stale faster than any other governance data because every deployment can change it.

Impact analysis in practice

The working move is to invert the map: instead of asking each report where its data comes from, group all connections by server/database and read the list of affected models — then the reports on those models, then who actually uses those reports. That last join (lineage × usage) is what turns a migration plan from "notify everyone" into "these 12 reports matter, 30 are zombies we retire instead of migrating".

Continuous lineage mapping

PGR Sonar syncs data source connections for every semantic model and paginated report in the tenant as part of its regular catalog sync, joined to workspaces, reports and usage history. "What breaks if we move this database" stops being a scripting project and becomes a filter on a map that is already current — with the usage side attached, so you also know which of the affected reports anyone would miss.

Power BI Data Lineage: Impact Analysis and Audits