New blog articles in Microsoft Fabric Community

My button & slicer disappeared in Power BI Service. Here's why.

Hans-Georg_Puls — Thu, 10 Sep 2026 21:28:14 GMT

Imagine you have created a beautiful table in Power BI with a slicer and a button placed on top of it, overlapping the table area.

The slicer is used to search for specific content. The button becomes clickable when exactly one row is selected and opens a detail page for that row.

In Power BI Desktop, everything works perfectly.

However, as soon as you publish your report to the Power BI service and start interacting with it, strange things may happen.

If you select one row, both the slicer and the button disappear.

If you leave the table area, both reappear.

However, as soon as you hover over them, they disappear again.

Even more strangely, if you move in and out of the table a few times, it may happen that the button is available again.

As it turns out, this is documented behaviour, not a bug. In reading view, Power BI brings the selected visual to the front layer, above anything that overlaps it. Selecting a table row selects the table, so the button and the slicer, which actually sit in front of the table, end up behind it and disappear.

What I can't explain is the button becoming available again after moving in and out a few times. I haven't found anything documented on that.

The good news: this default behaviour can be changed.

To change it, there is an option. It's called 'Maintain layer order' and can be found in a visuals format pane under Properties > Advanced options.

Switch it on for the visual that jumps to the front, in my case the table.

Have you run into this one? And on which visual did you end up switching it on?

Ask vs. Act: Fabric Data Agents and Fabric Operations Agents Explained (with Industry Scenarios)

FarhanJeelani — Thu, 10 Sep 2026 21:26:37 GMT

Feature status (September 2026): Fabric data agents and operations agents are both generally available. Investigator insights in operations agents is still in preview. Always check Microsoft Learn for the latest.

The core difference in one line

A Fabric data agent waits for a question and answers it from governed data. A Fabric operations agent doesn't wait for anyone: it continuously watches live data against business goals and raises its hand, or triggers an action, when a condition is met.

A simple mental model: the data agent is the expert analyst you can message at any time; the operations agent is the control-room operator who never goes off shift.

Fabric data agent: conversational analytics on governed data

The data agent is a configurable Fabric item that lets anyone ask plain-English questions about data in OneLake. Behind the scenes, it decides which source can answer the question, then generates and runs a read-only query: SQL for lakehouses and warehouses, DAX for Power BI semantic models, and KQL for KQL databases (including Eventhouse). It can also work with ontologies and Microsoft Graph.

One data agent can combine up to five sources. Authors improve accuracy by selecting relevant tables, writing agent instructions in business language (for example, "route revenue questions to the Finance semantic model"), and adding example question-and-query pairs, up to 100 per source (examples aren't currently supported for semantic models).

Security is where the data agent is deliberately conservative. Every query runs with the asking user's own credentials, so row-level and column-level security still apply, and Microsoft Purview controls such as DLP and access restriction policies are respected. It never creates, updates, or deletes data, and it doesn't trigger notebooks or other workflows.

Once published, the agent can be consumed well beyond Fabric: in Microsoft 365 Copilot, Teams, Azure AI Foundry, or as a tool inside Microsoft Copilot Studio agents, where the integration is now generally available through the Fabric IQ Data MCP tool.

It's built for conversational insight, not bulk extraction: responses are capped at 25 rows and 25 columns, and unstructured files like PDFs aren't supported.

Fabric operations agent: autonomous monitoring with human-in-the-loop action

The operations agent lives in the Real-Time Intelligence workload. Instead of answering ad-hoc questions, you give it business goals, instructions, a knowledge source (an Eventhouse KQL database or an ontology), and the actions it's allowed to recommend.

From that configuration, the agent generates a playbook: the business entities and properties it will track and the rules that define what "needs attention" looks like. You can build this manually or describe your intent to the built-in Copilot chat ("monitor the turbines and alert me when motor temperature gets too high") and refine the proposed rules iteratively. Each rule is backed by an inspectable query that the agent evaluates every five minutes, using either state conditions (such as is above 80, which keeps signaling while true) or transition conditions (such as crosses above 80, which signals only on the change).

When a rule is met, the agent sends a Teams message, to a person or a channel, through the Fabric Operations Agent Teams app, summarizing what it saw and what it recommends. Beyond messaging, you can configure actions that run a Fabric notebook or trigger a Power Automate flow, which opens the door to ServiceNow tickets, SAP work orders, emails, or any other Power Automate connector. For anomalies, Investigator insights (preview) adds correlated patterns and a likely root-cause summary directly in Teams.

Two governance details matter. First, each operations agent gets its own Microsoft Entra Agent ID, so its activity is auditable separately from human users. Second, it runs in delegated mode with its creator's permissions: when a recipient approves a recommendation, the action executes with the creator's access. Choose agent owners deliberately.

Side-by-side comparison

Dimension	Fabric data agent	Fabric operations agent
Core purpose	Answer questions about data	Monitor data and drive action
Interaction model	Pull: a user asks	Push: the agent notifies
Trigger	A human prompt	A rule condition being met
Data sources	Lakehouse, warehouse, semantic model, KQL database, mirrored database, ontology, Microsoft Graph (up to 5)	Eventhouse KQL database or ontology
Configuration	Tables, instructions, example queries	Goals, instructions, playbook rules, actions
Output	Natural-language answers, small tables, summaries	Teams alerts with recommendations, notebook runs, Power Automate flows
Write / action capability	Strictly read-only	Executes approved actions
Identity	Asking user's credentials (RLS/CLS enforced)	Entra Agent ID using creator's delegated permissions
Time orientation	"What happened, and why?"	"What's happening now, and what should we do?"
Where users meet it	Fabric, Teams, M365 Copilot, Copilot Studio, Foundry	Primarily Teams (alerts, approvals, investigations)

Industry scenarios

1. Manufacturing: from vibration spike to work order

A discrete manufacturer streams CNC machine telemetry (spindle vibration, motor temperature, cycle time) through Eventstream into an Eventhouse.

Operations agent: Its goal is to minimize unplanned downtime. A rule watches for vibration crossing above tolerance on any machine. When it fires, the maintenance supervisors' Teams channel receives an alert with the machine, recent readings, and a recommendation to schedule an inspection. On approval, a Power Automate flow creates a work order in the maintenance system.

Data agent: Preparing for a quarterly review, the plant manager asks: "Which lines had the most unplanned downtime last quarter, and how did OEE compare to target?" The agent queries the production lakehouse and OEE semantic model and returns a ranked answer, with no report-building required.

2. Retail and CPG: protecting a flash promotion

During a weekend promotion, point-of-sale and inventory events land in Eventhouse in near real time.

Operations agent: It monitors store-level inventory for promoted SKUs and flags any item dropping below safety stock. The regional replenishment lead gets a Teams recommendation to trigger an emergency transfer from a nearby store or distribution center, executed through Power Automate after approval.

Data agent: On Monday, the category manager asks: "How did the promotion perform versus the same weekend last year, by region, and which stores ran out of stock?" The agent blends the sales semantic model with lakehouse inventory history to answer in seconds.

3. Energy and utilities: pipeline pressure and grid load

An oil and gas operator ingests SCADA readings (pressure, flow rate, compressor status) from field assets; a utility does the same for substations.

Operations agent: Rules detect pressure exiting its normal operating range at a pumping station, or transformer load crossing a critical threshold during a heatwave. The control room is alerted with context and a recommended response, such as dispatching a field technician via a flow. Human approval stays in the loop. Note that operations agents complement, and never replace, certified safety instrumented systems.

Data agent: An asset integrity engineer asks: "Which ten assets had the most pressure excursions in the last 12 months, and when were they last serviced?"

4. Financial services: payment gateway degradation

A bank streams card authorization events by gateway, merchant category, and channel.

Operations agent: Its goal is protecting payment success rates. When a gateway's decline rate crosses above its threshold, the payments operations team gets an alert with a breakdown and a recommendation to reroute traffic to a secondary processor, an action that runs only after an engineer approves it.

Data agent: A relationship manager asks: "Which of my corporate clients saw failed payments above 2% this month?" Because the agent runs under the manager's own identity, row-level security ensures they only see their own portfolio.

5. Pharma logistics: cold-chain integrity

A logistics provider moving vaccines and biologics collects IoT temperature and GPS data from refrigerated containers.

Operations agent: A transition rule fires the moment a shipment's temperature exits the 2–8°C range. The control tower is notified with location and excursion details, a notebook action flags the batch for quality review, and a flow alerts the receiving site.

Data agent: A quality lead asks: "Which lanes and carriers had the highest excursion rates this year?"

Better together: detect, decide, explain

The strongest architectures use both agents on the same data foundation. Picture an airport operations team. An operations agent watches baggage-system events in Eventhouse and alerts the duty manager when belt throughput drops below target during a peak arrival wave. The manager approves the recommended action: rerouting bags to an alternate belt via Power Automate.

Then, without leaving Teams, the manager asks a Copilot Studio agent grounded by a Fabric data agent over the same Eventhouse and historical lakehouse: "How often has this belt degraded at this time of day over the past 90 days?"

The operations agent handles detection and response. The data agent handles explanation and learning. Because both point at the same governed data in OneLake, the alert and the analysis never disagree about the numbers.

How to choose

Choose a data agent when the need is exploratory and question-driven: executive self-service, analyst acceleration, or bringing trusted data into Copilot experiences. Choose an operations agent when you have a specific, repeatable business process with measurable conditions, where minutes matter and someone should be told (or something should happen) without anyone having to ask.

A quick test: if you hear "someone should check this dashboard every hour," you need an operations agent. If you hear "I just need to know X before Friday's meeting," you need a data agent.

Practical tips before you build

For data agents: curate tightly by selecting only the tables users need, write instructions in business terms, and invest in example queries, which are often the biggest accuracy lever. Use Git integration and deployment pipelines to promote agents from development to production.

For operations agents: scope one agent to one business process, flatten nested JSON columns in Eventhouse tables before configuring, and review each rule's generated query before starting the agent. Remember that approvals execute with the creator's permissions, trial capacities aren't supported, and agents consume capacity units, so track them in the Fabric Capacity Metrics app.

For both: confirm your tenant admin has enabled the required Copilot and Azure OpenAI settings, including cross-geo AI processing where your capacity region requires it.

Wrapping up

Fabric data agents and operations agents are two sides of the same coin. The data agent democratizes understanding: anyone can ask a question and get a governed answer. The operations agent operationalizes response: the business stops depending on people watching dashboards and starts reacting to events as they happen.

Start with the scenario that hurts most today, build on a shared OneLake foundation, and grow from there.

How are you using these agents in your industry? Share your scenarios in the comments!

Lineage-aware AI with the Fabric item relations API (Preview)

yaronc — Thu, 10 Sep 2026 19:10:20 GMT

With two new REST operations, you can retrieve the upstream and downstream relations of any Fabric item directly from your own code — the dependency graph behind the portal's lineage view, now available as a supported, programmable surface. Each response includes related items, the typed relation edges that connect them, and the workspaces those items belong to.

Lineage has always answered two human questions: “where does this data come from?” and “what breaks if I change it?” This API lets your tools — and your AI agents — ask those same questions programmatically.

What’s new

Until now, item lineage in Fabric was something you explored visually in the portal. You opened an item, looked at its lineage view, and traced dependencies by eye. That’s great for people, but it’s difficult to automate.

With this update, lineage becomes an API. After authenticating to Fabric, you can programmatically:

Get the downstream relations of an item — everything that depends on it (its consumers and impact radius).
Get the upstream relations of an item — everything it depends on (its sources).
Read the typed relation edges between items (for example, Shortcut, PushData, Orchestration).
Resolve related items across workspaces, using the workspace list returned alongside the graph.
Feed lineage into impact analysis, documentation, data catalogs, CI/CD checks, and AI agents.

Why this matters

If you only work in the Fabric portal, the lineage view already serves you well. The impact of this update shows up once you need to automate or scale — when understanding dependencies becomes part of a workflow rather than a manual click-through. A few examples:

Before you delete or reroute a dataset, you call the downstream API to see every report, semantic model, and pipeline that would be affected.
You build an internal catalog or documentation site that shows each item’s sources and consumers, kept fresh automatically.
You add a CI/CD check that fails a deployment if a change would break a downstream dependency.
You are an ISV building on Fabric, and you want lineage to be part of your product experience — not a side trip into the portal.

That’s what a public API is for: turning a visual experience into a building block you can automate and compose.

Lineage is context for AI

AI agents are only as good as the context they are given. When an agent answers a question about a table, a report, or a metric, it benefits enormously from knowing where that data came from and what depends on it. Lineage is exactly that context.

With the relations API, an agent can traverse an item’s dependency graph as part of its reasoning. Ask “is it safe to change this table?” and the agent can call the downstream API, enumerate the affected items, and ground its answer in the real graph instead of guessing. Ask “where does this number come from?” and it can walk upstream to the source. In other words, lineage helps ground AI responses in the actual dependency graph rather than inferred relationships.

This is the same pattern we see across Fabric’s AI story: take governance metadata your organization already maintains — like sensitivity labels — and share it with AI so agents understand your data the way your organization does. Lineage joins that toolkit. It gives agents dependency awareness: the ability to reason about cause, effect, and blast radius, not just content.

How it works

At a high level, the API exposes both sides of the dependency graph: what an item depends on and what depends on it. The API adds two GET operations under the platform surface. Because the API is in preview, every call currently requires beta=true as a query parameter.

GET /v1/workspaces/{workspaceId}/items/{itemId}/relations/downstream?beta=true

GET /v1/workspaces/{workspaceId}/items/{itemId}/relations/upstream?beta=true

The caller needs read permission on the item. Both user and service principal identities are supported.

Each response is a small graph made of three lists:

items — every item in the returned graph, including the item you queried, so each relation endpoint can be resolved (id, type, display name, and the workspace they belong to).

relations — the edges, each with a source item, the item it depends on, and a relation type.

workspaces — the workspaces referenced by those items, so you can resolve names across workspace boundaries.

A downstream response for a semantic model consumed by a report looks like this:

{

"items": [

    { "id": "3546052c-...", "type": "Report",

      "displayName": "Q4 Sales Dashboard", "workspaceId": "cfafbeb1-..." },

    { "id": "9b218778-...", "type": "SemanticModel",

      "displayName": "Sales Semantic Model", "workspaceId": "cfafbeb1-..." }

],

"relations": [

    { "itemId": "3546052c-...",

      "dependentOnItemId": "9b218778-...",

      "relationType": "Association" }

],

"workspaces": [

    { "id": "cfafbeb1-...", "displayName": "Finance Analytics Workspace" }

]

}

The relation types describe how two items are connected. The set is extensible, so new types can be added over time:

Relation type	What it means
Association	The item consumes the dependency item — for example, a report built on a semantic model.
Shortcut	The item references data through a OneLake shortcut to another item.
PushData	The item writes or pushes data into the dependency item.
Orchestration	The item runs or manages execution of the dependency item (for example, a pipeline).
Datasource	The item reads from the dependency item as a data source — for example, a notebook reading a lakehouse.
CascadeDelete	A parent–child relationship; deleting the parent deletes the dependent.
WeakAssociation	A soft dependency that is removed if the dependent item is deleted.
HiddenInWorkspace	A dependency on an item that isn't surfaced in the workspace list, such as a staging artifact.

Getting started

A great first step is to pick a familiar item and explore its downstream relations to understand its impact radius. The following is the shape of a first call using the Azure CLI for authentication:

1. Authenticate to Fabric and get a token.

$token = az account get-access-token `

--resource "https://api.fabric.microsoft.com" `

--query accessToken -o tsv

2. Call the downstream relations API for an item.

GET https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}

/items/{itemId}/relations/downstream?beta=true

Authorization: Bearer $token

3. Read the relations array to list what depends on the item, then walk upstream from any related item to trace it back to its sources.

From there, wire the results into whatever needs dependency awareness — an impact-analysis check, a catalog page, or an AI agent’s context. You can find the operations in the Fabric REST API reference under the platform items surface:

Exposing item lineage as a programmable API is a foundational step. It turns the dependency graph into something your tools, pipelines, and agents can read and reason over. We look forward to seeing what you build with it.

Note: This API is in preview and provided for evaluation and development purposes. It may change based on feedback and is not recommended for production use.

Designing scalable Business Events in Microsoft Fabric

robece-msft — Thu, 10 Sep 2026 19:40:36 GMT

Welcome to the seventh post in our Business Events, Fabric Events, and Azure Events series for Microsoft Fabric. This series takes you from foundational event-driven concepts to practical implementation patterns that help teams turn meaningful business moments into trusted signals, decisions, and actions across Fabric.

Accelerate JSON workloads with the Native Execution Engine in Microsoft Fabric

Santhosh_Ravin1 — Thu, 10 Sep 2026 17:00:00 GMT

JSON is one of the most common formats in modern data platforms. It carries application events, API payloads, operational telemetry, configuration data, and the metadata that coordinates data-driven processes. For many organizations, JSON is not an edge case. It is part of the critical path from ingestion through transformation and analytics.

The update of JSON support in the Microsoft Fabric Spark Native Execution Engine, now in preview, expands native acceleration to an important class of semi-structured workloads. Spark can now read and process JSON data through the Native Execution Engine's vectorized C++ path, helping more of the query remain columnar from the source through downstream transformations.

Why JSON performance matters

Analytics systems increasingly combine structured tables with semi-structured data. A pipeline might ingest JSON events from an application, use JSON control files to determine which tables to process, enrich the records with lakehouse data, and write curated Delta tables for reporting. JSON also appears behind the scenes in transaction metadata and other dependencies around Delta Lake processing.

These patterns make JSON parsing more than a file-read operation. It can influence the startup time, throughput, and end-to-end efficiency of an entire job. When a pipeline runs frequently or processes many files, even small costs in parsing and data conversion can accumulate across stages and workloads.

Common customer scenarios include:

Ingesting application, device, web, and service telemetry.

Processing nested records from APIs and partner data exchanges.

Driving reusable pipelines with JSON configuration and control files.

Reading schema, manifest, and metadata files during orchestration.

Transforming semi-structured landing data into governed Delta tables.

How JSON fits into a lakehouse flow

A common lakehouse pattern begins with JSON arriving in the Files area of a lakehouse, through a OneLake shortcut, or from an upstream ingestion process. The records might represent customer activity, application operations, device measurements, or partner transactions. A Fabric notebook reads those files, applies a schema, selects the fields needed by the business, and prepares the data for additional processing.

The same job can then filter invalid or irrelevant events, flatten nested structures, derive business attributes, and combine the JSON records with trusted reference data. Aggregations create useful metrics, while the curated result is stored in Delta tables for downstream notebooks, pipelines, the SQL analytics endpoint, and Power BI. The JSON read is the entry point to this larger analytical flow, so accelerating it helps the job begin productive columnar processing sooner.

Metadata-driven frameworks amplify this effect. A reusable pipeline may read many small JSON documents that describe source locations, schemas, validation rules, transformation steps, and destinations. Those reads happen across multiple tables and recurring schedules. Keeping JSON parsing in the native path helps reduce repeated execution overhead and supports a more efficient foundation for standardized data engineering.

This matters because customers evaluate performance at the job and pipeline level, not only at an individual operator. A faster source reader is most valuable when its output can continue through filters, projections, joins, and aggregations without unnecessary transitions between execution models.

Keeping JSON processing in the native path

The Native Execution Engine accelerates supported Spark operations by offloading them from the JVM-based execution path to a vectorized native engine built on Velox and Apache Gluten (incubating). Columnar processing allows the engine to operate on batches of values instead of repeatedly materializing individual row objects. This design improves data locality, enables efficient use of modern processors, and reduces overhead across many analytical operations.

Before native JSON support, a query that encountered a JSON source used the Spark JVM path for JSON reading and parsing. Even when filters, projections, aggregations, or joins later in the plan were eligible for native acceleration, the data first passed through row-oriented processing and then transitioned into a representation suitable for the accelerated path. Those handoffs reduced the amount of work that could benefit from continuous columnar execution.

With this preview, JSON reading and parsing can run in the Velox-based native layer. Parsed values are produced as columnar batches that can flow directly into eligible native operators. By avoiding an early return to row-based JVM processing, Fabric Spark can reduce execution-path transitions and apply native acceleration across a larger portion of the job.

What this means for your workloads

The most important benefit is broader end-to-end acceleration. Customers can continue to use familiar Spark DataFrame and SQL patterns while the engine handles the execution-path improvements. There is no new JSON-specific programming model to learn and no need to rewrite existing transformations simply to access the native reader.

For ingestion workloads, native JSON processing can help increase throughput before data is standardized into Delta tables. For metadata-driven pipelines, faster reads of configuration and control data can reduce overhead that appears repeatedly across orchestrated jobs. For analytical workloads that query JSON directly, filters and projections can begin from a native columnar source rather than waiting for a JVM-based parsing stage.

The result is a more consistent performance model across common lakehouse formats. Teams can design pipelines around business requirements and data characteristics while Fabric expands the set of operations that remain on the accelerated path.

Use the Spark APIs you already know

Existing notebook code can continue to read JSON with standard Spark APIs. For example, a pipeline can load event data, select the fields needed for analysis, filter the records, and aggregate the results with the same DataFrame operations used today:

events = spark.read.json("Files/events/") daily_activity = ( events.filter("eventType IS NOT NULL") .groupBy("eventDate", "eventType") .count() )

When the plan uses supported operations, Fabric can execute the JSON read and downstream processing in the native columnar path. The optimization is delivered by the platform, so developers can focus on data quality, business logic, and the outputs their users need.

Build faster semi-structured data pipelines

JSON support is another step in expanding the performance coverage of the Native Execution Engine across real customer workloads. It brings acceleration closer to the point where semi-structured data enters the lakehouse and helps preserve columnar execution as that data is filtered, transformed, joined, and aggregated.

To learn how the engine works and how to use it with Fabric Spark, see Native execution engine for Fabric Data Engineering. You can also review Apache Spark runtime in Fabric and Lakehouse and Delta Tables for more information about the broader Fabric data engineering platform.

Get started by running a representative JSON workload in a Fabric notebook and comparing the end-to-end job experience. Review How to use notebooks for guidance and share your experience through the Microsoft Fabric Community. Your feedback helps us prioritize the next areas of acceleration.

Power BI Q&A retirement reminder: February 2027 timeline update

mohammadali — Thu, 10 Sep 2026 16:00:00 GMT

In December, we announced the retirement of Power BI Q&A, our legacy natural-language querying experience, with retirement planned for December 2026. To give current Q&A user's additional time to assess their dependencies and transition to newer Copilot-powered solutions, we’re extending the retirement date to February 2027. This post recaps the affected experiences and provides updates on Copilot capacity availability, embedded scenarios, and sovereign clouds.

Recap of the January announcement

What is being deprecated?

The retirement applies to both the end-user Q&A experiences, and the associated Q&A configuration tools.

Retiring experience	Recommended alternative
Q&A in reports	Copilot with Power BI reports
Q&A on a dashboard	Copilot standalone experience
Q&A virtual analyst in mobile app	Copilot in Power BI Mobile
Q&A in Power BI embedded analytics	Copilot for SaaS scenarios. For embedded PaaS scenarios, refer to the updates later in this post.
Q&A Setup	Prep Data for AI

What happens at retirement?

Beginning in February 2027, Q&A will no longer work in Power BI. The Q&A visual will be removed, and existing reports that contain Q&A visuals will display an error in place of the visual.

Updates since December

Copilot availability across capacities

One of the most common questions following the December announcement was how customers relying primarily on Power BI Pro licenses could adopt Copilot capabilities after the retirement of Q&A.

Copilot is now available across all Fabric capacities starting at F2.

In addition, Fabric Copilot Capacity (FCC), which was initially limited to P1/F64 and above, can now be created on F2 and higher capacities.

FCC is an optional way to centralize Copilot usage for assigned users, including Pro and PPU workspaces, on one capacity. Review the current Copilot requirements.

This change makes Copilot available on smaller Fabric capacities, giving organizations that previously relied on Power BI Pro licenses another path to evaluate Copilot without moving immediately to a larger Premium or Fabric capacity.

Embedded (PaaS) Q&A scenarios

Another common question following the December announcement was whether Copilot would provide a direct replacement for Q&A in embedded (PaaS) scenarios.

There are currently no plans to provide a Copilot replacement for embedded Q&A PaaS scenarios.

Organizations using embedded Q&A should begin evaluating migration paths and alternative analytical experiences well before the February 2027 retirement date. Although these options are not direct replacements for embedded Q&A, customers can consider:

Copilot for SaaS scenarios, for organizations that can transition from an embedded PaaS architecture to a supported SaaS experience.
Narrative visual and smart narrative summaries
Fabric IQ MCP Server

Customers with embedded analytics solutions should review their current Q&A integrations and plan migration paths before retirement.

Copilot in sovereign clouds

Customers operating in sovereign cloud environments have also asked about Copilot availability following the retirement of Q&A.

Copilot does not yet support sovereign clouds due to GPU availability. Organizations using Q&A in sovereign clouds should review their dependencies and contact their Microsoft account representative or support team to discuss migration options.

Recommended next steps

To prepare for the retirement of Q&A:

Inventory existing Q&A dependencies, including reports, dashboards, mobile experiences, embedded solutions, and Q&A Setup artifacts.
Identify the appropriate migration path for each dependency, using Copilot-powered experiences where they are available and meet your requirements.
Review embedded Q&A implementations and evaluate supported SaaS patterns or other analytical experiences.
Confirm Copilot availability in your region, particularly for sovereign cloud deployments, before selecting an alternative.
Plan, test, and communicate changes before Q&A reaches full retirement in February 2027.
Starting these activities early will help ensure a smooth transition before Q&A reaches full retirement in February 2027.

The extension to February 2027 provides additional time to assess existing Q&A dependencies and evaluate replacement experiences. We encourage customers to begin planning their transition now, review Copilot availability and requirements, and test alternative experiences well before retirement. Taking these steps early can help ensure a smooth transition when Q&A reaches end of support in February 2027.

Reassigning a Workspace in the Microsoft Fabric Admin Portal

abiola_david — Thu, 10 Sep 2026 13:38:41 GMT

Reassigning a Workspace in the Microsoft Fabric Admin Portal

When working with Microsoft Fabric, workspaces are an important part of organising and managing analytics content. A workspace can contain items such as Lakehouses, Warehouses, Notebooks, Data Pipelines, semantic models, and Power BI reports.

Depending on how a workspace is configured, it can be assigned to different types of capacity. There may be situations where a workspace that was originally running on a Power BI Pro shared environment needs to be moved to a Microsoft Fabric Capacity.

In this article, I'll show how to reassign a workspace to a Fabric Capacity using the Microsoft Fabric Admin Portal.

For this demonstration, I have a workspace named task wk, which is currently assigned to the Power BI Pro workspace type.

Current Workspace Configuration

I have already created the following workspace:

Workspace Name: task wk Workspace Type: Power BI Pro

At the moment, task wk is not assigned to my Fabric Capacity.

The objective is to move this same workspace from its current Power BI Pro setup and assign it to a Fabric Capacity.

Rather than creating a new workspace, I can simply reassign the existing workspace.

Open the Fabric Admin Portal

The first step is to open the Microsoft Fabric Admin Portal.

From the Fabric interface, open the settings menu and select Admin portal.

The Admin Portal provides administrators with tenant-level management capabilities, including the ability to manage workspaces and their capacity assignments.

For this task, I need to work with the Workspaces section.

Go to the Workspaces Tab

Inside the Fabric Admin Portal, select Workspaces.

This section provides a view of the workspaces available within the Fabric tenant.

I can search for my workspace by name rather than scrolling through the entire list.

In my case, I'm looking for:

task wk

Once I locate the workspace, I can see its current configuration.

The workspace is currently associated with the Power BI Pro workspace type.

Select Reassign Workspace

To change the capacity assignment, I select the ellipsis (...) next to task wk.

This opens a menu containing actions that can be performed on the workspace.

From the menu, I select:

Reassign workspace

This is the option I need to change the workspace's capacity assignment.

Select the Fabric Capacity

After selecting Reassign workspace, Fabric presents the available capacity options.

From here, I select the Fabric Capacity that I want to assign to the workspace.

The important thing is to make sure I select the correct capacity, particularly if the organisation has multiple Fabric capacities.

Once the appropriate Fabric Capacity has been selected, I confirm the reassignment.

Fabric then updates the workspace's capacity assignment.

Verifying the Workspace

After completing the reassignment, I can return to the Workspaces section in the Admin Portal and check task wk again.

The workspace should now show that it is assigned to the selected Fabric Capacity rather than its previous Power BI Pro setup.

The workspace itself has not been recreated. The existing workspace and its contents remain in place; what has changed is the capacity to which the workspace is assigned.

This is useful because I don't need to migrate all the workspace items into a new workspace simply because I want to change the capacity.

Why Reassign a Workspace?

There are several reasons why an organisation might want to reassign a workspace to Fabric Capacity.

One common reason is to make Fabric capabilities available to the workspace.

For example, an organisation may start with a traditional Power BI workspace and later adopt Microsoft Fabric. Moving the workspace to an appropriate Fabric Capacity can be part of that transition.

Capacity assignment can also be useful when an organisation wants to manage workloads using dedicated capacity rather than relying on shared capacity.

A Simple Before and After

In this example, the change can be summarised as:

Before task wk --> Power BI Pro

After the reassignment:

After task wk --> Fabric Capacity

The workspace name remains the same, and I don't have to create another workspace just to make the change.

Things to Consider

Before reassigning a workspace, it is worth checking that you have the appropriate administrative permissions and that the target Fabric Capacity is available.

It is also important to understand the implications of moving a workspace between capacity types, especially in an organisation where capacity usage, governance, and licensing are carefully managed.

The exact options available in the Admin Portal can also depend on the tenant configuration and the permissions of the administrator.

One button, fifty rows: bulk write-back from Power BI to Fabric SQL using a UDF | Part-1

FarhanJeelani — Wed, 09 Sep 2026 18:45:16 GMT

Most writeback examples you'll find handle one record at a time. This one takes whatever the user has selected in the slicer — one hotel or fifty — passes the whole selection to a User Data Function as a single call, and writes it all in one transaction.

Every reporting team eventually gets the same request. Someone looks at a table in a Power BI report, spots a value that is wrong, and asks why they have to email the data team to fix it. In our case it was hotel code setup: mapping each hotel's code types to a Major Group and a Minor Group. The mappings changed often enough to be annoying and rarely enough that nobody wanted to build a whole application for it.

Translytical task flows finally made this practical. This post walks through the setup I actually built and shipped.

The stack is Fabric SQL database → User Data Function → a button in a Power BI report.

What it needed to do

Three requirements shaped everything else.

Edit one hotel or fifty in a single click. Code type mappings are usually rolled out across a brand or a region, not one property at a time. If the user has to click through hotels one by one, they will go back to emailing spreadsheets.

Record who changed what, at column level. "Someone changed the Major Group last month" is not an audit trail. I wanted old value, new value, the person's actual name, and a timestamp, for each column that moved.

Fail loudly and readably. The people using this are finance and operations users, not developers. An error has to tell them what to do next, not surface a SQL exception.

1. The SQL database

Everything starts with the schema. The full script is at the bottom of this post, but three decisions in it are worth explaining because they are the ones that determine whether bulk editing works at all.

The primary key

The original table used CodeType as the primary key. That works fine for one hotel and falls apart immediately for many, because five hotels sharing the code type FBFOOD need five separate rows.

So the table gets a surrogate identity column as the PK, and the real business rule moves into a unique constraint:

CONSTRAINT PK_HotelCodeSetup PRIMARY KEY CLUSTERED (HotelCodeSetupId), CONSTRAINT UQ_HotelCodeSetup_Hotel_Code UNIQUE (HotelCode, CodeType)

The unique constraint is what actually stops duplicates. The surrogate ID exists so the audit table has something stable to point at.

The audit table stores one row per changed column

Not one row per changed record. If a user updates Major Group and leaves Minor Group alone, I want exactly one audit row, saying which column moved and from what to what.

CREATE TABLE audit.HotelCodeSetupAudit ( AuditId BIGINT IDENTITY(1,1) NOT NULL, BatchId UNIQUEIDENTIFIER NOT NULL, InvocationId VARCHAR(100) NULL, HotelCodeSetupId INT NULL, HotelCode VARCHAR(10) NOT NULL, CodeType VARCHAR(20) NOT NULL, ActionType VARCHAR(10) NOT NULL, ColumnName VARCHAR(50) NOT NULL, OldValue NVARCHAR(200) NULL, NewValue NVARCHAR(200) NULL, ChangedBy NVARCHAR(200) NOT NULL, ChangedByOid VARCHAR(50) NULL, ChangedDateUtc DATETIME2(3) NOT NULL, SourceApplication VARCHAR(50) NULL );

BatchId is the piece that makes this usable. One button click produces one BatchId, however many hotels it touched. That gives you a natural unit for "show me everything that click did", and later, for rollback.

Why the audit is not a trigger

This is the one I would have got wrong if I hadn't tested it as a second user.

A trigger runs under the identity of the database connection. In this architecture that connection belongs to the User Data Function, so every single change would be attributed to the same account. The audit would be technically complete and practically worthless.

The user identity has to come from the function's call context and be passed in as a parameter, which means the audit writes have to happen inside the stored procedure, in the same transaction as the change itself.

The upsert

MERGE handles single and multi-hotel through one code path. The hotel list arrives as a comma-delimited string and gets split into a table variable, so one hotel is just a list of length one and there is no separate branch to maintain.

MERGE dbo.HotelCodeSetup WITH (HOLDLOCK) AS tgt USING (SELECT HotelCode FROM @Hotels) AS src ON tgt.HotelCode = src.HotelCode AND tgt.CodeType = @CodeType WHEN MATCHED AND ( ISNULL(tgt.MajorGroup, '') <> ISNULL(COALESCE(@MajorGroup, tgt.MajorGroup), '') OR ISNULL(tgt.MinorGroup, '') <> ISNULL(COALESCE(@MinorGroup, tgt.MinorGroup), '') OR tgt.IsActive = 0 ) THEN UPDATE SET

Two details in there that matter more than they look:

COALESCE(@MajorGroup, tgt.MajorGroup) is how "leave this column alone" works. A blank text slicer becomes NULL, and NULL means keep the existing value rather than wipe it. Without this, a user who only wants to change Minor Group would silently blank out Major Group.

The WHEN MATCHED AND (...) guard means rows that already hold the target values are not touched at all. No pointless ModifiedDateUtc churn, and no audit noise.

The OUTPUT clause writes $action plus old and new values into a table variable, which then gets unpivoted with CROSS APPLY into the column-level audit rows. That unpivot is where the "skip columns that didn't change" filter lives.

Deletes are soft. usp_DeactivateHotelCodes sets IsActive = 0 and audits it, so the audit trail always resolves to a row that still exists.

Run the smoke tests before Power BI is anywhere near this

The bottom of the script has direct EXEC calls for both single and multi-hotel. Run them. If the procedure works in the query editor, then every problem you hit later is a Power BI or UDF problem, and you have halved your search space.

EXEC dbo.usp_UpsertHotelCodeGroups @HotelCodes = 'HTL001,HTL002,HTL003', @CodeType = 'RMREV', @MajorGroup = 'Rooms Division', @MinorGroup = NULL, @ChangedBy = 'test.user@contoso.com';

2. The User Data Function

Create a User Data Functions item in the same workspace. Under Manage connections, add the SQL database, and note the alias Fabric generates. That alias goes into the decorator.

import fabric.functions as fn udf = fn.UserDataFunctions() @udf.connection(argName="writebackDb", alias="Writeback") @udf.context(argName="callContext") @udf.function() def apply_hotel_code_groups( writebackDb: fn.FabricSqlConnection, callContext: fn.UserDataFunctionContext, hotelCodes: str, codeType: str, majorGroup: str = "", minorGroup: str = "", ) -> str:

Three platform rules that are not optional:

Parameter names must be camelCase. No underscores. hotel_codes will not work.
The function must return str if you want it to show up in the Power BI button picker. A function returning a dict simply won't appear in the list, with no explanation.
import fabric.functions as fn and the udf = fn.UserDataFunctions() line are both required.

If the editor complains about the stacked @udf.connection and @udf.context decorators, swap their order. Both sit above @udf.function().

Getting the real user

def _identity(callContext) -> tuple: try: user = callContext.executing_user or {} return (user.get("PreferredUsername") or "unknown", user.get("Oid")) except Exception: return ("unknown", None)

PreferredUsername is the readable one for the report. Oid is the Entra object ID, which is immutable and survives people changing their name or email. Store both.

Validation lives in Python

The stored procedure validates too, as a backstop, but the messages users actually see come from UserThrownError:

if not codes: raise fn.UserThrownError( "No hotel selected. Use the hotel slicer to pick one or more hotels first.", {"hotelCodes": hotelCodes}, ) if len(codes) > MAX_HOTELS_PER_CALL: raise fn.UserThrownError( f"{len(codes)} hotels selected, which is over the {MAX_HOTELS_PER_CALL} limit. " "Narrow the selection and apply in smaller batches.", {"selectedCount": len(codes)}, )

MAX_HOTELS_PER_CALL is set to 250. This is a guard rail, not a performance tuning knob. Power BI hands the function whatever the slicer selection contains, and large payloads run into UDF request size and execution timeout limits. A bulk edit that times out halfway is exactly what the transaction in the procedure is there to protect you from, but it is better not to get there.

The return string is your UI

Since the function has to return a string anyway, make it a useful one. The procedure returns a result set with counts, and the function turns that into something a user can read in the toast notification:

return (f"'{code_type}' across {requested} hotel(s): " f"{detail}. {audit_rows} audit row(s) written. Batch {str(batch_id)[:8]}.")

So the user sees something like "'RMREV' across 12 hotel(s): 9 updated, 3 already matched. 9 audit row(s) written. Batch a3f2c101." That last part is genuinely useful when someone reports a problem, because you can look up the exact batch.

One thing that will bite you when reading the procedure's output: SET NOCOUNT ON helps, but you can still land on a resultless set before the SELECT. Skip forward until there is something to read:

def _first_result_row(cursor): while cursor.description is None: if not cursor.nextset(): return None return cursor.fetchone()

Publish, then test in the portal's Run pane before touching Power BI.

3. The semantic model

Connect Power BI Desktop to the SQL database in DirectQuery.

Point at the SQL database endpoint, not the SQL analytics endpoint. This one cost me an hour. The analytics endpoint mirrors into OneLake on a delay, so when the button refreshes the report the write has not landed yet. The user clicks Apply, the table doesn't change, and they conclude the button is broken. It isn't. You're just reading a copy.

Bring in dbo.HotelCodeSetup and audit.vw_HotelCodeSetupHistory.

4. DAX

This measure is what makes multi-hotel editing work. It collapses the slicer selection into the comma-delimited list the function expects:

Selected Hotel Codes = IF ( ISFILTERED ( HotelCodeSetup[HotelCode] ), CONCATENATEX ( VALUES ( HotelCodeSetup[HotelCode] ), HotelCodeSetup[HotelCode], "," ), BLANK () )

Do not skip the ISFILTERED guard. Without it, an empty slicer returns every hotel in the model. One stray click and you have rewritten the entire estate, correctly, transactionally, and with a beautiful audit trail of the disaster. Returning BLANK() instead makes the function reject the call with a readable message.

Selected Hotel Count = IF ( ISFILTERED ( HotelCodeSetup[HotelCode] ), COUNTROWS ( VALUES ( HotelCodeSetup[HotelCode] ) ), 0 ) Selected Code Type = SELECTEDVALUE ( HotelCodeSetup[CodeType] )

SELECTEDVALUE returns blank when zero or several code types are selected, so ambiguous input gets rejected rather than quietly applied to the wrong one.

And a live button label, because bulk edits deserve a preview of the blast radius:

Apply Button Label = VAR _n = [Selected Hotel Count] VAR _type = [Selected Code Type] RETURN SWITCH ( TRUE (), _n = 0, "Select at least one hotel", ISBLANK ( _type ), "Select one code type", _n = 1, "Apply to 1 hotel", "Apply to " & _n & " hotels" )

Please check Part 2, as the post is a little lengthy.

Get ready for table discovery in OneLake Catalog search (Preview)

nschachter — Wed, 09 Sep 2026 14:09:05 GMT

In late September, OneLake Catalog will begin surfacing tables as searchable objects in Microsoft Fabric. This change expands which table metadata users can discover based on their existing item permissions, so administrators may want to review the related tenant setting before rollout.

To give organizations time to prepare, the controlling tenant setting is already available in the Fabric admin portal. Administrators can review and configure this setting before table search becomes available.

Tables are the first object, an entity contained inside a Microsoft Fabric item, that OneLake Catalog will return as a standalone search result. Bringing objects into search makes the catalog more useful for everyday discovery because they are often where analysis, reporting, and development work begins.

Find tables directly

Finding the right data often starts below the item level. You may know a table name, its purpose, or only the name of a column it contains, but not which item contains it. Table discovery will let you search directly for tables in semantic models, lakehouses, and mirrored databases without first locating and opening the parent item. We plan to support tables from more Microsoft Fabric item types, along with additional object types, as OneLake Catalog expands beyond item-level discovery.

Each matching table will appear as its own result rather than as metadata attached to the parent item. Columns will not appear as standalone results, but you can still find the relevant table when a column name is your only starting point.

Table discovery will be available in Fabric’s global search UI and programmatically through the OneLake Catalog Search API. You will be able to search by table name or description or use an exact column-name match to find its containing table, without knowing the workspace or parent item in advance.

You can also access search through the Fabric Core remote MCP server, Fabric local MCP server, or the search skill from the Fabric Skills library. These options bring the same permission-aware discovery to applications, AI agents, GitHub Copilot, and other compatible AI coding tools.

Figure: A semantic model table returned as a standalone search result.

Understand how permissions affect table visibility

Before table search becomes available, administrators should understand how existing permissions affect what users can discover. This change does not grant access to additional data, but it may allow users to discover metadata for tables contained within items they can already access.

You can discover a table only if you have Read control-plane permission or higher on its parent item. You do not need Read All or Read Data permission to find a table in search.

Data-plane permissions, including OneLake security, do not change whether a table appears in catalog search. The relevant workload still enforces its data-access permissions when you open, query, or otherwise use the table. Catalog discoverability and data access remain separate decisions.

Tables in semantic models protected by object-level security are excluded from search. Object-level security can protect table and column names as well as their metadata, so OneLake Catalog currently does not surface tables from those models.

Control object discovery with a tenant setting

Before table search rolls out, Fabric administrators should review the Users can find objects in search tenant setting. This setting controls whether users can discover contained objects such as tables through Global Search and the Search API.

The setting is enabled by default, allowing users to find supported objects when they have access to the parent item. When it is disabled, search results are limited to top-level Fabric items, such as lakehouses and reports. Disabling the setting does not change access to the underlying items or data; it changes whether contained objects appear in search.

Figure: The tenant setting for controlling object visibility in search results.

Additional search improvements

Apart from table discovery, this release also introduces several improvements in search for Microsoft Fabric items.

Get richer item results

New filters and expanded metadata make item results more precise and useful. You can:

Return and filter item results by endorsement status, workspace ID, and sensitivity label ID.
Find dataflows and dashboards in search results.
Identify reports and dashboards included in a workspace app and retrieve the relevant app context.

This context helps you distinguish between similar items, apply governance signals, and choose the right result without making additional requests.

These improvements provide more ways to narrow large result sets and enough context to understand where an item belongs before you open it.

Refine searches with new operators

New query operators give you more control over how search interprets your terms:

Use quotation marks (" ") to search for an exact phrase.
Use an asterisk (*) as a wildcard for multiple characters.
Use a question mark (?) as a wildcard for a single character.
Use double ampersands (&&) to return only results that contain all specified terms.

These operators help you narrow results when names are similar or when you know only part of a name.

Prepare for rollout

Tables are the starting point for discovery below the Fabric item level. The same catalog model can support more object types over time while preserving parent context, permission trimming, and a consistent way to search. For now, table search addresses a common need: finding the table you want from its name, description, or an exact column-name match without already knowing where it lives.

Table search will begin rolling out late September. Before rollout, administrators should review the tenant setting, and developers can prepare the search experiences they plan to offer:

Review the Users can find objects in search tenant setting in the Fabric admin portal and decide whether object discovery should be enabled for your organization.
Explore the OneLake Catalog Search API if you build data portals, governance tools, or other discovery experiences.
Connect an AI development tool through a Fabric MCP server or install the search skill from the Fabric Skills library to prepare agentic discovery workflows.

One button, fifty rows: bulk write-back from Power BI to Fabric SQL using a UDF | Part-2

FarhanJeelani — Thu, 10 Sep 2026 17:00:00 GMT

5. The report page

Enable Translytical task flows and Text slicer under Preview features in Desktop first, or the Data function action type will not appear on the button at all.

Element	Setup
Hotel slicer	HotelCode, multi-select on. This is what drives single vs bulk.
Code type slicer	CodeType, single select on.
Major group input	Text slicer, no field bound. It's an input box, not a filter.
Minor group input	Text slicer, no field bound.
Table visual	HotelCodeSetup, showing current state.
Audit visual	vw_HotelCodeSetupHistory, sorted by ChangedDateUtc descending.
Apply button	Action → Data function.

Set both text slicers to Edit interactions → None against every other visual. Otherwise typing "Rooms Division" into the input box filters the report down to nothing and the user thinks the data vanished.

Button parameter mapping:

Function parameter	Bind to
hotelCodes	Conditional value → [Selected Hotel Codes]
codeType	Conditional value → [Selected Code Type]
majorGroup	Major group text slicer
minorGroup	Minor group text slicer

Turn on Refresh the report automatically and Auto clear on the button, and bind the button text to [Apply Button Label].

6. Things I learned the hard way

Test as a non-author. Report access and function execute permission are separate grants in Fabric. If they are out of sync, the user gets an opaque error, and the people most likely to hit it are the least equipped to interpret it. Grant your writeback audience Execute on the User Data Functions item explicitly, then log in as one of them and click the button.

Deployment pipelines do not rebind the button. The button stores a hard reference to a specific workspace, function set, and function. Promote dev to test to prod and it is still pointing at dev, even when an identically named function exists in the target workspace. It will happily write dev data from your prod report. Repoint it manually after every deployment, and put that on the release checklist.

Decide your insert policy deliberately. @AllowInsert = 1 means editing a code type for a hotel that doesn't currently have one creates the row. That is convenient, and it is also a way for typos to become master data. Pass 0 if setup rows should only ever originate from your master data process.

The analytics endpoint thing. Worth repeating because it presents as "the button does nothing", which sends you looking in entirely the wrong place.

7. Audit queries that earn their keep

-- Everything one button click did SELECT * FROM audit.vw_HotelCodeSetupHistory WHERE BatchId = '<batch-guid>' ORDER BY HotelCode; -- Full history for one hotel and code type SELECT ChangedDateUtc, ChangedBy, ActionType, ChangeDescription FROM audit.vw_HotelCodeSetupHistory WHERE HotelCode = 'HTL001' AND CodeType = 'FBFOOD' ORDER BY ChangedDateUtc DESC; -- Who is making bulk changes SELECT ChangedBy, COUNT(DISTINCT BatchId) AS Batches, COUNT(*) AS ColumnChanges FROM audit.HotelCodeSetupAudit WHERE ChangedDateUtc >= DATEADD(DAY, -30, SYSUTCDATETIME()) GROUP BY ChangedBy ORDER BY ColumnChanges DESC;

The view builds a readable line per change:

CONCAT(a.ColumnName, ': ', ISNULL(a.OldValue, '(blank)'), ' -> ', ISNULL(a.NewValue, '(blank)')) AS ChangeDescription

So the audit visual on the report reads "MajorGroup: Food & Bev -> Food & Beverage" rather than making the user mentally diff two columns.

What's next

Because the audit stores old and new values per column and groups them by BatchId, rollback is a replay of OldValue for a given batch. That is the obvious third function to build once the main flow has been stable for a while. I have deliberately not built it yet, on the grounds that an undo button written in week one tends to be the thing that needs undoing.

Wrapping up

The pattern generalises well beyond hotel codes. Any reference or mapping table that business users maintain, and that currently lives in a spreadsheet somebody emails around, is a candidate. The parts worth copying are the ones that are not obvious from the tutorials:

Surrogate PK plus a unique constraint on the real business key, so bulk editing is possible at all.
Audit inside the procedure rather than in a trigger, so the identity is the report user.
COALESCE in the update so blank means "leave alone", not "erase".
ISFILTERED in the DAX so an empty slicer can't rewrite everything.
A hard cap on selection size in the function.

Happy to answer questions in the comments. If you have built something similar and solved the deployment pipeline rebinding problem more elegantly than "remember to do it manually", I would genuinely like to hear it.

PBIX File & full scripts: 01_schema_and_procs.sql and 02_user_data_function.py are attached below.

You Can Create Calculated DAX Columns in Direct Lake — But Should You?

amitchandak — Wed, 09 Sep 2026 14:03:44 GMT

Adding calculated columns in DAX for Direct Lake gives a lot of flexibility and feels like an easy option... BUT.....

Advancing the Microsoft Fabric SQL Query Editor

salilkanade1 — Tue, 08 Sep 2026 19:00:00 GMT

The Microsoft Fabric SQL Query Editor is the home for web-based SQL development in Fabric. It gives developers a workspace to explore warehouse data, write and run SQL, among many more capabilities.

That work rarely starts and ends with a single query. Developers navigate large schemas, author and refine SQL, inspect results, share findings, and connect validated work to downstream analytics and operational workflows. As warehouses and teams grow, each of those steps can introduce friction, from finding the right object, to managing an increasing number of queries or moving between different Fabric experiences.

The latest SQL query editor updates are focused on reducing that friction and making the development experience faster, more scalable, and more connected across Fabric.

A scalable editor for any size warehouse

Working with a warehouse becomes harder when the development tools do not scale with the environment.

Large schemas can make objects difficult to navigate, metadata-heavy environments can slow down authoring assistance, and large query results can become cumbersome to inspect in the browser.

The latest updates strengthen the core web SQL query editor experiences across Object Explorer, IntelliSense, and the results grid so developers can stay productive as their warehouse grows.

To learn more about the rich capabilities the SQL query editor offers, explore the SQL query editor documentation.

A faster, more capable data grid (Generally Available)

Running a query is only useful if developers can quickly understand the output.

Large or wide result sets can be difficult to inspect when the grid is slow or when values do not fit comfortably on screen, often pushing developers to export data just to review it.

The brand-new data grid improves performance and makes data and result previews easier to inspect directly in the web SQL query editor. Developers can resize columns for wide result sets, while expanded support for larger LOB data types makes it possible to review larger values directly in the grid, with many more improvements coming soon.

Figure: Animated GIF - Brand new results grid, now with support for resizing columns.

For additional information regarding the data grid, refer to the Data preview documentation.

Object explorer built for large databases (Generally Available)

Finding the right table, view, or schema should not become harder simply because a warehouse contains thousands of objects.

The redesigned object explorer is significantly optimized for performance when navigating large warehouse environments while keeping schema browsing responsive as the number of objects grows.

Developers can also pin frequently used tables, views, and schemas, reducing the need to repeatedly navigate through large object hierarchies during everyday development.

Figure: Animated GIF - New object explorer (left) vs. old object explorer (right) loading times for thousands of user objects.

To learn more, refer to the Object explorer documentation.

IntelliSense, redesigned for scale (Generally Available)

SQL authoring becomes increasingly dependent on good database context as schemas grow. Developers should not need to remember every table, column, or object name before they can start writing a query. With improved IntelliSense responsiveness in larger warehouse environments, developers can spend less time looking up object names and more time building and refining their queries.

Better query management for development workflows

The number of queries developers work with tends to grow alongside the warehouse.

Exploratory queries become reusable queries. Saved SQL queries accumulate across projects. Queries need to be shared for team review, revisited later, or cleaned up once they are no longer useful.

New query management capabilities make that ongoing work easier to maintain directly within the query editor.

Copy and share queries with their context (Preview)

Sharing SQL often means separately copying the query, capturing its output, and explaining which results came from which version of the logic.

The new copy query experience makes it easier to keep those pieces together.

Developers can copy a query together with its results or generate a link that opens the query directly in the tool of their choice. This makes reviews, validation, and collaboration easier while reducing the extra steps required to pick the work back up in another experience.

Figure: Animated GIF - Copy query experience in the SQL query editor.

More control with autosave (Generally Available)

Not every SQL editing session represents work a developer wants to preserve in the same way. Exploratory changes may be temporary, while active development may need to be continuously protected from accidental loss.

Developers can now toggle autosave on or off, giving them more control over how changes are preserved based on the way they are working.

Figure: Animated GIF - Autosave on/off configuration in SQL query editor.

Manage queries at scale (Generally Available)

Saved queries can quickly accumulate across ongoing development, investigation, and experimentation. Managing them one at a time becomes increasingly tedious as that collection grows.

Bulk query management makes it easier to select and manage multiple queries at once, helping developers clean up old work and keep their query collections organized as projects evolve.

Figure: Animated GIF - Bulk management capabilities for queries.

Import and export .sql files (Generally Available)

SQL development often extends beyond a single tool or environment. Developers may already have queries stored as .sql files or need to move work between Fabric and other parts of their development workflow.

The SQL query editor now supports importing .sql files directly for editing, sharing and execution, as well as exporting queries as .sql files for use elsewhere.

This makes it easier to bring existing SQL into Fabric, preserve work in a portable format, and move queries between tools without manually copying and pasting code.

Figure: Animated GIF - Export queries as .sql files from the SQL query editor for development in other tools.

Extending SQL into analytics, semantics, and operations

SQL development often produces the starting point for work that continues elsewhere.

A developer may validate warehouse data in SQL and then need to analyze it with another engine, connect it to a semantic model, or use the result as part of an ongoing monitoring workflow. Moving between these experiences can interrupt the development flow and create additional steps between understanding the data and doing something with it.

New integrations make those transitions more direct from the SQL query editor.

Analyze warehouse data across OneLake (Generally Available)

Different analytical problems often call for different tools.

A developer may begin by exploring warehouse data with SQL but later need Spark for broader data processing or KQL for another analytical scenario. Traditionally, moving between engines can also introduce additional data movement or setup.

Directly from the SQL query editor, developers can now create Eventhouse endpoints or notebooks that work with the same warehouse data using KQL or Spark. This makes it easier to choose the engine that best fits the task while staying connected to the same data in OneLake. Learn more about OneLake analytics in the Eventhouse endpoint documentation.

Figure: Animated GIF - Create Notebooks and Eventhouse Endpoints directly from the SQL query editor for Spark and KQL based analysis on warehouse data.

To learn more about OneLake analytics, refer to the Eventhouse endpoint documentation.

Connect SQL to the semantic layer (Generally Available)

Validated SQL and warehouse data frequently become the foundation for downstream reporting and BI.

Without a direct path into semantic modeling, developers and BI teams often must leave the web SQL Query Editor and start that workflow separately, even when they are working from the same underlying warehouse data.

Developers now have the option to create a Direct Lake over OneLake semantic model directly from the SQL query editor, making it easier to move from exploring and validating warehouse data into building a semantic model without extra navigation or setup.

Figure: Animated GIF - Create Direct Lake semantic models from the SQL query editor.

To learn more about creating semantic models on warehouse data, refer to the Power BI semantic model documentation.

Turn SQL queries into operational workflows with Fabric Activator (Preview)

Developers often rerun the same SQL queries to monitor changing conditions and catch issues that need attention. That creates repetitive work for developers and operators who need to continually inspect business conditions or workload signals.

The new Fabric Activator integration, now in preview, makes those SQL queries in warehouse more operational. Developers can define conditions based on query results and trigger follow-up actions when those conditions are met. Instead of repeatedly running SQL to look for an issue, the query can become part of an ongoing workflow that surfaces when attention or action is needed.

Figure: Animated GIF - Creating an alert on a SQL query.

To learn more, refer to the alert rule documentation.

A more complete web SQL query editor experience

These updates are designed around a simple idea: developers should spend more time working with their data and less time working around their tools.

Faster navigation and authoring reduce friction in large warehouse environments. Better query management makes ongoing SQL development easier to maintain. Deeper Fabric integrations reduce the distance between writing a query and using that work across analytics, semantic models, and operational workflows.

Together, these capabilities make the SQL query editor a more complete development experience for working with warehouse data, from finding the right object and writing SQL to validating results and carrying that work forward across Fabric.

Ready to get started? Refer to the SQL query editor documentation.

This is just the start of a series of rich investments to make the Microsoft Fabric SQL Query Editor an even more powerful and productive environment for web-based SQL development in Fabric, with many more capabilities coming soon. Stay tuned!

Building and Enriching a Microsoft Fabric Data Agent on a Power BI Semantic Model

Praful_Potphode — Tue, 08 Sep 2026 13:46:21 GMT

Microsoft Fabric’s Data Agents are one of the most exciting additions to the Fabric ecosystem for Power BI practitioners. They let business users ask questions in plain English and receive grounded answers directly from a governed semantic model, without needing to write DAX or SQL.

In this post, I’ll explain why you might place a Data Agent on top of a Power BI semantic model, how to set one up, and, most importantly, how to enrich it so it provides high-quality, trustworthy answers.

The big idea: Business users ask questions in plain English. The agent reasons over a curated semantic layer and returns grounded, governed answers rather than invented results.

1. What Are Data Agents, and Why Use Them?

Data Agents let people ask plain-English questions about their data and receive context-rich answers. Under the hood, they use Azure OpenAI models to interpret the question, determine which data source is most relevant, and generate an appropriate query: SQL for a warehouse or lakehouse, DAX for a semantic model, and KQL for event data.

The result is presented as a readable response containing tables, summaries, or insights while respecting the user’s existing security permissions. Because Data Agents connect directly to governed data in OneLake, they make analytics accessible to users who may never open Power BI Desktop or write a query.

1.1 What Is the Difference Between Copilot and a Data Agent?

Both Fabric Copilot and Fabric Data Agents use generative AI, but they are designed for different scenarios.

Copilot is embedded within the current Fabric experience, such as a Power BI report, and helps users complete context-specific tasks such as creating visuals or writing DAX. A Data Agent is a standalone conversational analytics experience that can connect to as many as five data sources and can be integrated with experiences such as Microsoft Teams, Microsoft 365 Copilot, Copilot Studio, and custom applications.

Data Agents support custom instructions, business terminology, verified answers, and reusable integrations. They are read-only and honor existing security. This makes them suitable for domain-specific, governed self-service analytics, while Copilot remains useful for assistance within the current Fabric item.

2. Prerequisites and Setup

To create a Data Agent, you need Fabric capacity and at least one supported data source containing data, such as a lakehouse, warehouse, Power BI semantic model, KQL database, mirrored database, or ontology.

You should also have a well-designed Power BI semantic model with governed measures, meaningful relationships, clear naming, and appropriate security. Cross-geo processing must be enabled when your data is stored in a different region. Read permission on the semantic model is sufficient; Build permission is not required.

3. Preparing the Semantic Model: The Most Important Step

Preparing the semantic model is the foundation of a reliable Data Agent. Before adding the model to the agent, configure it using Power BI’s Prep for AI capabilities.

Use business-friendly names. Give tables, columns, and measures clear names. Hide technical keys, housekeeping fields, and other objects that users should not query.
Organize the model. Group related columns and measures into display folders, such as Customer, Sales, Profit, and Time Intelligence.
Add descriptions and synonyms. Explain what each important table, column, and measure represents, and include the terminology users are likely to use.
Validate relationships. Ensure the model has the correct active relationships, filter direction, and date behavior.
Apply security. Configure RLS and OLS where required. The Data Agent respects the semantic model’s security.
Configure Prep for AI. Define the AI data schema, semantic-model instructions, and verified answers. When a Data Agent queries a semantic model, its DAX-generation tool relies on the model metadata and Prep for AI configuration. Data Agent-level instructions are not used to generate DAX, so model-specific calculation and filtering rules must live in the semantic model.

4. Creating and Configuring the Data Agent

In your Fabric workspace, select New item, choose Fabric data agent, give the agent a descriptive name, and create it. The OneLake catalog will appear, allowing you to add supported data sources. Select the Power BI semantic model and any other required sources, then choose only the tables the agent needs for the intended business questions.

4.1 Configuring the Data Agent

Creating the agent is only the starting point. To improve accuracy and keep the experience useful over time, treat it as an evolving system and use an iterative process of testing and refinement.

1. Add Data Agent instructions. These instructions govern orchestration and presentation. Use them to define source-routing priorities, response structure, clarification behavior, business terminology, and how results should be summarized or visualized.

2. Add semantic-model instructions. These belong in Prep for AI and explain how AI should understand and query the model. Include governed measures, date rules, relationships, filter logic, definitions, and important safeguards.

One important separation: Semantic Model AI Instructions explain how AI should understand the model. Data Agent Instructions explain how the agent should orchestrate and communicate.

3. Start with a benchmark set. Build a representative set of business questions with expected queries and answers. Use it to evaluate accuracy and expand coverage systematically.

4. Diagnose incorrect responses. Determine whether an incorrect answer was caused by missing metadata, unclear instructions, incomplete examples, an ambiguous user question, or a semantic-model issue.

5. Refine the instructions. Clarify data-source priorities, business definitions, date behavior, summary-versus-detail rules, and expected output formatting.

4.2 Best Practices and Recommendations

Use descriptive table, column, and measure names so the agent can understand the schema.
Build specialized agents for specific domains and limit each source to the tables and columns needed for that domain.
Be explicit about what the agent should do, not only what it should avoid.
Define business terms, abbreviations, synonyms, date rules, and important calculation logic.
Provide representative verified answers for common and complex questions.
Select only the sources and objects needed to answer the expected questions. A focused configuration improves query accuracy and efficiency.
Use SQL, DAX, or KQL examples only where they materially clarify complex joins, filters, or date logic.
Validate results under different user identities to confirm RLS and OLS behavior.

These practices help the Data Agent interpret questions correctly, query the right source, and return clear, context-rich answers.

5. Enriching and Evolving the Data Agent

You can enrich the agent with instructions, examples, terminology, and response rules. Data Agent instructions should define tone, routing, clarification, response formatting, and visual policy across sources. Avoid placing semantic-model-specific calculation logic at this level.

Use verified answers to anchor common business questions to the expected interpretation and governed query. As you test the agent, review both the returned result and the generated query. If an answer is incorrect, refine the semantic model metadata, AI data schema, verified answers, or instructions based on the actual cause.

Evaluate and Iterate with the Fabric Data Agent SDK

Evaluation is essential to the ongoing development of a Data Agent. Use the Fabric Data Agent SDK to test representative questions at scale, compare actual results with expected answers, and identify patterns in failures.

An effective evaluation set should include common questions, ambiguous questions, unsupported requests, date and comparison scenarios, hierarchy navigation, security-sensitive questions, and follow-up questions that depend on conversational context.

Add Code Interpreter

Code Interpreter gives the Data Agent a secure, sandboxed Python environment for analyzing retrieved data. With it enabled, the agent can support calculations, deeper analysis, and visualizations that go beyond the initial query result.

The governed data source should still produce the underlying result first. Code Interpreter should analyze that result rather than recreate business logic outside the semantic model.

6. How Data Agents Work at Runtime

When a user asks a question, the Data Agent uses Azure OpenAI to interpret the request and determine the most suitable connected source. It accesses each source under the user’s identity and security context.

For a Power BI semantic model, the agent uses the model’s metadata and Prep for AI configuration to generate and execute a DAX query. It then formats the governed result as a conversational response. Because the query runs under the user’s permissions and honors model and workspace security, the agent only returns information that the user is authorized to access.

7. Benefits and Limitations

Data Agents make governed analytics more accessible by reducing the need for users to write queries or build a report for every question. They can bring multiple supported data sources into one conversational experience while honoring existing security and governance.

However, a Data Agent is not automatically accurate simply because it is connected to trusted data. Its results depend on semantic-model quality, relevant metadata, clear instructions, verified answers, focused source selection, and continuous evaluation. Complex root-cause or predictive questions may also require additional analytical logic beyond a straightforward governed query.

8. Conclusion

Microsoft Fabric Data Agents provide a powerful new way to interact with enterprise data. By combining a well-prepared Power BI semantic model with focused Data Agent configuration, verified answers, clear instructions, and ongoing evaluation, you can create a conversational analytics experience that users can trust.

The goal is not merely to connect AI to data. The goal is to connect AI to governed business meaning.

Building a Better Microsoft Fabric Data Agent: Instructions, Visual Policy, and Cost-Aware Design

Praful_Potphode — Tue, 08 Sep 2026 13:34:16 GMT

Connecting a semantic model to a Fabric Data Agent is the easy part. The real work starts when the agent needs to understand what your business actually means.

A Fabric Data Agent can generate technically valid DAX and still return the wrong business answer. The missing piece is often not the model itself; it is the context we provide around it.

Consider this question:

Which region performed best last quarter?

It sounds straightforward, but the agent must make several decisions before it can answer.

What does performed best mean?

Highest Sales?
Highest Profit?
Best Profit Margin?

Which date defines last quarter?

Order Date?
Ship Date?

Should the agent return only the leading region, compare every region, or create a chart? If a governed Profit Margin measure already exists, should the agent use it or recreate the calculation from raw columns?

These are not primarily DAX questions. They are context and governance questions.

After working with Fabric Data Agents beyond the proof-of-concept stage, I stopped treating instructions as one large prompt. A reliable implementation has several layers:

Data enrichment
Semantic Model AI Instructions
Data Agent Instructions
Routing and ambiguity handling
Response and visual policy

Each layer has a different responsibility. Getting these layers right improves answer quality and can also reduce unnecessary reasoning, retries, query execution, and overly verbose responses.

1. There Is a Cost to Ambiguity

Fabric Data Agent consumption is token-based. The user’s question is only one part of the context processed by the AI. Agent instructions, source instructions, example queries, conversation history, and supporting context can also contribute to the input.

At the time of writing, the published consumption rates are:

1,000 input tokens = 100 CU seconds
1,000 cached input tokens = 10 CU seconds
1,000 output tokens = 400 CU seconds
Data-source query execution is charged separately

This creates an important architectural consideration.

A Poorly Prepared Data Agent

Imagine that a user asks:

Which region performed best?

The agent assumes that performance means Sales, executes a query, and returns an answer. The user then replies, I meant profitability.

Now we have another interaction, another round of reasoning, another response, and potentially another underlying query.

A better approach is to define the business interpretation once:

When performance is used without a specific KPI, evaluate both Sales and Profit.

The objective should not be to use the fewest tokens possible. It should be to use the minimum useful context required to produce the right answer with the least unnecessary reasoning.

A small prompt that produces the wrong answer is not an optimization. Adding thousands of characters of unnecessary instructions to every interaction is not an optimization either.

Optimize for cost per successful answer, not tokens per prompt.

2. Data Enrichment Comes First: Start with the Model

Semantic-model enrichment was covered in our previous article, so I will not repeat the full process here. The main principle is that a focused AI Data Schema, clear descriptions, relevant synonyms, governed measures, and a clean model reduce ambiguity and help the AI focus on the objects that matter.

Important: Instructions should add business context. They should not be used to repair a poorly designed semantic model.

Data Enrichment Guide - https://community.fabric.microsoft.com/blog/community_blog/why-your-fabric-data-agent-gives-wrong-answers-and-how-data-enrichment-fixes-it/5361211

3. The Most Important Separation: Semantic Model Instructions vs. Data Agent Instructions

Semantic Model AI Instructions and Data Agent Instructions are not the same, and they should not contain the same information.

Data Agent-level instructions are not passed to the DAX-generation tool used for semantic-model query generation. This changes how the instruction architecture should be designed.

Consider this rule:

When a user asks for margin, always use the governed Profit Margin measure.

If this rule exists only in the global Data Agent instructions, it is placed at a layer that the DAX-generation tool does not directly use. The rule belongs in the Semantic Model AI Instructions.

The easiest way to remember the separation is:

Semantic Model AI Instructions explain how AI should understand and query the model.
Data Agent Instructions explain how the agent should orchestrate and communicate.

Once this separation is clear, the overall framework becomes easier to maintain.

4. Semantic Model AI Instructions: Give the Model a Clear Purpose

Use Semantic Model AI Instructions for rules that affect how the model should be interpreted and queried. The business rules will change across Finance, Sales, HR, Supply Chain, Operations, and other domains, but the structure does not have to change.

Instead of one long block of rules, use a repeatable framework:

SEMANTIC MODEL AI INSTRUCTIONS
1. Purpose and Scope
2. Measure Priority
3. Authoritative Objects
4. Business Definitions
5. Governed Measure Mapping
6. Business Rules
7. Time Rules
8. Source Priority
9. Default Behaviour
10. Ambiguity Rules
11. Domain Restrictions
12. Cross-Domain Rules

The principle is straightforward:

If a rule changes the query, it probably belongs close to the semantic model.

Reusable Semantic Model Instruction Framework

5. Keep the Data Agent Focused on Orchestration

Once semantic logic lives at the correct layer, the Data Agent instructions become much cleaner. A generic framework can look like this:

DATA AGENT INSTRUCTIONS
1. Purpose
2. Scope
3. Data Source Behaviour
4. Response Policy
5. Visual Policy
6. Insight Generation
7. Recommendation Policy
8. Comparison Rules
9. Large Result Handling
10. Conversation Style
11. Explainability
12. Formatting
13. Missing Data
14. Follow-up Questions
15. Guardrails

The production pattern should reinforce one key rule:

Retrieve governed results from the semantic model and never override the model’s business rules, measure selection, relationships, or calculations.

Reusable Data Agent Instruction Framework

6. Make the Response Policy Adaptive

A fixed seven-section response can be useful for deep analysis, but it is unnecessary for a simple question such as:

What were Total Sales in 2025?

An adaptive response policy is more effective:

Simple KPI Question

Answer directly.
State the important period and filter context.
Keep the response concise.
Do not force a chart.

Analytical Question

State the scope.
Provide a short summary.
Show the supporting result.
Create one useful visual.
Highlight the key takeaways.

Deeper Analysis

Add recommendations and follow-up questions only when they provide real value. A useful analytical flow is: Scope, Executive Summary, Supporting Details, Visual, Key Takeaways, Recommendations, and Follow-up Questions.

7. Visual Policy Should Be Governed Too

Fabric Data Agent can generate native visual responses, and Data Agent Instructions can influence when a visual should be used and which supported chart type should be preferred.

At the time of writing, the supported visual types include:

Line chart
Multi-line chart
Column chart
Multi-column chart
Stacked column chart
Pie chart
Scatter plot
Area chart
Stacked area chart

A simple intent-based policy can map trends to line charts, category comparisons to column charts, composition to stacked columns, small part-to-whole comparisons to pie charts, and numeric relationships to scatter plots.

The safeguards matter just as much:

Do not create a visual when it adds no value.
Create a visual when the user explicitly requests one and the request is supported.
Do not generate several charts when one is sufficient.
Keep the KPI, filters, comparison, and time context consistent.
Never change the business calculation simply to produce a visual.

A chart should explain the result. The result should never be changed to fit the chart.

8. Guardrails Matter More Than More Instructions

A good instruction framework should make its non-negotiable behavior explicit.

Always

Respect semantic-model rules.
Respect the user’s filters.
Respect security.
Use governed results.

Never

Recreate governed KPIs.
Fabricate values.
Infer causes without evidence.
Override semantic-model logic.
Expose technical objects unnecessarily.
Change the user’s scope without permission.

9. What Changes When the Source Is SQL?

Now imagine that the same Data Agent also has access to a Fabric Warehouse.

A semantic model already provides relationships, governed measures, business-friendly metadata, DAX calculations, and a semantic layer. A raw SQL source is different. The Data Agent may need more direct guidance about:

What each table represents.
How tables should be joined.
Which columns own particular business concepts.
Which date should be used.
Common stored values and their meaning.
The grain of each fact table.
Query patterns that are not obvious from object names.

For SQL sources, use Data Source Instructions as a concise onboarding guide for someone seeing the database for the first time.

SQL Data Source Instruction Pattern

SOURCE PURPOSE
Use this source for Sales, Customer, Product,
and Inventory analysis.

TABLE GRAIN
FactSales contains one row per Order Line.
FactInventory contains Product inventory by location.

JOIN RULES
FactSales.CustomerKey → DimCustomer.CustomerKey
FactSales.ProductKey → DimProduct.ProductKey
FactSales.DateKey → DimDate.DateKey

BUSINESS RULES
Revenue = SUM(SalesAmount)
Order Count = COUNT(DISTINCT OrderID)
Do not use COUNT(*) for Order Count because
one Order can contain multiple Order Lines.

DATE RULES
Use OrderDate for normal Sales analysis.
Use ShipDate only for shipping or fulfillment questions.

QUERY RULES
Use explicit joins.
Avoid SELECT *.
Return only required fields.
Do not expose technical keys unless requested.

The goal is not to document the entire database. Include only the context that materially affects query generation.

Example Queries Demonstrate the Pattern

Consider the question:

Who are the top 10 customers by revenue?

SELECT TOP 10
    c.CustomerName,
    SUM(s.SalesAmount) AS Revenue
FROM FactSales s
INNER JOIN DimCustomer c
    ON s.CustomerKey = c.CustomerKey
GROUP BY
    c.CustomerName
ORDER BY
    Revenue DESC;

This single example teaches the agent:

Which fact table contains Sales.
How Customer should be joined.
How Revenue is aggregated.
How customer-level grouping works.
How Top N ranking should behave.

Instructions explain the rule. Example queries demonstrate the pattern.

A few carefully chosen examples are usually more valuable than dozens of near-identical queries.

10. Limitations to Keep in Mind

Data Source Instructions improve context, but they do not turn a SQL source into a governed semantic model.

Instructions do not repair poor data modeling.
Do not place every business KPI inside SQL instructions.
Stored values may need to be documented explicitly.
Example queries are patterns, not hard-coded answers.
Too many examples can create noise.
SQL Data Source Instructions are different from Semantic Model AI Instructions.

11. Final Thought

Building a reliable Fabric Data Agent is not about writing the longest possible prompt. It is about putting the right context at the right layer.

Use metadata to explain the data. Use Semantic Model AI Instructions to govern how the model is interpreted. Use Data Source Instructions and examples to guide SQL generation. Use Data Agent Instructions to govern orchestration, response behavior, visuals, and guardrails.

The goal is not more instructions. It is less ambiguity.

That is what moves a Fabric Data Agent from a successful demo toward governed conversational analytics.

References

Microsoft Learn: Data Agent consumption

Microsoft Learn: Semantic model best practices for Data Agent

Microsoft Learn: Configure your Data Agent

Microsoft Learn: Visual responses from a Fabric Data Agent

Microsoft Learn: Improve Data Source routing

GitRep - AI Instruction Framework

What have you found most difficult when moving a Fabric Data Agent from a proof of concept into a governed production experience? Share your experience in the comments.

Why Refresh the Whole Model When Only One Table Changed? Power BI Finally Lets You Choose

pankajnamekar25 — Tue, 08 Sep 2026 13:26:20 GMT

The problem: refreshing everything when you only needed a little

Picture a semantic model with a few tables: a large Sales fact table that updates every day, a Products table that changes maybe once a month, and a Currency Exchange Rate table that barely changes at all. For as long as most of us have used Power BI, hitting "Refresh" meant refreshing the entire model - every table, every time, whether it actually needed it or not.

Worse, a normal refresh always did two things at once: it checked whether anything about your data source's structure had changed (a schema sync), and then it reloaded all the actual data. Most of the time you only care about one of those. You just want fresh numbers in your Sales table - you don't need Power BI to re-check whether your Currency table's column structure changed, because it never does. But there was no way to say "just get me new data, skip the schema check," or "refresh only this one table." You got the whole thing, every time.

This wasn't just an annoyance - for larger models, refreshing everything when you only needed a fraction of it meant longer waits, more load on your source systems, and refresh operations eating into your daily refresh limits for no good reason.

The old way to get around this

If you needed genuinely granular control before this update, your only real option was going through the XMLA endpoint or the REST API - writing code to say "refresh just this table" or "refresh just this partition." This worked, but it required Premium or Fabric capacity, technical setup, and honestly, a level of comfort with scripting that most report builders don't have or need for day-to-day work. For anyone just using the standard Power BI Service interface, there was no such option - it was full refresh or nothing.

What changed

In the August 2026 update, Power BI brought this kind of control directly into the Service UI, no scripting required. You now get two separate improvements working together:

First, refresh type options. Instead of one generic "Refresh" button that always does a schema sync plus a data refresh, you can now choose exactly what you want:

- Refresh schema and data - the original all-in-one behavior, still available when you genuinely need both

- Sync schema only - checks and applies any structural changes from your data source, like new columns, without reloading all the data

- Refresh data only - reloads fresh data without checking for schema changes at all

Second, table-level refresh. Instead of applying that choice to your entire model, you can now apply it to just one specific table.

A real example

Back to our Sales, Products, and Currency Exchange Rate model. Say it's the middle of a regular business day, and you just want today's sales numbers updated - nothing else has changed.

Open the semantic model in Model view within the Power BI Service.
Instead of hitting the generic top-level Refresh button, find the Sales table specifically.
Choose Refresh data only for just that table.

Power BI reloads fresh data into Sales, and leaves Products and Currency Exchange Rate completely untouched - no unnecessary schema check, no reloading tables that didn't need it. What used to be a full-model operation is now a targeted, few-second action.

Where this saves the most time

- Large models with tables that update on very different schedules - a fast-changing fact table alongside slow-changing dimension tables that rarely need touching

- Direct Lake models specifically, where a Lakehouse table might have gained new columns, you're not ready to bring into your model yet - you can refresh the data without pulling in that schema change

- Anyone managing refresh limits or capacity usage, where cutting unnecessary schema syncs and full-model reloads adds up to real savings over dozens of refreshes a day

What to keep in mind

This is a Power BI Service feature, so it's something you'll do from the web interface managing a published semantic model, not from Power BI Desktop while you're building. It's also worth remembering that "Sync schema only" and "Refresh data only" are meant to be used thoughtfully - if you genuinely don't know whether a data source's structure has changed recently, doing a full "Refresh schema and data" occasionally is still the safer choice, especially before a report goes out to a client or stakeholder.

If you've been refreshing an entire model out of habit when only one table actually needed it, this is worth checking out the next time you're in the Power BI Service.

Thanks for reading!

Connect with me on:
LinkedIn |
Data With Pankaj - YouTube

Fabric Influencers Spotlight: August 2026

slindsay — Thu, 10 Sep 2026 18:01:37 GMT

Explore the August Fabric Influencers Spotlight featuring community-driven guidance, tutorials, AI use cases, and Power BI insights from Microsoft MVPs and Fabric Super Users. Discover practical examples of Microsoft Fabric in action across governance, data engineering, analytics, real-time intelligence, and AI.

How to Connect Salesforce to Power BI from Inside Salesforce

metrica — Fri, 04 Sep 2026 15:17:14 GMT

Learn how to connect Salesforce to Power BI, manage reusable data sources inside Salesforce, securely authenticate Power BI connections, and embed finished Power BI reports back into Salesforce dashboards.

Fabric Data Warehouse best practices for medallion architectures

Scirqueira — Thu, 03 Sep 2026 21:00:00 GMT

Part three of a series on medallion architecture with Fabric Data Warehouse.

Good medallion architecture is mostly operational discipline.

In part one of this series, we chose the pattern, and in part two, we filled in the Bronze, Silver, and Gold layers. Now comes the part that usually determines whether the architecture holds up in production: the operating rules. Many medallion architectures look great on paper but become difficult to maintain as data volumes, business requirements, and consumers grow.

A medallion pipeline is easy to explain and easy to demo. It is more challenging to keep clean over time. The challenges usually start small: row-by-row loads, report-specific logic in the wrong place, transformations that cannot be safely rerun, or Gold tables that slowly become another staging layer.

Why this matters

Most medallion problems are not caused by the names Bronze, Silver, and Gold. They happen because the pipeline stops behaving like a pipeline.

Bronze starts cleaning. Silver starts serving dashboards. Gold starts compensating for upstream data quality. Before long, nobody knows where a rule belongs, and every change feels risky.

The goal of best practices is not to add ceremony. The goal is to make the pipeline predictable: predictable loads, repeatable transformations, trusted outputs, and clear places to look when something breaks.

Best practice 1: Batch the writes

Fabric DW is built for set-based work. Treat ingestion and transformations as batches, not as a stream of tiny row-by-row operations.

In Bronze, that usually means using COPY INTO, Fabric Pipelines, or other bulk-loading patterns to land data in raw tables. If you are loading from files, aim for fewer well-sized files instead of many tiny ones. When practical, files in the 100 MB to 1 GB range are a healthier starting point than a long tail of small files.

In Silver and Gold, the same idea applies: prefer set-based T-SQL transformations, CTAS, INSERT...SELECT, and MERGE patterns over procedural row-at-a-time logic.

Do this well

Load Bronze in batches, and avoid trickle inserts when the source can be staged first.
Add ingestion metadata, such as source file name and load timestamp, so every batch is traceable.
Keep operational logging lightweight. If you need very high-write audit events, do not turn the warehouse into a single-row logging engine.
Let Bronze preserve the batch; let Silver decide what is valid.

Rule of thumb: if a load pattern creates a large number of tiny writes, fix the load pattern before tuning the query.

Best practice 2: Make Silver rerunnable

Silver is where the pipeline earns trust. That means Silver transformations need to be repeatable, testable, and safe to rerun.

If an upstream source reloads, or a cleansing rule changes, you should know how to rebuild the affected Silver tables without guessing which reports need to be patched. This is where idempotent design matters: a transformation should produce the same result when run again against the same inputs.

In Fabric DW, use CTAS when you want to materialize a clean table from a query, INSERT...SELECT for controlled incremental loads, and MERGE when late-arriving or changed data needs to update existing Silver rows.

Do this well

Design transformations so they can run again without duplicating or corrupting data.
Use staging tables when the logic is complex. A few clear steps are easier to operate than one unreadable query.
Put quality gates in Silver: required fields, valid formats, duplicate handling, and reason codes for rejected records.
Choose precise data types and lengths. Silver is the right place to turn loose source data into reliable analytical data.

Rule of thumb: if a report needs to clean the data again, Silver did not finish its job.

Best practice 3: Shape Gold for consumption

Gold is not just “the final table.” Gold is the business-facing serving layer. It should be modeled around how people ask questions, not around how the source systems store data.

For some workloads, that means a star schema with fact and dimension tables. For others, it means a data mart, a wide reporting table, or a pre-aggregated summary. The pattern matters less than the principle: Gold should make the common analytical path simple, fast, and trustworthy.

This is also where you should be careful not to let Gold become a junk drawer. If Gold is full of one-off fixes, report-specific exceptions, and raw technical fields, the layer is doing too much.

Do this well

Model the grain explicitly. A fact table without a clear grain becomes hard to explain and harder to debug.
Pre-aggregate where the business repeatedly asks the same question.
Hide technical fields that helped the pipeline but do not help the consumer.
Keep Gold dependent on Silver by default. Direct Gold-to-Bronze dependencies should be rare and deliberate.

Rule of thumb: Gold should answer the business question quickly without making the report author rediscover the pipeline.

Best practice 4: Use Fabric DW defaults, but do not fight the engine

Fabric DW gives you a SQL warehouse over Delta data in OneLake. That means you get transactional behavior, optimized storage patterns, and a managed engine that handles many physical decisions for you.

The practical advice: do not bring every habit from traditional data warehousing with you. You do not need to micromanage distribution or indexing the same way you would in older platforms. Focus first on healthy data layout, set-based transformations, good table design, and predictable query patterns.

At the same time, do not ignore the basics. Query performance still benefits from clean data types, useful statistics, well-shaped Gold tables, and avoiding unnecessary scans.

Do this well

Keep V-Order and platform optimizations on unless you have a measured reason to change them.

Use the performance guidance for Fabric Data Warehouse before inventing custom tuning patterns.

Check query behavior when a Gold table becomes critical to many reports.

Treat advanced exceptions as exceptions. Most teams should start with the defaults and tune only when evidence says to tune.

Rule of thumb: tune from evidence, not from habit.

Best practice 5: Monitor by layer

A medallion pipeline should be observable at each layer. If a dashboard is wrong or slow, you should be able to tell whether the issue started in Bronze ingestion, Silver transformation, or Gold serving.

In Fabric DW, use Query Insights and the warehouse monitoring views to understand query behavior, expensive operations, and refresh patterns. Pair that with pipeline-level monitoring so you can see not only whether a job failed, but where the failure happened.

Measure the pipeline in terms the team can act on: Bronze load duration, Silver transformation duration, rejected-record counts, Gold refresh duration, and Gold query performance.

Do this well

Track load and refresh duration by layer.
Log the number of records received, accepted, rejected, and published.
Watch critical Gold queries after refresh, especially the ones that feed executive dashboards or widely used semantic models.
Keep operational alerts tied to business impact. A failed Gold refresh matters differently from a delayed Bronze load.

Rule of thumb: if you cannot tell which layer failed, your monitoring is not layer-aware enough.

Before moving a medallion pipeline into production, use the following checklist to verify that each layer is operating as intended.

The best-practice checklist

Area	Bronze	Silver	Gold
Write pattern	Batch ingest with metadata	Set-based transformations	Scheduled refreshes
Quality rule	Preserve what arrived	Validate, conform, and flag	Expose trusted fields only
Performance focus	Avoid tiny writes	Keep logic rerunnable	Shape for common queries

Takeaway

Part two of this series was about one job per layer. Part three is about operating each job like it matters.

Batch the writes. Make Silver rerunnable. Shape Gold for consumption. Use Fabric DW’s managed engine instead of fighting it. Monitor the pipeline by layer so failures are easy to locate and fixes happen in the right place.

If you follow those rules, your medallion architecture becomes less fragile over time, not more.

This post is part of our Medallion Architecture on Fabric Data Warehouse series:

Choosing your medallion pattern in Fabric Data Warehouse
Building the Bronze → Silver → Gold layers
Fabric DW best practices for medallion architectures
Securing and governing your layers
Performance tuning your medallion pipeline

Ready to go deeper? Explore the Microsoft Fabric Data Warehouse performance guidelines and ingestion guidance, then stay tuned for Part four of this series, where we’ll cover securing and governing your layers.

Workspace Outbound Access Protection (OAP) for Operations Agent and Fabric Maps (Preview)

BisiAdele — Thu, 03 Sep 2026 20:00:00 GMT

Co-authors: Andre Terceros and Bodhisatva Gautam

Workspace Outbound Access Protection (OAP) in Microsoft Fabric helps WS admins secure outbound connections from workspace items to external resources. Administrators can control outbound access by blocking unwanted connections by default and allowing only approved connections through configured rules.

As organizations adopt AI-powered operations at scale, governance and security remain at critical requirements. With this preview release, Microsoft Fabric introduces Outbound Access Protection (OAP) for Operations Agent and Fabric Maps, enabling workspace administrators to control the outbound actions an agent can perform.

OAP for Operations Agent

When OAP is enabled, Operations Agent continues to perform core functions including reasoning, recommendation generation, rule evaluation, and telemetry collection. However, outbound actions are governed by the workspace's configured access policies. Administrators gain greater visibility through in-product notifications, Teams messaging experiences, and the Operations Agent Activity Log, making it easier to identify and troubleshoot blocked actions.

Figure: Outbound Access Protection helps workspace administrators govern outbound Operations Agent actions while providing clear visibility when actions are blocked.

What's new with Operations Agent and OAP?

With Outbound Access Protection support for Operations Agent, workspace administrators gain more control over how agent-initiated actions interact with external services and resources. The following updates improve governance, visibility, and operational oversight while helping organizations continue to automate with confidence.

Govern outbound agent actions through workspace-level OAP policies.
Control whether Operations Agent can send Teams notifications based on allowed connections.
Prevent unauthorized cross-workspace actions when OAP policies restrict outbound access.
Receive clear visibility when actions are blocked through in-product notifications and Teams messaging experiences.
Monitor agent activity and OAP-related outcomes through the Operations Agent Activity Log.

Figure: Activity Log Operations Details show the steps the agent completed and each action’s status, including when an action is blocked.

OAP for Maps

Fabric Maps can connect to a variety of data sources, including Lakehouse across Fabric workspaces, Kusto databases (KQL), Ontologies as well as external geospatial services such as Web Map Services (WMS), Web Map Tile Services (WMTS), and Web Feature Services (WFS).

Workspace Outbound Access Protection helps organizations maintain security and compliance by governing outbound connections and requiring explicit approval before a map can access external resources.

With OAP enabled, Fabric Maps follows a "default deny" model, ensuring only approved destinations can be accessed.

How it Works

When Workspace Outbound Access Protection is enabled on a workspace, Fabric Maps evaluates outbound connectivity at multiple stages:

Save and Load Operations

Whenever a map is created, updated, or loaded, Fabric evaluates all referenced data sources against the workspace policy.

If a data source isn't permitted:

References are blocked
Disallowed sources are redacted when the map is opened
Attempts to save unsupported references are rejected

Runtime Data Access

Map visuals continuously retrieve data such as:

Map tiles
Geospatial features
Query results

Before each outbound request is executed, Fabric validates the destination against the workspace's outbound access protection policy.

External Service Validation

External geospatial services such as WMS, WMTS, and WFS are validated through Data Movement and Transformation Services (DMTS). DMTS acts as a policy enforcement layer and ensures only explicitly approved external endpoints can be reached.

Supported Connection Scenarios

Lakehouse

Lakehouse connectivity receives the most flexibility under the current release.

Lakehouse within the same workspace are always allowed.
Lakehouse in other workspaces can be allowed using Data Connection Rules.
Administrators maintain granular control over cross-workspace access.

External Geospatial Services

Organizations can securely connect to approved WMS, WMTS, and WFS services.

By using Data Connection Rules with the Geospatial Web Services connection type, administrators can create an allow list of approved endpoints.

This enables scenarios such as:

Accessing enterprise GIS systems
Consuming approved mapping services
Integrating with external geospatial data providers

Kusto Databases and Ontologies

Connections to Kusto databases and Ontologies within the same workspace continue to function normally.

Cross-workspace connectivity for these sources is currently blocked when OAP is enabled. Future releases will introduce additional policy controls for these connection types.

Configuring Fabric Maps with Workspace OAP

Enabling protection is straightforward:

Enable Workspace Outbound Access Protection for the workspace.
Create Data Connection Rules that define approved destinations.
Add approved external geospatial services using the Fabric connection experience.
Configure Geospatial Web Services rules to authorize required endpoints.

Once configured, Fabric Maps can access only the approved destinations specified by policy.

Security by Design

Workspace OAP for Fabric Maps follows several key security principles:

Explicit Allow Lists: Only approved destinations can be reached. All other outbound connectivity is automatically blocked.
Consistent Enforcement: Policies are applied during authoring, loading, and runtime execution, ensuring continuous protection throughout the lifecycle of a map.
Fail-Closed Protection: If policy validation services become unavailable, Fabric denies cross-workspace connections by default. This fail-closed behavior helps prevent unintended data exposure during service disruptions.

What’s next?

We are actively working to expand OAP support for additional experiences and plan to add support for Power BI Semantic Models and Reports soon in GA soon.

Your feedback is essential! Let us know how we can make Fabric even more secure and flexible for your workloads by sharing your feedback at Fabric Ideas – Microsoft Fabric Community

Learn more

Manage Fabric connections at scale with connection recency in Fabric REST APIs

ryanjadams — Thu, 03 Sep 2026 19:50:43 GMT

Understand Connection Recency

Connections are shared infrastructure in Microsoft Fabric. Pipelines, dataflows, semantic models, and other Fabric items use them to reach data sources without storing connection details and credentials in every item. Connection Recency adds the context administrators need to understand how each connection is being used. If you go to “Manage Connections and Gateways” in Fabric settings and open the settings of any connection, the following information card will populate:

Figure: Connection Recency shows when a connection was created, last linked to an item, and last used to access credentials.

The card provides three insights:

Created on shows when the connection was created.
Last Bound to items shows when an item was most recently associated with the connection. By any user reflects activity across the tenant, and By me is specific to the viewer.
Last credentials used shows when a workload most recently used the connection credentials. It also separates activity By any user from activity By me, which is the current user.

Linking and usage are different events. A connection can be linked but never used, or it could have been linked a long time ago to an item that still runs every day. Credential-use information can also be up to 30 minutes behind real time, so use it for governance and investigation rather than immediate usage monitoring.

Learn more in the Data source management documentation.

Why enterprise connection management becomes difficult

Connections can grow exponentially across a large organization. Every team, project, environment, gateway, and data source can introduce more connections. Over time, names become inconsistent, employees move on, and multiple connections can point to the same endpoint. The Fabric interface is useful for inspecting one connection, but reviewing recency and ownership one connection at a time does not scale to an enterprise inventory.

This creates three common problems:

Stale connections: A connection may no longer support an active workload, but its name, creation date, and Last Bound Date do not prove that it is unused. Administrators need both Last Bound Date and Last Credential Use signals before deciding what to review or retire.
Duplicate connections: Different display names can hide equivalent connection definitions. Duplicates increase credential maintenance, complicate troubleshooting, and make it harder to establish a preferred connection which dilutes the advantage of connection sharing and reuse across a tenant.
Ownership risk: A connection with only one person as an owner can become orphaned when that person leaves the organization. The connection might then be unavailable for administration or no longer usable by dependent workloads.

The REST APIs make it possible to evaluate these risks across every connection the caller can access. In the case of cloud connections, you can only see connections where you are the owner, but the admin for a gateway can see all connections on the gateway. This provides better scalability than the UI.

Using the APIs to manage connections

You can use the APIs to identify stale and duplicate connections for removal and to help mitigate the issue of single user ownership. Gateways in Fabric have a limit of 1,000 connections, so managing and governing your connections will help you stay under that limit.

Now that we understand each of the three scenarios, let’s see what the API can provide to help us handle each scenario:

Stale connections:
- LastBoundDateTime is the first of two signals we can use. If this is NULL, then it is currently not being used by a Fabric item and would be a candidate for removal. The one catch is that connections bound prior to recency being introduced will also show NULL, so we must filter out anything with a CreatedDateTime earlier than the introduction of the recency feature. Recency came out in preview at the end of March 2026, so my example code will filter anything created prior to May 1, 2026, to play it safe.
- The second signal we have is the LastCredentialUsedDateTime, which indicates the last time the connection was used by any item. You can change this in the example code, but I’m going to use 90 days. You might have connections that legitimately get used less frequently, such as year-end runs or only during the holiday season, so keep that in mind when reviewing and adjust accordingly.
Duplicate connections:
- It is possible for two connections to have identical configurations except for the DisplayName. This defeats the purpose of having shareable connections, so we’ll need to use the LastCredentialUsedDateTime to determine which one was most recently used and flag any others to be considered for removal or consolidation. We’ll use ConnectionType, ConnectionPath, ConnectivityType, and GatewayID to identify duplicates. There are other columns you may want to add, such as CredentialType or ConnectionEncryption, depending on what you consider duplicate in your specific environment.
Ownership risk:
- For ownership continuity, you want to identify connections whose only Owner role assignment is a User, then add another approved owner. This helps avoid having an orphaned connection if an owner gets deleted. Adding a Microsoft Entra group is preferred because group membership can be maintained as people join, leave, or change responsibilities. A second individual owner is better than a single owner, but it does not provide the same durable operating model as group ownership.

MYTH: A common misconception is that a connection fails when its owner account is deleted. In reality, what matters is the credential being used for authentication. When you create a connection that uses OAuth, you become the owner and your OAuth credential is typically used. If your account is later deleted, the connection fails because it can no longer authenticate with that credential, not because ownership changed. If the connection instead uses an SPN and is shared with another user, it will continue to work.

Explore the List Connections, List Connection Role Assignments, and Add Connection Role Assignment documentation for the complete request, pagination, identity, and permission details.

Next steps

Run the companion notebook first. The notebook is designed as a Python notebook to be run in the Fabric Python runtime and not the PySpark Python runtime. There will be a section for each of the previous scenarios. Stale and duplicate connections will be shown so you can review before deciding what to remove, but that part will be up to you. You can use the data frame and pass the connection ID values to the Delete Connection API. If you don’t know how to write that part, then it’s a great opportunity to use Copilot.

The ownership section will show you all connections with a single owner where you will want to add another owner. As a best practice, we’ll assume you are adding a group, but that part will be commented out as you very likely do not want to blatantly add the same group to every connection across the board. You can use the Add Connection Role Assignment API to make those additions as you need.

Connection recency data gives you the signals you need to manage connections at scale, but it should be the starting point for review rather than the basis for automatic removal. Use the companion notebook to identify potentially stale or duplicate connections and connections with a single owner, then apply your organization’s requirements before taking action. Regularly reviewing these signals can help you reduce unnecessary connections, improve ownership continuity, and establish a more manageable connection inventory.