Impact Analysis & Dependencies
Before you change a lakehouse, know what breaks. Lineage view, impact analysis, and downstream dependency management across Fabric items.
Why impact analysis matters
Think of Fabric items like dominoes. If you change one (rename a lakehouse column), others fall — dataflows break, semantic models return errors, reports show blanks. Impact analysis shows you which dominoes will fall BEFORE you push the first one.
The lineage view
The lineage view is a visual graph showing how items connect:
Lakehouse → Dataflow Gen2 → Warehouse → Semantic Model → Report
↓
Dashboard
What the lineage view shows
- Upstream sources — where data comes from
- Downstream consumers — who depends on this item
- Cross-workspace dependencies — items in other workspaces that reference this one
- External sources — connections to data outside Fabric
Accessing lineage view
- Open the workspace
- Click Lineage view in the top menu
- The graph shows all items and their connections
Impact analysis for each item type
The exam tests impact analysis across four item types:
| Changed Item | Downstream Affected | Example Impact |
|---|---|---|
| Lakehouse | Dataflows, notebooks, warehouse views, semantic models (via SQL endpoint), reports | Renaming a table breaks all SQL queries referencing it |
| Warehouse | Semantic models (via SQL/default model), reports, downstream warehouses (cross-DB) | Changing a view breaks the semantic model |
| Dataflow Gen2 | Lakehouses, warehouses (where data is loaded) | Changing output schema breaks destination tables |
| Semantic model | Reports, dashboards, other models (via DirectQuery chaining) | Renaming a measure breaks all reports using it |
Scenario: Anita renames a lakehouse table
Anita at FreshCart plans to rename sales_raw to bronze_pos_transactions in her lakehouse. Before making the change, she opens the lineage view and sees:
- 2 Spark notebooks read from
sales_raw - 1 Dataflow Gen2 loads data into
sales_raw - The lakehouse SQL endpoint exposes
sales_rawas a view - A semantic model in Direct Lake mode references the SQL endpoint view
- 5 reports connect to that semantic model
Impact: renaming the table would break the notebooks, dataflow, and SQL endpoint view — which cascades to the semantic model and all 5 reports. She coordinates the change with her team before proceeding.
Best practices for managing dependencies
- Check lineage before any schema change — column renames, table drops, type changes
- Use views as abstraction layers — if reports connect to views (not tables), you can change tables without breaking reports
- Notify downstream owners — the impact analysis panel shows item owners and their contact info
- Test in Dev first — use deployment pipelines to validate changes before promoting to Prod
- Version your changes — Git integration tracks what changed and when, enabling rollback
Anita plans to rename a column in a lakehouse table. What should she do FIRST?
Anita deletes a view in a Fabric warehouse that a semantic model uses as its data source. Which downstream items might break?
🎬 Video coming soon
Next up: XMLA Endpoint & Reusable Assets