ai-assisted

Power Query’s New Preview Isn’t About Speed—It’s a Governance Stress Test

Data & Analytics: The New Power Query Preview and What It Signals for Self-Service BI at Scale

Frank Garofalo

22 May 2026 — 8 min read

The new Power Query preview is not a UI story. It is a governance story.

The new Power Query preview looks like a productivity win, but the bigger story is organizational. If Microsoft is making data prep easier and faster for analysts, every BI team now has to decide whether its governance model can keep up.

What makes this preview notable is not just polish. It brings a more modern authoring experience to the transformation layer many teams already depend on across Power BI and Fabric. When Microsoft improves the place where analysts shape data, manage steps, and prepare reusable logic, that matters far beyond one editor window. It changes how easily transformation work can spread, repeat, and become operational.

My view is simple: this preview signals that Microsoft is doubling down on broader self-service data preparation across Power BI, Fabric, dataflows, and adjacent services. That is good news only if enterprises pair analyst autonomy with managed self-service guardrails—clear ownership boundaries, reusable transformation standards, lineage, and platform governance.

The preview matters because Power Query is a shared transformation layer

If this were only a nicer editor inside one product, I would not care much. But Power Query is Microsoft’s shared data transformation and preparation engine used across multiple products and services, which is exactly why changes to its experience matter strategically beyond a single workflow (Microsoft Learn: Power Query overview).

When Microsoft makes Power Query easier to use, it is not just helping report authors clean columns faster. It is lowering the friction for transformation work across semantic models, dataflows, and Fabric workflows. The transformation layer becomes more accessible, more repeatable, and more likely to be used by a wider set of analysts.

And when transformation gets easier, the bottleneck moves into the operating model:

Who owns reusable transformation logic?
Which transformations are allowed to remain local?
When does analyst prep become a shared platform asset?
How do you detect five copies of the same M logic before they become production dependencies?

In Q1, I reviewed a 40-person analytics function where three business units had independently built near-identical customer cleansing logic against the same ERP source, and nobody realized it until refresh windows started colliding on the gateway every weekday at 8:00 a.m.

That is the future this preview accelerates unless teams get deliberate.

Microsoft is signaling a bigger bet on governed self-service

A lot of people still frame self-service BI as a tug-of-war between central control and analyst freedom. Microsoft’s own guidance is more mature than that.

Microsoft explicitly describes managed self-service BI as a deliberate operating model, not an accidental byproduct of giving users tools (Microsoft Learn: managed self-service BI usage scenario). The same pattern shows up in implementation guidance for self-service real-time analytics, where users increasingly work against live, shared enterprise data rather than isolated desktop extracts (Microsoft Learn: self-service real-time analytics usage scenario).

That tells you something important: Microsoft is not signaling less governance. It is signaling more self-service on top of shared enterprise platforms.

That interpretation is stronger when you look at the surrounding product context. Power Query remains the common transformation layer. Dataflow Gen2 in Fabric pushes reusable prep further into the platform. And enterprise connectors such as Azure Databricks are now first-class parts of the same transformation experience across semantic models, Power BI dataflows, and Fabric Dataflow Gen2 (Microsoft Learn: Azure Databricks connector).

My opinion here is firm: the preview is a forcing function for better governance.

Why this matters now: the blast radius is bigger

Organizations are under pressure to deliver analytics faster, support more live reporting, and feed more downstream consumers: semantic models, operational dashboards, Fabric workloads, and AI-assisted experiences that depend on trustworthy structured data.

That changes the cost of sloppy preparation work.

A bad join is no longer just one analyst’s problem. An undocumented business rule no longer dies inside a single PBIX file. A slightly different definition of “active customer” can now propagate into shared semantic models, executive dashboards, and operational decisions.

Microsoft’s own guidance reflects this shift. Self-service is increasingly tied to live and shared enterprise data, including DirectQuery-based scenarios (Microsoft Learn: self-service real-time analytics usage scenario). And Power Query increasingly sits in front of serious enterprise sources, including Databricks-backed environments, not just spreadsheets and small extracts (Microsoft Learn: Azure Databricks connector).

Faster self-service prep on top of enterprise-grade sources is powerful. It is also dangerous when every workspace invents its own cleansing rules.

The real trade-off: analyst autonomy versus transformation sprawl

Let’s name the real problem clearly: transformation sprawl.

Transformation sprawl is what happens when organizations still treat Power Query work as disposable report prep even after it becomes operationally important. In practice, it looks like this:

Duplicated M logic across datasets and dataflows
Slightly different cleansing rules for the same business entity
Hidden business assumptions embedded in query steps
One-off mashups that quietly become production dependencies
Refresh schedules and gateway usage that scale badly
Weak lineage between source, transformation, semantic model, and report

These are the four risks that matter most:

Duplicated logic

The same transformation gets rebuilt in five places because nobody knows it already exists.

Semantic drift

“Net sales,” “active supplier,” or “open order” slowly diverge because each analyst makes a reasonable local choice.

Refresh inefficiency

Repeated source pulls and redundant transforms waste capacity, gateway throughput, and patience.

Weak lineage

When a source changes or a rule breaks, nobody can quickly see which assets are affected.

Microsoft has been pointing toward reusable preparation patterns for years through managed self-service guidance, dataflows, and broader BI architecture recommendations (Microsoft Learn: managed self-service BI usage scenario; Microsoft Learn: dataflows overview; Microsoft Learn: BI solution architecture).

What mature teams will do differently after this preview

The right response is not to slow people down. It is to change what “good self-service” means.

Mature teams will shift from report-by-report transformations toward reusable, shared preparation assets where possible. That includes governed dataflows, curated semantic layers, and upstream canonical transformations for important domains.

A useful ownership model looks like this:

Analysts compose, explore, and extend for local analytical needs.
BI platform admins enforce workspace structure, gateway controls, refresh policies, connector governance, and endorsement patterns.
Central data teams own canonical transformations for high-value, cross-functional, or compliance-sensitive domains.

That is managed self-service in practice.

Here is the governance flow I would put in front of any BI lead reviewing the preview. It shows how a self-service asset should feed back into governance inventory rather than disappear into a workspace.

What matters is not just authoring the query. It is capturing metadata, refresh telemetry, and repeated patterns so you can standardize what should no longer stay local.

For teams already exporting Power BI or Fabric inventory data from admin APIs, workspace scans, or refresh logs, even lightweight analysis can reveal where self-service has already become shared architecture.

# Load exported metadata and normalize key fields for governance analysis
import pandas as pd

assets = pd.DataFrame([
    {"asset_id": "ds1", "asset_type": "dataset", "workspace": "Sales", "source": "sql://erp", "transform_hash": "abc123", "refresh_minutes": 45},
    {"asset_id": "df1", "asset_type": "dataflow", "workspace": "Sales", "source": "sql://erp", "transform_hash": "abc123", "refresh_minutes": 30},
    {"asset_id": "ds2", "asset_type": "dataset", "workspace": "Finance", "source": "sharepoint://budget", "transform_hash": "xyz999", "refresh_minutes": 10},
])

assets["source_norm"] = assets["source"].str.lower().str.strip()
assets["workspace_norm"] = assets["workspace"].str.lower().str.strip()

print(assets[["asset_id", "asset_type", "workspace_norm", "source_norm", "transform_hash", "refresh_minutes"]])

A basic inventory with normalized fields is enough to spot repeated source usage and recurring transformation patterns.

Next, identify duplicated transformation logic. This example uses a reusable transform hash as a stand-in for fingerprinting M logic extracted from datasets or dataflows.

# Flag likely duplicate transformation patterns using a reusable transform hash
import pandas as pd

assets = pd.DataFrame([
    {"asset_id": "ds1", "workspace": "Sales", "transform_hash": "abc123"},
    {"asset_id": "df1", "workspace": "Sales", "transform_hash": "abc123"},
    {"asset_id": "ds2", "workspace": "Finance", "transform_hash": "xyz999"},
    {"asset_id": "df2", "workspace": "Ops", "transform_hash": "abc123"},
])

dupes = (
    assets.groupby("transform_hash")
    .agg(asset_count=("asset_id", "nunique"), workspaces=("workspace", lambda s: sorted(set(s))))
    .reset_index()
)

dupes = dupes[dupes["asset_count"] > 1].sort_values("asset_count", ascending=False)
print(dupes.to_string(index=False))

If the same transformation pattern appears across multiple assets or workspaces, that is usually a candidate for standardization into a shared dataflow, curated semantic layer, or upstream pipeline.

Not every transformation belongs in Power Query

This is where opinion needs to get practical.

Power Query is powerful, but it is not the right home for every transformation. Teams get into trouble when they confuse “possible” with “appropriate.”

Keep transformations in Power Query when they are:

Local to one analyst or one team
Low-risk and easy to validate
Exploratory or short-lived
Specific to a reporting need rather than an enterprise definition

Move transformations upstream when they are:

Shared across multiple reports, datasets, or workspaces
Business-critical or executive-facing
Expensive to compute or refresh
Compliance-sensitive
Needed by multiple tools beyond Power BI
Better served by stronger testing, observability, and reuse

That is the same logic data engineering teams already use in lakehouse, warehouse, and medallion-style pipelines. Not every transformation should live in the consumption layer.

Microsoft’s product direction supports that distinction. Dataflows and Fabric-native preparation patterns exist precisely because some transformation work needs to scale beyond ad hoc desktop logic (Microsoft Learn: dataflows overview).

A practical governance checklist for BI platform leads

If you own the BI platform, this preview should trigger a concrete review.

Start with these operating questions:

Where should transformation logic live by default for each data domain?
Who approves shared prep assets?
How is lineage captured across source, transformation, semantic model, and report?
How do you detect duplicate queries or repeated source access?
When does a personal query need to be promoted into a governed asset?

Then tighten platform controls:

Segment workspaces by purpose and lifecycle
Use endorsed and certified assets intentionally
Govern gateways and source bindings
Monitor refresh schedules and failures
Maintain connector allowlists where appropriate
Standardize source access patterns for high-value systems

If you want one quick win, prioritize repeated source usage. That is often the clearest signal that local prep should become a shared asset.

# Identify repeated source usage that may justify shared dataflows or curated semantic layers
import pandas as pd

assets = pd.DataFrame([
    {"asset_id": "ds1", "source": "sql://erp"},
    {"asset_id": "df1", "source": "sql://erp"},
    {"asset_id": "ds2", "source": "sharepoint://budget"},
    {"asset_id": "df2", "source": "sql://erp"},
    {"asset_id": "ds3", "source": "sharepoint://budget"},
])

source_reuse = (
    assets.groupby("source", as_index=False)
    .agg(asset_count=("asset_id", "count"))
    .sort_values("asset_count", ascending=False)
)

source_reuse["candidate_for_standardization"] = source_reuse["asset_count"] >= 2
print(source_reuse.to_string(index=False))

When the same source appears across multiple assets, you likely have an opportunity to reduce duplication, improve consistency, and lower refresh cost with a governed shared layer.

Bottom line: faster self-service is only a win if the platform gets stricter

The new Power Query preview is a real productivity improvement. But the strategic point is what it means for operating models.

Power Query is a shared transformation engine across Microsoft’s data stack. Microsoft’s own guidance points toward managed self-service BI, reusable prep patterns, real-time analytics on shared data, and architecture that spans more than report authoring. The preview fits that trajectory.

So my position is firm: enterprises should welcome this preview and tighten governance at the same time. Not because analysts need less freedom, but because they are about to have more influence over shared transformation logic than ever before.

The winners will be the organizations that treat Power Query as part of data architecture, not just report authoring.

One concrete discussion prompt for practitioners: what is the first signal that tells you Power Query logic should be promoted into a governed shared asset—duplicate M patterns, repeated source access, refresh pain, semantic drift, or something else?

#PowerBI #Fabric #Datagovernance #SelfserviceBI

Sources & References

Try it yourself

Run this tutorial as a Jupyter notebook: Download runbook.ipynb (24 cells, 20 KB).