Fabric lineage view answers a deceptively difficult question: how does data move from upstream sources through Fabric items to downstream analytical consumers? Impact analysis asks the complementary question: if an item changes, what could be affected? Both are explicitly relevant to DP-600, but the real value comes from understanding what the graph represents and what it cannot prove.
Lineage is metadata about recognized relationships among data sources, dataflows, lakehouses, warehouses, semantic models, reports, and other supported Fabric items. It helps operators and owners trace dependencies that would otherwise be reconstructed manually. That makes it a practical part of data governance, because change decisions improve when teams know which assets depend on which upstream contracts.
The mental model is a directed graph, not a live execution trace. A node is an item or source. An edge represents a recognized dependency. The graph can reveal likely blast radius and help navigate ownership, but it does not automatically guarantee that every dynamic query, external script, exported file, or undocumented business process appears.
Lineage begins with detectable metadata
Fabric can display relationships it knows about through supported connections and item metadata. Within a workspace, lineage view shows items and their relationships, and it can show external data sources one step upstream. Cross-workspace relationships can also appear when supported dependencies exist.
This means the graph’s completeness depends on how the system was built. A connection created through supported Fabric experiences is easier to represent than an external script that downloads a CSV and manually uploads the result somewhere else. Governance improves when teams prefer traceable platform connections for important production flows.
Lineage metadata should have an owner too. If a connection or item type changes and the expected edge disappears, somebody needs to notice. Critical domains can periodically review whether key source-to-report paths are still represented, especially after migrations or introduction of external tooling.
Impact analysis walks downstream, not upstream
When considering a change to an item, impact analysis identifies downstream Fabric items and workspaces that may depend on it. This is useful before renaming a column, changing a semantic model, modifying a dataflow, or replacing an upstream data source. The focus is the potential blast radius of the proposed change.
For external data sources, the analysis can be shallower because Fabric may only know direct children. To trace further, an operator can continue from those child items. That limitation is important: a small visible impact list should not automatically be interpreted as proof that the change is low risk.
Downstream impact should be prioritized, not merely counted. Ten low-value development reports may matter less than one certified executive semantic model. Add business criticality, audience size, refresh frequency, and regulatory significance to the structural graph when deciding how much change coordination is required.
Impact prioritization can also consider reversibility. A change affecting many low-value reports may be easy to roll back, while one small dependency on a regulated export can be difficult to recover after incorrect data is distributed. Blast radius is a combination of count, criticality, and recovery cost.
A dependency edge does not describe semantic importance
Two reports can both depend on the same semantic model while having very different business consequences. One may be a test report used by three analysts; the other may drive month-end financial reporting. Lineage shows structural dependency, not criticality.
Governance should therefore enrich the graph with ownership, endorsement, business purpose, sensitivity, and service expectations. The principles behind data-quality accountability are relevant because a useful data estate knows which assets are authoritative and which owners are accountable for their quality and use.
Dependencies can also be conditional. A report may use one source only for a rarely selected region, or a notebook may call an external dataset only when a parameter is enabled. Static lineage can show the relationship without explaining frequency or runtime condition. Operators should know when an edge is structural versus commonly exercised.
Dynamic and external dependencies are a blind spot
Some dependencies can be created at runtime: parameterized notebooks, dynamic SQL, external automation, copied exports, or manual operational steps. If those relationships are not represented in Fabric metadata, lineage cannot infer them safely. An architectural review must distinguish between ‘not shown’ and ‘does not exist.’
Critical undocumented dependencies should be converted into managed contracts where possible. If a downstream process cannot be represented technically, record it operationally and include it in change review. Metadata is a tool, not a substitute for system knowledge.
Shadow copies are especially dangerous because they break visible lineage. Exported spreadsheets, manually copied tables, and locally cached datasets can continue circulating after the governed source changes. Data governance should reduce those copies for important decisions or at least identify them as unmanaged consumers.
A practical schema-change scenario shows the mechanism
Suppose a warehouse column named CustomerSegment is being renamed. Lineage shows the semantic models that query the warehouse; impact analysis shows reports and downstream workspaces connected through those models. The change owner can notify the affected teams, add the new column first, update models, validate reports, and remove the old column later.
Without that graph, the same change may appear local to the warehouse team. The failure would surface only after a report refresh or query breaks. Impact analysis turns downstream dependency information into a sequencing decision before the outage occurs.
A good migration scenario uses lineage twice: before change to identify consumers, and after change to confirm the expected new path. If a report still points to the deprecated asset after the migration, the post-change graph exposes incomplete work even when the new platform itself is healthy.
Migration plans should preserve a fallback until downstream validation is complete. Keeping an old table or measure temporarily available can reduce risk, provided ownership and a removal date are explicit. The purpose is controlled compatibility, not indefinite duplication.
Lineage helps troubleshooting as well as change planning
When a report is stale, the lineage graph provides a path upstream: report to semantic model, model to data item, data item to pipeline or source. Operators can inspect the last successful refresh or load at each layer and find the first point where expected state stopped advancing.
That workflow becomes more effective when paired with logging and monitoring. Lineage tells you where to look; logs and operational metrics tell you what happened there. Neither alone gives the complete explanation.
Troubleshooting can move upstream and downstream. A stale report may be caused by an upstream load, but a healthy source can also feed a semantic model whose refresh failed. Following the path in both directions helps identify whether the issue is freshness, transformation, model processing, or report interpretation.
Ownership should follow high-consequence edges
Shared semantic models, central warehouses, and widely reused dataflows deserve stronger change control because many downstream items depend on them. The graph can reveal these fan-out points. Those assets should have clear owners, compatibility policies, and deprecation processes.
High fan-out does not mean an asset should never change. It means changes should be additive where possible, communicated early, and validated against representative downstream consumers. Lineage provides evidence for where that effort has the highest value.
Fan-out assets deserve stronger compatibility guarantees and better documentation. A shared dataflow or semantic model with dozens of children functions like a platform API. Its owner should publish deprecation windows, additive-change preferences, and contact information so downstream teams can plan rather than react.
The graph should be reviewed for surprising relationships
Lineage is also a governance discovery tool. Unexpected cross-domain dependencies can reveal copied designs, shadow integrations, or reports using a nonauthoritative source. Those relationships may be legitimate, but they should be explainable.
Periodic review can therefore improve architecture rather than merely document it. A dependency that bypasses the intended curated layer may create inconsistent business logic. A report drawing directly from raw data may avoid the shared semantic definitions that the broader Power BI and Fabric foundations architecture is meant to provide.
Unexpected lineage can be a security signal. A sensitive source feeding an unapproved workspace or a certified model depending on an ungoverned raw table should trigger review. Structural visibility becomes more valuable when governance teams know what relationships are normal for the domain.
Use lineage to make better decisions, not to claim perfect visibility
A good impact review asks what the graph shows, which dependencies are business-critical, what metadata may be missing, who owns the affected items, how the change can be staged, and what evidence will prove downstream health afterward. That is more useful than treating the lineage diagram as an inventory screenshot.
Fabric lineage and impact analysis reduce uncertainty because they expose many dependencies automatically. Their limitation is equally important: metadata can only represent relationships the platform can see. The safest architecture uses lineage as a decision aid inside a larger culture of explicit contracts, ownership, and observable change.
Impact analysis should end with a validation plan. List the critical downstream items, the owners who must be notified, the tests that prove compatibility, and the time window for observing delayed failures. The graph informs that plan; it does not replace the work of verifying consumers after change.
After change, lineage should be checked again for orphaned or unexpected branches. A successful consumer test can still leave an obsolete dependency consuming refresh resources or exposing old data. Post-change cleanup is part of impact management because unused paths become future confusion.
The same review can identify documentation debt. If operators repeatedly need tribal knowledge to understand an edge or owner, capture that context in the asset metadata or runbook so the next impact analysis begins with better information.
