Data lineage (or data traceability) refers to the ability to follow the complete journey of a piece of data, from its source (database, file, API, ERP) to the final report viewed by a business user, through all intermediate transformations.
In a mature Power BI environment, this traceability quickly becomes critical: a simple column rename in a SQL source can silently break dozens of reports spread across dozens of different workspaces, managed by teams that have sometimes never talked to each other.
What Power BI’s native lineage offers
Power BI Service includes a lineage view directly accessible from each workspace. It displays as a diagram the relationships between dataflows, semantic models (datasets), reports and dashboards belonging to that workspace. It is a genuinely useful feature day to day for a team working within a limited scope, but it has a major structural limitation: it remains centred on one workspace at a time. It does show shared semantic models coming from other workspaces, and the impact analysis of a semantic model lists the items that depend on it elsewhere, but data sources are only visible at report and workspace level: there is no global view across the tenant.
The limits of “siloed” lineage
In the operational reality of a company, the same semantic model is frequently referenced by reports hosted in other workspaces, sometimes managed by other business teams, through shared datasets or composite models. Native lineage lets you find these dependencies object by object (provided you think of it and have rights on the workspaces concerned), but not see them at a glance across the tenant.
The concrete result: a team that modifies “its” data model often finds out too late about the reports of other departments that depend on it, which it may break without knowing.
Real-world example :
A finance team modifies a shared semantic model to add a new analytical dimension. Three weeks later, the sales team reports that its sales pipeline report has been showing calculation errors for some time, without being able to identify the cause. Cross-workspace lineage would have made it possible to anticipate this impact before the change was even published.
Why complete lineage changes the game
Lineage extended to the entire tenant, across all workspaces, answers questions that would otherwise be impossible to handle quickly:
- If I modify this source table, which reports, in which workspaces and managed by which teams, will be affected?
- Which semantic models are no longer used by any active report and can be safely archived?
- What is the complete dependency chain of a strategic report presented every month to the executive committee?
- How many hops separate raw data from its final visualization, and where are the critical transformations?
Downstream vs upstream lineage
It is useful to distinguish two complementary directions of lineage analysis:
- Upstream lineage : starts from a report and goes back to its sources: useful to understand where the displayed figures come from, and to check the reliability of a piece of data before presenting it at a management meeting.
- Downstream lineage: starts from a data source and goes down to all the reports that depend on it: this is the essential view before any source change, migration or system decommissioning.
A common use case: source system migration
During an ERP or CRM migration, or a data warehouse change, the first question asked by management is almost always the same:
“How many reports will be affected, and which ones are critical?”
Without cross-workspace lineage, the BI team’s honest answer is “we don’t know for sure, we’ll have to check as we go”. With complete, up-to-date lineage, this answer becomes a simple query on a centralized catalogue, available in minutes rather than after several weeks of manual investigation.
This topic is covered in depth in our article on migrating an ERP, a CRM or a business-critical application and its impact on Power BI.
Setting up cross-workspace lineage: the method
- Collect metadata from all workspaces through the Power BI Admin API (endpoints related to datasets, dataflows, reports and their declared relationships).
- Rebuild relationships between objects beyond workspace boundaries, in particular by identifying shared datasets referenced through composite models from other workspaces.
- Cross-reference with external sources (databases, files, APIs) declared in each semantic model, to get the complete chain from source to final report.
- Refresh regularly this map, because workspaces, reports and connections change continuously: a frozen lineage quickly loses its reliability.
This is technically demanding groundwork if done in-house, but it lastingly transforms a data team’s governance capabilities, especially during transformation projects involving several source systems.
Frequently asked questions
Is Power BI’s native lineage completely useless?
No, it remains useful for quickly understanding the structure of a given workspace and onboarding new team members. Its limit appears as soon as a global view is needed: it is viewed workspace by workspace or object by object, and does not provide a map of data sources across the tenant, even though this is a common need in any organization structured into several business teams.
Does cross-workspace lineage work with DirectQuery and composite models?
Yes, well-built cross-workspace lineage must cover all three connection modes (import, DirectQuery, composite), because dependencies between shared semantic models are created regardless of the mode used by the consuming report.
How long does it take to get complete, reliable lineage?
Developed in-house from the Admin APIs, this type of project generally takes from a few days to a few weeks depending on the size of the tenant. But the most demanding part is not the initial build: it is long-term maintenance (API changes, new workspaces, new sources) to keep the map up to date. This is where a dedicated, continuously updated solution makes the difference.
See also: “ERP, CRM or business-critical application migration“, which applies cross-workspace lineage to a migration project, and “Power BI inventory“, which provides the data foundation needed for any reliable lineage.
