New blog articles in Microsoft Fabric Community

Grounding Fabric Data Agents so they stop inventing columns | Part-1

FarhanJeelani — Mon, 14 Sep 2026 17:04:12 GMT

Your data agent answers a question about churn by writing SELECT customer_id, churn_flag FROM dim_customer. There is no churn_flag column. There never was. The agent produced confident SQL against a column it made up, the query failed, and the person who asked has now decided the whole thing is a toy.

This is the single most common complaint I see about Fabric data agents in the community, and almost every answer to it is the same: "add better AI instructions." That advice is not wrong, but it is the weakest lever available and people reach for it first.

Here is the thing that changes how you approach the problem. An agent does not invent a column because it is disobedient. It invents a column because the question implied a concept that your schema does not name, and generating something plausible is the only move it has. You cannot instruct your way out of that. You have to close the gap between the words your users use and the words your schema uses.

So the fix is a stack, and it is worth being blunt about which layers actually carry weight:

Layer	Effort	How much it actually helps
Shape the schema the agent sees	High	Most of the win
Scope tables and columns tightly	Low	Large
Data source instructions and descriptions	Medium	Moderate
Example queries (few-shot)	Medium	Moderate, and underused
Agent instructions	Low	Small on its own
Evaluation harness	Medium	Not accuracy, but it is how you keep accuracy

Most teams do this list backwards. Below is each layer with the actual configuration.

First, confirm it is actually hallucinating

Before you fix anything, find out what happened. Two different failures look identical from the chat window:

The agent referenced a column that does not exist.
The agent referenced a real column that means something different from what the user assumed.

The second is far more common and far more dangerous, because it returns a number instead of an error. A status column that means shipment status answering a question about payment status will produce a clean, wrong answer that nobody catches for a quarter.

Use the Diagnostics button in the data agent. <cite index="47-1">It downloads a snapshot of the agent's configuration and execution steps, including data source settings, the instructions that were applied, which example queries were used, and the steps the agent took to produce its response.</cite> Read the generated SQL, not the answer. If you are debugging by reading answers, you are debugging the wrong artifact.

Layer 1: Shape what the agent can see

The agent reads your schema. If your schema is tbl_cust_mstr with columns flg1, dt_2, and amt_ttl, no instruction block will save you.

Build a view layer for the agent. Do not point it at your raw tables. Create a schema of AI-facing views with names that match how people actually speak, and expose only those.

-- Fabric Warehouse (T-SQL). The agent sees this, not the underlying tables. CREATE SCHEMA ai; GO CREATE VIEW ai.customer AS SELECT c.cust_sk AS customer_key, c.cust_no AS customer_number, c.cust_nm AS customer_name, g.ctry_cd AS country_code, g.ctry_nm AS country_name, c.seg_cd AS segment_code, CASE c.seg_cd WHEN 'E' THEN 'Enterprise' WHEN 'M' THEN 'Mid-Market' WHEN 'S' THEN 'Small Business' END AS segment_name, c.acq_dt AS acquisition_date, CASE WHEN c.term_dt IS NOT NULL THEN 1 ELSE 0 END AS is_churned, c.term_dt AS churn_date, c.act_flg AS is_active FROM dbo.dim_cust c LEFT JOIN dbo.dim_geo g ON g.geo_sk = c.geo_sk WHERE c.is_current = 1; -- collapse SCD2 so the agent never has to reason about it GO

Four things happened there, and each one removes an entire class of hallucination:

is_churned now exists. The agent no longer has to invent it. This is the whole game. Every time you see a hallucinated column, ask whether it should be a real column.
Codes are decoded. segment_name means the agent never has to guess that 'E' is Enterprise, and users can ask about "enterprise customers" in their own words.
SCD2 is collapsed. Slowly changing dimensions are a reliable source of silently wrong answers, because the agent has no reason to know it must filter to the current row.
Cryptic names are gone. amt_ttl invites guessing; total_amount_usd does not.

If you cannot create views, at minimum use column descriptions on the tables you do expose. The SDK <cite index="41-1">supports adding column and table descriptions for SQL data sources</cite>, and they carry real weight in query generation.

Then scope hard. <cite index="46-1">A data agent supports up to five data sources, and for each one you select the specific tables the agent can use.</cite> Select fewer than you think. Twelve well-described tables outperform sixty raw ones, every time. Ambiguity is the raw material of hallucination, and every table you add manufactures more of it.

One trap specific to lakehouses: <cite index="46-1">the agent answers using the lakehouse tables you select and does not read standalone files such as CSV or JSON unless they are ingested or exposed as tables.</cite> If your answer set lives in Files, the agent cannot see it, and it will improvise around the gap rather than tell you.

Layer 2: Data source instructions (per source, not global)

There are two distinct instruction fields and people conflate them constantly.

Data source instructions attach to a single data source and are used during query generation. <cite index="31-1">They improve the agent's ability to select the right tables and columns, understand data-specific logic such as fiscal calendars and regional codes, apply consistent filters, and interpret intent.</cite> This is where anti-hallucination content belongs, because it sits closest to the SQL being written.

Here is a template. Replace the specifics; keep the structure.

SCOPE This source contains the ai.* views only. Every question about customers, subscriptions, invoices and revenue is answered from these views. TABLE MAP ai.customer – one row per current customer. Grain: customer_key. ai.subscription – one row per subscription. Grain: subscription_key. A customer may hold several subscriptions. ai.invoice_line – one row per invoice line. Grain: invoice_line_key. This is the only source of revenue. ai.date – calendar and fiscal date dimension. Grain: date_key. JOIN PATHS ai.subscription -> ai.customer on customer_key ai.invoice_line -> ai.subscription on subscription_key Any table -> ai.date on date_key Never join ai.invoice_line directly to ai.customer. Go through ai.subscription, or revenue will be duplicated across subscriptions. DEFINITIONS "Revenue" = SUM(ai.invoice_line.net_amount_usd). Never gross_amount_usd. "Churn" = ai.customer.is_churned = 1. "Active customer"= ai.customer.is_active = 1. "ARR" = SUM(ai.subscription.annual_contract_value_usd) WHERE ai.subscription.status = 'Active'. "Enterprise" = ai.customer.segment_name = 'Enterprise'. TIME The fiscal year starts on 1 April. For any question mentioning a fiscal period, use ai.date.fiscal_year and ai.date.fiscal_quarter. For any question mentioning a calendar period or naming a year with no other qualifier, use ai.date.calendar_year. "Last month" means the most recent complete calendar month, not the trailing 30 days. VALUE FORMATS country_code is a two-letter ISO code ('AE', 'SA', 'GB'), never a full country name. To filter on a country name, use country_name. segment_name is one of: Enterprise, Mid-Market, Small Business. All amounts are already in USD. Do not apply currency conversion. CONSTRAINTS Use only the columns listed in the table map above. If a question requires a column or a concept that does not exist in these views, do not substitute a similar column and do not construct one. State which specific column would be needed and stop.

That last paragraph is the only genuinely instruction-shaped anti-hallucination content in the whole block, and it is the least important part of it. Everything above it works by removing the need to guess. The constraint paragraph only catches what slipped through.

Note the join warning. Fan-out across a one-to-many join is the most common cause of a plausible-but-doubled number, and it produces no error at all.

Layer 3: Agent instructions (routing and terminology)

Agent instructions are global. <cite index="28-1">You can write up to 15,000 characters of plain English to instruct the agent on how to handle queries, including which data source to use for which kind of question, and definitions for words, acronyms or terms the AI consistently misinterprets.</cite> <cite index="46-1">For example: direct financial metrics to a Power BI semantic model, raw data exploration to the lakehouse, and log analysis to the KQL database.</cite>

Keep this layer short and about routing. Detail belongs at the source level.

ROUTING Questions about revenue, ARR, bookings or any officially reported financial metric -> the "Finance Reporting" semantic model. These figures are governed and must match published reporting. Questions about customer counts, subscription details, product usage or any exploratory or ad-hoc analysis -> the "CustomerLH" lakehouse. Questions about system errors, latency, ingestion failures or anything described as logs, events or telemetry -> the "PlatformEvents" KQL database. If a question spans finance and customer detail, answer the financial part from the semantic model and say explicitly which part came from which source. ORGANISATIONAL TERMS "GCC" = the countries AE, SA, KW, QA, BH, OM. "MENA" = GCC plus EG, JO, LB, MA, TN. "NRR" = net revenue retention. Only reported from the Finance Reporting model; do not compute it from raw invoice data. "Logo" = a customer account, not a brand asset. "Logo churn" means customer count churn, not revenue churn. BEHAVIOUR Always state which data source answered the question. When a question is ambiguous between two definitions, ask one clarifying question rather than picking one silently. Never present an estimate as a reported figure.

The terminology section earns its place. "Logo churn" is exactly the kind of phrase that sends an agent hunting for a column that does not exist.

One boundary worth understanding: <cite index="46-1">instructions sit in a precedence model beneath organisational policy and role-based permissions, and above end-user prompts. Where they conflict with policy, the agent refuses or redirects.</cite> Your instructions configure behaviour; they do not grant access.

Layer 4: Example queries, which almost nobody uses properly

This is the most underused surface in the whole product. <cite index="46-1">You can add sample question-and-query pairs that show the agent how to interpret similar questions</cite>, and <cite index="46-1">you get up to 100 per data source.</cite> Most agents I look at have three.

Few-shot examples do something instructions cannot: they demonstrate the join path, the filter convention, and the column vocabulary in the exact form the agent has to produce. An instruction saying "always join through subscription" is a claim. An example query showing it is a pattern.

Pick your examples deliberately. Cover:

The canonical join, so the fan-out path is demonstrated rather than described.
The fiscal-versus-calendar distinction, one example each.
The metric everyone asks for differently. If revenue is asked as "sales", "turnover" and "top line", write one example per phrasing.
The concept your schema does not have. More on this below.

-- Q: What was our revenue in the GCC last fiscal quarter? SELECT SUM(il.net_amount_usd) AS revenue_usd FROM ai.invoice_line il JOIN ai.subscription s ON s.subscription_key = il.subscription_key JOIN ai.customer c ON c.customer_key = s.customer_key JOIN ai.date d ON d.date_key = il.date_key WHERE c.country_code IN ('AE','SA','KW','QA','BH','OM') AND d.fiscal_quarter = ( SELECT fiscal_quarter FROM ai.date WHERE date_key = CAST(GETDATE() AS DATE) ) - 1;

-- Q: How many enterprise customers churned in calendar 2025? SELECT COUNT(DISTINCT c.customer_key) AS churned_customers FROM ai.customer c JOIN ai.date d ON d.date_key = c.churn_date WHERE c.is_churned = 1 AND c.segment_name = 'Enterprise' AND d.calendar_year = 2025;

One limitation to plan around: <cite index="46-1">example query pairs are not currently supported for Power BI semantic model data sources.</cite> If you route financial questions to a semantic model, that source gets instructions and a well-described model, and nothing else. Invest correspondingly more in the model's own metadata and measure descriptions.

There is also a preview assistant that can help you generate this configuration. <cite index="27-1">Build agent with AI mode summarises key entities, likely join paths and important columns, surfaces patterns from successfully executed queries in your query history, and proposes candidate few-shot examples and data source instructions.</cite> <cite index="27-1">It is currently limited to SQL and Eventhouse sources and will not run if you add an unsupported source.</cite> Treat its output as a first draft you edit, not a configuration you accept.

Please check part-2 of this post

Diagnose Fabric Data Warehouse workloads with the SQL DW operations skill (Generally Available)

Mariyaali — Mon, 14 Sep 2026 17:00:00 GMT

When a warehouse slows down, the investigation usually starts with more questions than answers. Was there a capacity spike? Did a specific query suddenly become expensive? Are requests failing, being canceled, or simply taking longer than usual?

Answering those questions often requires switching between the Fabric Capacity Metrics app, Query Insights, and SQL pool diagnostics while manually correlating time ranges across multiple tools. The SQL DW operations skill brings those investigations into a single workflow and is now generally available.

Available through the open-source Microsoft Fabric skills repository, the SQL DW operations skill lets you describe a problem in natural language using a compatible AI coding tool such as GitHub Copilot CLI. The skill runs bounded, read-only diagnostics and returns a structured diagnosis, supporting evidence, recommended actions, and validation steps.

What you can do with the SQL DW operations skill

The SQL DW operations skill helps you:

failure-analysis: Separate failed queries from canceled requests, identify affected workloads, and resolve engine error codes.
resource-consumers: Find recurring resource-consuming query patterns, regressions, and changes in execution volume or per-run cost.
capacity-metrics-correlation: Connect a Capacity Metrics spike to warehouse activity in the same time window.
pool-pressure: Diagnose contention and identify workloads that might benefit from custom SQL pools.
lakehouse-health: Find lakehouse tables with small-file, deleted-row, or checkpoint issues.
query-reference: Use the appropriate read-only system views and Query Insights queries for bounded operational analysis.
scenarios: Combine the diagnostics into guided workflows for common warehouse incidents.

Each response separates the diagnosis, evidence, ruled-out causes, recommendations, and customer follow-ups. Measurements are tied to their source, and zero-row results are treated as valid evidence instead of prompting an invented explanation.

Common use cases

Start with the operational question rather than selecting system views or writing diagnostic SQL.

Figure: GIF depiction of how the SQL DW operations skill connects a natural-language prompt to bounded, read-only diagnostics and customer follow-up actions.

Investigate failed and canceled queries

Analyze failed and canceled queries in SalesWarehouse during the last 24 hours.

The skill uses Query Insights to identify affected users, applications, query patterns, and SQL pools. It resolves failed engine codes through sys.messages and keeps cancellations separate because they can reflect a user-initiated cancellation, a client timeout, or resource pressure.

Explain a performance slowdown

Explain why FinanceWarehouse was slow between 09:00 and 11:00 UTC yesterday.

The skill checks SQL pool pressure, overlapping requests, CPU, elapsed time, and storage scans. It distinguishes contention from a directly expensive query or a broad increase in workload.

Find resource-consuming query patterns

Find the top resource-consuming queries in SalesWarehouse and compare them with the previous seven days.

The skill groups requests by query shape and separates higher execution volume from increased per-run cost, new query patterns, and one-time expensive runs.

Investigate a capacity spike

Use the Fabric Capacity Metrics app to investigate the CU spike from 14:00 to 15:00 UTC, then identify expensive SQL users and query patterns.

Following the warehouse metering update introduced in August 2026, Capacity Metrics shows when consumption occurred and how much was reported based on allocated warehouse compute over time. Query Insights explains what ran during the same period.

The skill discovers the installed Capacity Metrics model, identifies a costly warehouse or SQL analytics endpoint, and analyzes Query Insights requests that overlap its time window. It doesn't join Capacity Metrics operation identifiers to Query Insights statement identifiers. Capacity consumption and warehouse CPU are complementary signals, not interchangeable measurements.

Assess custom SQL pool candidates

Assess whether recurring workloads in SalesWarehouse are candidates for custom SQL pools based on the last 30 days.

If repeated pressure is associated with a consistent application name, such as an ingestion service or reporting application, the skill can recommend testing that workload in a custom SQL pool. It identifies the application to isolate and the pressure, latency, CPU, scan, and failure measures to compare before and after the pilot.

Get started

Prerequisites

Before you start, make sure you have:

GitHub Copilot CLI or another compatible AI coding tool.
An active Fabric warehouse or lakehouse SQL analytics endpoint.
Contributor or higher access to the workspace.
The Microsoft Fabric Capacity Metrics app installed for capacity-spike investigations.

Add the Microsoft Fabric skills marketplace in GitHub Copilot CLI:

/plugin marketplace add microsoft/skills-for-fabric

Install the Fabric skills bundle:

/plugin install fabric-skills@fabric-collection

Then open Copilot CLI in a project folder and describe the warehouse issue you want to investigate. Include the workspace, warehouse or SQL analytics endpoint, and UTC time range when possible.

For detailed permissions, setup, supported scenarios, and diagnostic time limits, see Diagnose warehouse workloads with the SQL DW operations skill.

Next Steps

Install or update the Microsoft Fabric skills bundle.
Review Query Insights in Fabric Data Warehouse.
Review monitoring options for Fabric Data Warehouse.
Learn about custom SQL pools.

From Business Events, Fabric Events, and Azure Events to Real-Time Hub

robece-msft — Mon, 14 Sep 2026 16:59:28 GMT

Welcome to the eighth and final 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.

Forecasting with Autoregression, ARIMA & AIC / BIC for Data Science in Microsoft Fabric

Sahir_Maharaj — Mon, 14 Sep 2026 13:57:38 GMT

In this edition, we’re exploring forecasting through Autoregression, ARIMA, and the model selection tools AIC and BIC. By the time you’re done reading, you’ll understand how data can actually learn from its own patterns, how ARIMA helps bring structure to unpredictable trends, and how AIC and BIC keep your models grounded by balancing accuracy with simplicity.

How to Connect SAP to Power BI Through SAP BTP

metrica — Mon, 14 Sep 2026 13:57:05 GMT

Learn how to connect SAP to Power BI through SAP BTP using Metrica Software’s connector. This step-by-step guide covers creating reusable OData data sources, managing access, and loading SAP data into Power BI.

Schema Compare in VS Code: Simplifying Fabric Warehouse Deployments

techies — Mon, 14 Sep 2026 13:55:53 GMT

Deploying databases shouldn't feel uncertain. Synchronizing development and production schemas in Microsoft Fabric Warehouse can be challenging as database objects evolve. A frequent issue arises when the .sqlproj file isn't configured with the Fabric-specific schema provider (SqlDbFabricDatabaseSchemaProvider). Misconfiguration may lead Schema Compare to flag supported Fabric objects as unsupported. To avoid this issue, explicitly specify the schema provider in the .sqlproj XML if the GUI does not offer that option.

In this blog, let's take a quick look at how to get started.

Before using Schema Compare with Fabric Warehouse, make sure you have the following prerequisites.

You need access to an existing Warehouse item within a Microsoft Fabric workspace, with Contributor or higher permissions.
You also need Visual Studio Code installed on your workstation.
Next, install the .NET SDK, which is required to build and publish database projects.
Finally, install these two Visual Studio Code extensions:

SQL Database Projects
SQL Server (mssql)

Both extensions are available directly from the Visual Studio Code Marketplace.

After installing the extensions, open Visual Studio Code and select "Add Connection" to connect to Fabric Warehouse.

Enter the required server and authentication details, and complete the connection.

After connecting, access the Warehouse directly in Visual Studio Code.

Open Schema Compare

Now navigate to Database Projects in Visual Studio Code.

You should see your available database projects and connections. Right-click the database project or connection and select "Schema Compare."

Schema Compare gives you an object-level view of the differences between the source and target.

You can compare schemas between:

.dacpac files
Databases
SQL database projects

Comparison results outline actions to align target with source.

Instead of treating the database as a single deployment unit, you can review individual changes and decide what should happen next.

You can also selectively exclude actions from the comparison results when a particular change should not be deployed.

Schema Compare with Fabric Warehouse

Schema Compare's integration with Fabric Warehouse allows developers to identify differences in database objects before implementing changes.

Database Projects and Git

The database project becomes the artifact under review in the PR, not a raw DDL diff — schema changes get the same scrutiny as application code, and the deployment pipeline consumes a validated project state rather than an ad-hoc script.

Schema Compare exposes Fabric Warehouse DDL limitations before deployment, helping you proactively address issues and maintain greater control over the deployment process.

Power BI Smart Table Visual: Excel style Column Filtering, Dynamic Column Headers, Grouping Columns

tharunkumarRTK — Mon, 14 Sep 2026 13:55:10 GMT

For a smoother reading experience with clearer screenshots and easy code copying, I suggest [reading this article on my website](https://www.techietips.co.in/articles/powerbi-managed-6500measures-smartly). It’s free, ad-free, distraction-free, and dedicated solely to sharing knowledge.

The Table is the most commonly used visual in Power BI. Anyone who has spent years in Excel expects to click a header and filter that column. They expect related columns to sit under a common heading. The native table visual does none of this.

There are grid visuals in the Microsoft visual app source that do. Most developers never get to use them, for two reasons that have nothing to do with the features. The good ones are licensed per developers or user, and that cost has to be justified to someone. The free ones are usually not Microsoft certified, which means an uncertified third party script is running inside your report, and that is a fair thing for a security team to say no to.

So I built one. It is called Smart Table, and I built it with Claude. This post walks through what it does.

1. Excel style column filtering

Every column header carries a funnel button in its own divided cell. Click it and you get what you would expect from Excel: sort, a set of conditions appropriate to the column’s type, and a searchable checkbox list of that column’s values. The menu names the column it belongs to, counts what you have ticked, and stays open while you sort.

The conditions follow the column type rather than offering one generic list:

Sync: does the filter stay in the grid or reach the report

Sync is on by default. Filters applied in the header are pushed to the model, so every other visual on the page responds, exactly as if the user had used a slicer. Turn Sync off: Filtering then narrows this grid only.

Global search

The toolbar has a search box with its own operator dropdown: contains, is exactly, starts with, ends with, does not contain. It searches across every column at once.

Power BI: Smart Table Excel Style Column Filtering

2. Dynamic column headers, driven by a measure

A column header name is normally a static label. Here it can be a DAX measure.

Arrival Month is set to April, and the Key Metrics headers read Lead Time (Avg: 30.00), Room Nights (Avg: 1.00), ADR (Avg: 160.50). Change the month and they recompute.

The header honors the filter context, including the filters applied inside the grid itself. Filter Property down to Resort Hotel with the funnel and the averages in the header follow.

Power BI Smart Table: Measure Driven Column Headers (Dynamic Column names) - YouTube

3. Column groups, without any extra tables

Four groups across eleven columns: Reservation, Channel, Room Type, Key Metrics. Each one is a spanning header above its columns with its own colour.

The thing to notice is what is not involved. No disconnected table. No field parameters. No two table visuals stacked on top of each other. No shapes placed in the background: which means your column groups move to the right along with your cursor.

Power BI Smart Table: Grouping columns in a table without using a static table and a matrix visual - YouTube

Known limits

All of these come down to one idea: some filtering reaches the model and some is local to the grid.

30,000 rows That is the Power BI cap for a table mapping with this data reduction algorithm. Header filters push a real model filter, so filtering down to a workable set works fine. Do not point it at an unfiltered fact table.
Value lists cap at 2,000 distinct values per column**, built from the loaded rows. On a high cardinality column like a guest name, use the search box in the menu.
Ends with, Does not end with, and blank selections filter the grid only.** Power BI’s advanced filter operators have `StartsWith` and `Contains` but no `EndsWith`, and a blank has no equivalent in a model side `In` list. The menu tells you when you pick one of these.
Bookmarks restore the data but not the ticked checkboxes.** The model filter is persisted by Power BI, so the rows come back correctly. The header checkboxes just will not show as ticked.

I wrote this to make one point: the gaps in the built-in visuals are not permanent. Build your own, and with vibe coding that is no longer a months-long project.

I am not sharing the .pbiviz file. It is an experiment, not tested for production grade reports. Feel free to checkout my [website](https://www.techietips.co.in) and reach out to me if you are interested to do these experiments along with me,

I would like to continue developing this visual and will write detailed blogs in features explaining its features and implementations.

I hope you learned something new. Feel free to share your thoughts in the comments section.

Happy Learning!!!

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 — Mon, 14 Sep 2026 16:59:09 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.