Subject: Feature Proposal: Fault-Tolerant Refresh, Schema Changes & Intelligent Retry
Dear Microsoft Power BI Team,
I would like to propose an enhancement to Power BI semantic model refresh behavior focused on schema changes, dependency awareness, and intelligent recovery.
A source schema change should not automatically result in a failed refresh. Power BI should first evaluate whether the change actually affects the semantic model or any downstream logic.
1. Intelligent Schema Change Handling
When a source column is missing, renamed, or changed, Power BI should analyze its dependency before failing the refresh:
- Column is not referenced anywhere: Continue the refresh normally and display a warning.
- Column is referenced but has no meaningful downstream dependency: Continue with a warning and identify the affected column.
- Column is required by a Power Query transformation: Attempt intelligent recovery/retry before failing.
- Column affects a downstream transformation, measure, relationship, or visual: Clearly identify the dependency and explain the specific impact.
The objective is to distinguish between a harmless schema change and a change that genuinely breaks the model.
2. Special Handling for Changed Type
One particularly common scenario occurs when a source column is removed but Power Query still references that column in a Changed Type step.
For example:
Source ↓ Column A Column B ← Removed from source Column C ↓ Changed Type ↓ Filter ↓ Merge ↓ Output
If Column B is only referenced by the Changed Type step and is not used by any subsequent transformation, Power BI should recognize that the missing column does not affect the resulting query.
Instead of failing the refresh, Power BI could provide:
Warning: Column Column B is no longer available in the source. The column is only referenced by the Changed Type step and has no downstream dependency. Refresh continued successfully.
Ideally, Power BI could automatically:
- Ignore the missing column in the Changed Type step, or
- Retry the query with the obsolete type transformation removed, without requiring the developer to manually modify the M code.
3. Dependency-Aware Backend Recovery
Power BI could introduce an automatic recovery mechanism based on the dependency graph:
Refresh → Detect Error → Analyze Dependency → Determine Impact → Apply Safe Adjustment → Retry → Continue
For example, if the only failure is a missing column referenced by Changed Type, Power BI could safely exclude that column from the type transformation and retry the query.
The recovery should only be applied when Power BI can establish that the adjustment is semantically safe and does not affect downstream results.
4. Refresh Status
The refresh result should clearly distinguish a successful refresh with a non-critical schema warning from an actual failure.
For example:
🟢 Updated with Warning — 100% Complete
1 source column missing: Column B
Column is not used by downstream transformations.
Refresh completed successfully.
Instead of:
🔴 Refresh Failed
The warning should remain visible in the Power BI Service refresh history so administrators can identify and investigate schema changes without unnecessarily treating them as failed refreshes.
5. Dependency Impact Reporting
For columns that are genuinely required, Power BI should provide a precise dependency explanation rather than a generic error.
For example:
🔴 Refresh Failed — Required Column Missing
Missing column: Column B
Used by: Filter Rows → Merge Queries → Final Output
Impact: Query cannot be safely recovered automatically.
This would significantly reduce troubleshooting time by showing where the missing column is actually required.
6. Core Principle
The key principle should be:
A schema change should not automatically equal a refresh failure.
Power BI should evaluate the dependency impact first:
Missing & unused → Warning + Continue
Missing but safely recoverable → Auto-adjust/retry + Warning
Missing & required → Dependency-aware retry → Fail with precise explanation
This would make Power BI refreshes substantially more fault-tolerant and resilient, particularly for enterprise semantic models connected to large external databases where source schemas can evolve over time.
A harmless column removal should not bring down an otherwise healthy dataset, while genuinely breaking schema changes should still be surfaced clearly and accurately.
Best regards,
Ahmed Albukhaytan
