Connect coding agents to Fabric notebooks with FNTK (Preview)
The Fabric Notebook Toolkit (Preview) helps developers shorten the feedback loop between writing code and validating it with live notebook results. It connects coding agents to Microsoft Fabric notebooks through a command-line interface (CLI) that runs in the terminal alongside tools such as Claude Code, GitHub Copilot CLI, and Codex. An agent can inspect the current code, run one cell, review its output, make a targeted change, and run it again without resubmitting the entire notebook—much as a human programmer working interactively. A coding agent uses FNTK from the terminal to interact with a Microsoft Fabric notebook. From code suggestions to notebook execution A coding agent can help write a transformation, but a proposed change is not the same as a working result. When execution happens elsewhere, developers must move code into a notebook, run it, and bring the results or errors back to the agent. FNTK connects those steps so the agent can work with a running Fabric notebook and its execution results instead of relying only on code shared in the conversation. Interactive development and debugging are the central use cases. You can ask an agent to inspect a notebook, investigate a failing transformation, or validate a change using actual execution output. The notebook remains in Fabric and uses Fabric capacity for distributed data processing, while FNTK provides the terminal commands the agent uses to interact with the live session. Run, inspect, and refine one cell at a time FNTK keeps the notebook session active while the agent works, so developers can explore and refine code without repeatedly restarting the workflow. For example, an agent can inspect a schema, adjust a conversion, check several records, and return to the same transformation as new information emerges. This mirrors the iterative way developers work in notebooks and keeps each change grounded in actual execution results. The toolkit brings the operations needed for that workflow into the terminal. An agent can discover the target notebook, read and update its cells, execute code, and retrieve results. Instead of treating every adjustment as a new whole-notebook submission, it can focus on the code being investigated. Find workspaces, notebooks, and lakehouses to establish the context for the task. Read, add, or update notebook cells as the work develops. Execute a cell's code and inspect its output before deciding what to change. Reuse the live session to refine and rerun the relevant code. For example, a transformation may fail because an input column has a different type than expected. An agent can inspect the schema, revise the affected code, and rerun it in the existing session to check the result. This avoids restarting the entire notebook merely to test that change and keeps the investigation focused on the failing operation. Give the agent the evidence to debug FNTK gives the agent the execution evidence needed to determine the source of a failure. It exposes cell output and Spark job state, along with driver logs, executor logs, and logs from Livy, the service that manages Spark sessions. With this context, the agent can investigate the likely source of a problem instead of relying on source code alone. The CLI can return structured JavaScript Object Notation (JSON) responses that identify results, errors, and suggested next actions. An agent can use this information to determine whether execution has finished, retrieve diagnostics, and choose what to investigate next. This shortens the feedback loop between writing code and understanding its behavior while reducing the need to copy outputs and logs manually between tools. FNTK in practice at Microsoft For our data engineering team at Microsoft, FNTK filled a gap between generating code and working with real data. Previously, we used an AI assistant to draft code locally, then copied it into Fabric notebooks to run it and brought the results back into the conversation. With FNTK, we can stay in GitHub Copilot, execute code in Fabric, and use the results to iterate. We started by installing the toolkit, connecting with the appropriate permissions, and asking questions about a data source. Exploratory work quickly became a valuable use case. We could ask for row counts, distributions, or samples, then follow up based on the actual results. From there, we built shared workflow skills and a developer plugin around FNTK, incorporated our engineering standards, and connected the plugin to Azure DevOps through the Model Context Protocol (MCP) to bring user-story context into the same workflow. In practice, this has sped up development and helped us work across multiple user stories, with more of our time spent reviewing changes rather than writing every line ourselves. Copilot handles the reasoning; FNTK provides the connection to live notebook execution. We can still inspect the runs in Fabric, and our existing source-control, quality, and human-review practices remain in place. In practice, this workflow has helped us work across multiple user stories and spend more time reviewing changes instead of writing every line ourselves. Copilot handles the reasoning; FNTK provides the connection to live notebook execution. We can still inspect the runs in Fabric, and our existing source-control, quality, and human-review practices remain in place. Figure: FNTK connects an AI developer agent to live Fabric notebook execution, alongside MCP tools for context and delivery tools for human-reviewed changes. Capabilities with FNTK commands Command or group Usage fntk help Show command guidance and examples. fntk init Install or update coding agent workflow skills. fntk discover Find workspaces, notebooks, lakehouses, and identity information. fntk notebook Manage notebooks, sessions, and default lakehouses. fntk cell Read, edit, and organize notebook cells. fntk code Execute code, retrieve results, and cancel runs. fntk monitor Inspect Spark progress, diagnostics, and resource usage. fntk logs Download driver, executor, Livy, and cell logs. fntk resource Manage notebook resource files and folders. fntk skill Read built-in coding and debugging guidance. fntk server Manage the local FNTK server. Get started To try the workflow, install the toolkit and connect your coding agent by following the FNTK installation and quick-start documentation, including fntk init for workflow skill setup. Then choose an existing development notebook and a focused task, such as inspecting one transformation. Run the code, review the output, and use the result to guide your next change.
Retiring the Fabric data agent custom tool in Microsoft Foundry: move to Fabric IQ
In March 2025, we announced that agents in Microsoft Foundry could use Fabric data agents to answer questions about data in Microsoft Fabric. In the earlier integration, you connected to a data agent by adding it as a custom tool. For details, refer to Consume a data agent in Microsoft Foundry. What’s changing We are deprecating the earlier custom-connection integration. Starting 11/6/2026, that integration will no longer be supported. If your Foundry agents use a Fabric data agent as a custom tool, you must migrate them before that date. The replacement integration (Preview) uses the Fabric IQ (OneLake Catalog) tool, which makes your data available to agents and applications. In the Foundry portal, you can use this tool to add a published Fabric data agent to a Foundry agent. For configuration steps, refer to Consume Fabric data agent from Microsoft Foundry via Fabric IQ. Capabilities with the new integration The replacement integration changes how you find and connect Fabric data agents: Select accessible published data agents from the catalog. In the Foundry portal, the OneLake Catalog shows the published data agents available to you by name, so the connection workflow does not require you to enter a workspace ID or an artifact ID. Connect more than one data agent. A Foundry agent can call multiple data agents, such as separate agents for sales data and customer support data. The earlier custom-connection integration only supported one Fabric data agent. Connect through a Model Context Protocol (MCP) endpoint. MCP is an open standard for how an agent calls a tool. Each selected Fabric data agent is presented to the Foundry agent as a tool through a MCP endpoint. Coming soon, when a data agent answers a question, its response will also include the query it used to generate the answer. What you need to do If any of your Foundry agents use a Fabric data agent as a custom tool, complete the following steps before 11/6/2026: In Microsoft Fabric, make sure to publish your Fabric data agent with a rich and detailed description. Open the agent in the Microsoft Foundry portal. In the Tools section, add the Fabric IQ (OneLake Catalog) tool, and then select your data agent from the catalog. Update the Foundry agent's instructions. Name each data agent and describe the types of questions it should handle. Remove the earlier custom tool and then save the Foundry agent. Test the Foundry agent with representative questions for each connected data agent. If you connect data agents in code, update your implementation to use the Fabric IQ tool. For samples in Python, C#, and JavaScript, refer to Connect agents to Microsoft Fabric with Fabric IQ. Guides to migrate from Fabric Data Agent to Fabric IQ tool Option 1: Migrate in Foundry Portal Navigate to Foundry Portal and open the Tools Catalog, select “Fabric IQ (OneLake Catalog)”. . In the OneLake catalog, filter by “Data agent” type. Select any data agent you want to use, and you are ready to go. Provide instructions to your Foundry agent about how to use Fabric data agent. . Option 2: Migrate in SDK/Rest API After you publish the Fabric data agent, open its Settings and go to the Model Context Protocol tab. This tab shows: Data agent MCP server name MCP server URL (copy this value; you can use in every client) Data agent MCP tool name MCP server tool description Once you get the data agent MCP server URL, proceed with the following steps: Step 1: Get an access token az account get-access-token --resource https://management.azure.com --query accessToken -o tsv Step 2: Create a Foundry connection to the Fabric data agent A connection stores the Fabric data agent endpoint and how to sign in to it. Your agent uses this connection to reach Fabric. Replace each value in angle brackets, then run the request: curl --request PUT \ --url 'https://management.azure.com/subscriptions/<azure-subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account-name>/projects/<foundry-project-name>/connections/<connection-name>?api-version=2025-04-01-preview' \ --header 'Authorization: Bearer <access-token-from-step-1>' \ --header 'Content-Type: application/json' \ --data '{ "type": "Microsoft.MachineLearningServices/workspaces/connections", "properties": { "authType": "UserEntraToken", "group": "AzureAI", "category": "RemoteTool", "target": "<fabric-data-agent-mcp-endpoint>", "audience": "https://api.fabric.microsoft.com/.default", "isSharedToAll": true, "sharedUserList": [], "UseCustomConnector": false, "Credentials": { "ClientId": "fake" }, "metadata": { "ApiType": "Azure" } } }' Main field capabilities: Field Value What it means authType UserEntraToken The agent calls Fabric as the signed in user, with that user's Microsoft Entra token. category RemoteTool The connection points to a remote tool, in this case an MCP endpoint. target Your MCP endpoint The address of your Fabric data agent. audience https://api.fabric.microsoft.com/.default The token is issued for the Fabric API. isSharedToAll true Every user in the Foundry project can use the connection. Credentials.ClientId fake Keep this value as shown. The response includes an id field. This is the full resource ID of the connection. Save it for step 4. It looks like this: /subscriptions/<azure-subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account-name>/projects/<foundry-project-name>/connections/<connection-name> Step 3: Install the Python packages pip install "azure-ai-projects>=2.2.0" azure-identity Step 4: Set the environment variables Variable Where to find it FOUNDRY_PROJECT_ENDPOINT The Overview page of your Foundry project. FOUNDRY_MODEL_NAME The deployment name of your model in your Foundry project. FABRIC_IQ_PROJECT_CONNECTION_ID The full connection resource ID from step 2. Use the full ID, not only the connection name. export FOUNDRY_PROJECT_ENDPOINT="<your-project-endpoint>" export FOUNDRY_MODEL_NAME="<your-model-deployment-name>" export FABRIC_IQ_PROJECT_CONNECTION_ID="<your-connection-resource-id>" Step 5: Create an agent that uses the Fabric IQ tool and ask it a question This script creates a prompt agent with the Fabric IQ tool, sends it one question, prints the answer, and then deletes the agent. import os from azure.identity import DefaultAzureCredential from azure.ai.projects import AIProjectClient from azure.ai.projects.models import PromptAgentDefinition, FabricIQPreviewTool endpoint = os.environ["FOUNDRY_PROJECT_ENDPOINT"] with ( # Signs in with your Azure command line interface account (from az login). DefaultAzureCredential() as credential, AIProjectClient(endpoint=endpoint, credential=credential) as project_client, project_client.get_openai_client() as openai_client, ): # 1. Define the Fabric IQ tool. It uses the connection you created in step 2. fabric_iq_tool = FabricIQPreviewTool( project_connection_id=os.environ["FABRIC_IQ_PROJECT_CONNECTION_ID"], require_approval="never", # The agent calls the tool without asking you first. ) # 2. Create the agent with your model, its instructions, and the Fabric IQ tool. agent = project_client.agents.create_version( agent_name="MyAgent", definition=PromptAgentDefinition( model=os.environ["FOUNDRY_MODEL_NAME"], instructions="Use the available Fabric IQ tools to answer questions and perform tasks.", tools=[fabric_iq_tool], ), ) print(f"Agent created (id: {agent.id}, name: {agent.name}, version: {agent.version})") # 3. Ask the agent a question. Change this to a question about your own data. user_input = "Which customers placed orders above $10,000 last quarter?" response = openai_client.responses.create( input=user_input, extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}}, ) print(f"Agent response: {response.output_text}") # 4. Delete this agent version so unused versions don't build up in your project. project_client.agents.delete_version(agent_name=agent.name, agent_version=agent.version) print("Agent deleted") Finally, run the script. python fabric_iq_agent.py Learn more and share feedback We recommend that you move to Fabric IQ as soon as you can. We look forward to improving this integration, and we’d like to hear your feedback. Join the community discussion to share feedback and report issues. For more information, see these articles: Consume Fabric data agent from Microsoft Foundry via Fabric IQ Connect agents to Microsoft Fabric with Fabric IQ
Advanced NL2SQL and advanced DAX generation in Fabric data agents (Generally Available)
Data agents in Microsoft Fabric let users ask questions about data in plain language. As a creator, you connect an agent to supported sources—including SQL databases, lakehouses, Power BI semantic models, and eventhouses—add the business context it needs, and share it with users across Fabric, Teams, Microsoft 365 Copilot, Copilot Studio, and Microsoft Foundry. The data agent can then respond like a domain expert that understands what your tables mean, how your metrics are defined, and which source can answer a question. The usefulness of a data agent ultimately depends on a simple question: can it translate what a user asks into the right query? That is harder than it sounds. Enterprise schemas are rarely intuitive. Several tables, columns, measures, or join paths may appear to answer the same question, so a query can be technically valid but still return the wrong result. Advanced NL2SQL and advanced DAX generation help address this problem by allowing the agent to explore the schema and data, validate assumptions, and refine its approach before generating a query. Both capabilities are available today, and we'll begin rolling the core improvements out to the standard runtime on November 2, with the rollout expected to complete by November 10. In this post, we'll look at how they work, what our internal benchmarks show, the new configurations available for shaping how the agent behaves, and what to consider as you re-test and evaluate your data agents. Why conversational analytics gets harder with enterprise data Turning a plain-language question into a correct query is a complicated problem, both for SQL and DAX, requiring the agent to resolve several challenges at once: Schemas are large. Enterprise sources can contain hundreds of tables, columns, and measures, and the names alone may not explain when or how they should be used. Business context exists outside the data. Definitions such as “revenue” or “active customer” often live in documentation, previous queries, or analysts’ knowledge rather than in the source schema. Filter values must match the way data is stored. Users describe concepts naturally, but those concepts must map to the values in the data. For example, a user may ask about “California” when the relevant column stores the value “CA.” Questions are ambiguous. More than one column, calculation, or join may appear to satisfy a request. Individually, each of these can be managed with enough hand-written guidance. The difficulty is that they compound: a single-pass generator has to resolve all of them at once — your schema, your definitions, your filter values — committing to an interpretation before it has any evidence that interpretation is right. When it guesses wrong, the query still runs, and the answer looks no different from a correct one. Advanced NL2SQL and advanced DAX generation are built around that problem. Rather than generating a single pass, the agent gathers evidence first. Advanced NL2SQL: the agent explores before it writes The shift is architectural. Instead of one-shot generation, the agent has sub-tools to explore schema, test joins, and look up real filter values before it writes SQL. Under the hood, you can inspect each step the agent took, and the assumptions and reasoning behind it. It operates in three modes, each backed by its own sub-tools: Mode What it does Example query following Finds a relevant example query and answers by making approved modifications, such as literal filter or parameter substitutions. Clarifying questions Determines it can’t answer reliably without more information and asks targeted clarifying questions before generating SQL. Data exploration When no example directly applies, learns from existing example queries to infer business logic, explores the data to validate assumptions, and iteratively refines its approach. What you get as a creator: Advanced NL2SQL explores the SQL source schema, tests joins, and looks up real filter values before generating SQL, helping it choose the appropriate tables, columns, relationships, and filters. Schema descriptions and topics that teach the agent what your data means, so you get better answers with fewer instructions. Better example-following and filter-value substitution for novel questions. Handles large schemas far better and runs faster end to end, with more reasoning detail for debugging. New configurations: schema descriptions and topics Two new configurations give the agent more of the context it needs. Both are available for SQL data sources on the preview runtime. Schema descriptions Schema descriptions attach business context to the objects in your data source — what a table holds, what a column represents, and how each should be used. The agent uses them to interpret large or ambiguous schemas and generate a more accurate query. They matter most where object names don’t carry meaning on their own, or where several tables and columns look interchangeable. Figure: Schema descriptions add business context to schema objects, helping the data agent interpret your data. Topics Topics help you give the agent detailed guidance without sending every instruction with every question. The agent searches your topic content and uses only the sections relevant to the current request. Use data source instructions for rules that must always apply, and use topics for deeper guidance that applies only to a specific subject. You can write topics in Markdown, import multiple files, and review the run steps to see which topics the agent selected. Figure: Topics organize subject-specific instructions in Markdown to guide the data agent’s query generation. Internal benchmark testing: Advanced NL2SQL on Preview Runtime vs NL2SQL on Standard Runtime Better reasoning matters only if it produces better answers without making users wait substantially longer. In an internal benchmark set evaluating answer quality and end-to-end latency, the preview runtime delivered the stronger outcome, answering more questions correctly than the standard runtime while reducing both median and tail latency. Smart-answer accuracy increased from 78.8% to 90.9%. Latency improved at the same time: P50: 28.4 seconds to 26.0 seconds P95: 46.8 seconds to 32.9 seconds Figure: Smart answer accuracy and end-to-end latency, standard runtime versus the Advanced NL2SQL preview, on an internal benchmark set. Accuracy rises 12.1 points to 90.9%, while P50 latency falls 8.3% and P95 falls 29.8%. *Performance results are based on Microsoft internal testing conducted in 2026 using an internal evaluation set comparing standard NL2SQL to the advanced NL2SQL preview in Microsoft Fabric. Actual results may vary depending on workload, data model, and configuration. The P95 result shows the largest latency improvement in this benchmark, with latency decreasing from 46.8 seconds to 32.9 seconds. This improvement is most relevant to the slower, more complex queries represented at the tail of the distribution. Advanced DAX generation: agentic reasoning over semantic models The agent calls tools, inspects results, and refines its approach to answer harder questions. Instance value indexing searches real column values, so filters match your data. And you get consistent results across Data Agent, Power BI, and M365 Copilot. For users, this means the agent is more likely to resolve filter terms to the values stored in the semantic model and return consistent answers across supported Microsoft experiences. Internal benchmark testing: Advanced DAX generation improves accuracy while cutting latency Our internal Advanced NL2DAX evaluation showed improvements in both answer accuracy and latency. Smart-answer accuracy increased from 89.15% to 91.86%. At the same time: P50 latency: 39.1 seconds to 20.4 seconds P95 latency: 97.5 seconds to 34.7 seconds This represents an approximately 48% reduction in P50 latency and a 64% reduction in P95 latency, along with a 2.7 percentage-point increase in smart-answer accuracy. *Performance results are based on Microsoft internal testing conducted in 2026 using an internal DAX generation evaluation set comparing the baseline to the advanced DAX generation preview in Microsoft Fabric. Actual results may vary depending on workload, semantic model, and configuration. Rolling out the runtime improvements We'll begin rolling the core Advanced NL2SQL and advanced DAX generation improvements out to the standard runtime on November 2, with the rollout expected to complete by November 10. As part of this rollout, the standard runtime will also move to GPT-5.6 Terra. As the rollout reaches your environment, data agents using the standard runtime will receive these improvements and the model upgrade by default, with no opt-in required. What is moving to the standard runtime: Advanced NL2SQL: improved example-query following, filter-value substitution, and data exploration. Advanced DAX generation: the agentic tool-calling loop and instance value indexing. Model upgrade: The standard runtime will move to GPT-5.6 Terra for orchestration and supported data agent capabilities. What stays in preview: Schema descriptions and topics for SQL sources. We believe these changes deliver significantly better results, based on improvements observed in our internal evaluations. However, results can vary by data source, model, instructions, examples, and workload. Creators can re-test and evaluate their agents on the standard runtime between November 2 and November 10 as the rollout reaches their environment, or try the changes now on the preview runtime. Moving from one-shot generation to an agent that explores data can change how existing instructions and examples are interpreted. We recommend re-testing: Run your existing question set against the standard runtime as the rollout reaches your environment between November 2 and November 10, or switch to the preview runtime to try the changes now. Rerun your evaluations with the Fabric data agent SDK and a ground-truth set. Compare the new results with your previous baseline, and use the visible reasoning steps to identify where the agent’s assumptions differ. Tune your example queries and instructions based on what the evaluation shows. The agent now explores your data and adapts examples through substitution, so guidance written to work around the previous behavior may no longer be needed. Re-testing and evaluating your agents will help you confirm the expected quality improvements for your own data and scenarios. Next steps If you build data agents in Microsoft Fabric, re-test your agents on the standard runtime as the rollout reaches your environment between November 2 and November 10, or try the changes now on the preview runtime. For more details: Fabric data agent runtime: Learn what the standard and preview runtimes each contain, how to switch between them, and what’s in the preview runtime today. SQL sources in Fabric data agent: Learn how NL2SQL and Advanced NL2SQL generate queries over Lakehouse, Data Warehouse, SQL Database and Mirrored Database sources, and which configurations each one can use. Semantic model best practices for data agent: Semantic model best practices for data agent: Learn about advanced DAX generation and how to prepare a semantic model so the agent can answer questions accurately.Introducing Rayfin: A new AI-first way to build, deploy, and govern application backends
The way organizations are building apps is changing. AI and coding agents have made it easier than ever to turn an idea into an app. But keeping those applications secure, compliant, and governed has only gotten harder.
Unlocking LLM-Powered through Data Agent from your Mirrored Databases in Microsoft Fabric
Fabric Data Agent now support mirrored databases--making it easier than ever to put your operational data to work with AI. As organizations depend on an ever-growing mix of data sources, the ability to seamlessly integrate and analyze data—no matter where it resides—is critical. This is where mirroring in Fabric comes in. With open mirroring, you can bring data from Independent Software Vendors (ISVs) directly into Fabric’s Delta Parquet format, ensuring it stays automatically in sync with the source. Now, with mirrored database artifacts connected directly to data agents in Fabric, you can unlock the power of Large Language Models (LLMs) to query, reason over, and generate insights from your operational data--accelerating time-to-insight across your entire data estate. What Are Mirrored Database Artifacts? Mirrored database artifacts are representations of your external databases—such as Azure Cosmos DB, Azure SQL Database, Oracle, Snowflake, Databricks—mirrored into Microsoft Fabric. This enables you to leverage Fabric’s AI-driven analytics and LLM capabilities over data that previously lived outside the Fabric ecosystem. Supported Mirrored Artifacts in Data Agent include: Mirrored Azure Cosmos DB Mirrored Azure Database for PostgreSQL Mirrored Azure Databricks catalog Mirrored Azure SQL Database Mirrored Azure SQL Managed Instance Mirrored Oracle Mirrored Snowflake Mirrored SQL Server Database With the latest release, users can add mirrored artifacts directly to Fabric Data Agent. Users no longer need to create an intermediary Lakehouse to bridge this gap. Once connected, the data agent leverages its NL2SQL (Natural Language to SQL) capability to generate and execute SQL queries against the SQL Analytics Endpoint built into the mirrored artifact. This means users can ask natural language questions and get instant, actionable insights—powered by LLMs—across all your mirrored data sources. Figure 1: The user has a data agent loaded with a mirrored databricks catalog and a mirrored oracle database. The user hits on add datasource and filters by mirrored items in Fabric. The user then selects a mirrored cosmos db and adds it to the data agent. Key Features and Benefits By connecting mirrored artifacts directly--without extra steps--you can unlock instant insights, streamline workflows, and power smarter applications across your data estate. Direct Integration: Add mirrored artifacts as data sources in Fabric data agents without the need for intermediate Lakehouses or shortcuts. AI-Driven Analytics: Use data agent’s built-in NL2SQL to query your data in plain English and receive insights instantly. Broad Compatibility: Integrate data from Azure, Oracle, Snowflake, Databricks, and more. Customizable Knowledge: Curate the data agent with instructions, data source instructions, and few-shot queries for all mirrored data sources. Scoped Context: Select relevant tables to focus the data agent’s knowledge and responses. Seamless AI Application: Bridge the gap between your external data and AI applications in Microsoft Fabric. Getting Started Mirror Your Database: Use mirroring for Azure databases, or open mirroring to bring external databases into Microsoft Fabric as a mirrored artifact. Add to Data Agent: In the data agent interface, add the mirrored artifact as a data source. Curate and Query: Customize your data agent with instructions and examples, then start asking questions in natural language to generate LLM-powered insights. What’s Next? Microsoft Fabric is continuing to expand support for additional data sources. Coming soon, you’ll be able to connect SQL Database artifacts. To learn more about data agent, check out the Fabric data agent concepts (preview) documentation. For more details on how to mirror your databases into Fabric, review the Open Mirroring documentation. Summary By connecting mirrored database artifacts directly to Fabric Data Agent, you can unlock the full power of LLM-driven analytics across all your data—no matter where it lives. This new capability makes it easier than ever to bridge the gap between your data and AI, empowering you to make smarter, faster decisions.FabCon/SQLCon Barcelona 2026: What’s new in Fabric Data Factory
If you haven't already, check out FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents for a complete look at all of our FabCon Europe announcements across Fabric and Microsoft Databases. Almost every conversation I have with customers comes back to the same issue: data fragmentation remains the single biggest challenge to harnessing AI. Harmonizing data across the systems and applications where it resides, and making that data available to the people, applications, and agents that need it, is the work — and most teams are still doing a surprising amount of it by hand. At the European Microsoft Fabric and SQL Community Conference, we are showcasing what’s possible when a data platform is built to address fragmentation across silos while respecting the diversity and heterogeneity of enterprise data estates. We’re introducing more than 45 new capabilities, including additional sources for unifying and distributing data, stronger replication governance, new data destinations, more resilient pipelines, richer monitoring, and AI assistance across the end-to-end experience. The following capabilities, announced at FabCon Barcelona, can help teams operate their multicloud data estates day in and day out. A foundation for the AI-powered enterprise AI is redefining how every organization operates. But AI is only as powerful as the data that grounds it. That is why data integration has never been more important. At Microsoft, we are building the foundation for the AI-powered enterprise with Microsoft Fabric and Data Factory, unifying data across operational systems, clouds, applications, and analytics platforms into a single, trusted, governed data estate. From zero-ETL data unification and real-time intelligence to metadata-driven integration and agentic experiences, we are enabling organizations to turn fragmented data into enterprise intelligence that powers business decisions, workflows, and AI agents. Our ambition is not simply to modernize data integration, but to transform it from a process of moving data into the intelligence layer that powers AI agents, applications, and people with trusted business context. Unifying the data estate: Zero ETL, and now zero excuses Data silos create friction that makes it harder to realize value from data. Data must be copied or extracted, the pipelines that move it must be managed and monitored, and data distributed across systems must be governed. Mirroring helps eliminate this friction by continuously bringing data into OneLake without placing a load on source systems or requiring pipelines to maintain. It has become a fast way for customers to obtain a governed, current view of their operational data. Today, we are extending Mirroring in the two directions customers requested: adding more sources and increasing each source by going beyond data replication. Mirroring for Google BigQuery and Mirroring for SharePoint Lists are both generally available, opening two of the most requested paths into OneLake — one at analytical scale, the other for the lists business teams keeps their working data in. Coming soon, Mirroring for Dynamics 365 Business Central will let customers bring data from selected tables and companies directly into OneLake, unlocking richer reporting and analytics across Microsoft Fabric. Extended Capabilities in Mirroring are now generally available, including Change Data Feeds. We’re also announcing an addition to the extended capabilities in Mirroring for Snowflake: replication of security policies. Governance has traditionally been a challenge for replication. The data may be copied cleanly, but its permissions are not requiring customers to rebuild security policies manually in the destination. Replicating Snowflake security roles in OneLake carries that governance context with the data. Open Mirroring continues to grow through our partner ecosystem, with additional partner investments landing this release. This is an important dimension of our Mirroring roadmap and the only way in which we can cover the breadth of sources that matter to every organization. We are always grateful to our partners for joining us in building a complete and comprehensive Mirroring roadmap. Learn more about extended capabilities in the Mirroring documentation. Multicloud, petabyte-scale data distribution Getting data in is only half of the story. Increasingly, our customers need to distribute data to another cloud, a partner, or their own customers' environments. Bespoke approaches to data distribution are costly and can impose a large integration tax. With Data Factory, our vision is to support data movement across clouds and diverse data platforms. We have a breadth of capabilities in our portfolio to drive data movement from batch to streaming scenarios and multicloud sources and destinations. Copy job in Data Factory is purpose-built for data distribution, with capabilities such as Change Data Capture, Slowly Changing Dimension Type 2, and audit capabilities that preserve history and lineage in the destination instead of requiring them to be reconstructed later. An exciting addition to the Copy Job is the integration of batch-to-stream and stream-to-batch capability, minimizing the gap between these two modalities in data integration. Copy job can now write changes directly to eventstreams, bringing the wealth of batch data sources to enable greater flexibility. Copy job execution can now also be triggered through Fabric Activator, which means that Copy jobs can be triggered in more ways than through a wall-clock schedule. Both of these improvements enable customers to build richer and more elegant architectures for how data integration is done. We are also expanding Copy job’s multicloud data distribution capabilities, giving customers more flexibility in where data lands and greater control over how delivery is managed. This includes SharePoint folders as a destination and support for loading multiple source folders into separate destination tables within a single job. To make distribution easier to operate, audit columns add traceability to data delivered to Snowflake, while workspace monitoring brings job health and throughput into a centralized view so teams can spot failed or slow-running jobs without opening each one. Custom staging database and schema support give customers control over where CDC and SCD Type 2 staging objects are created, helping data delivery fit their existing security and operational practices. Transformation in the tools people already use Transformation is the most widely used integration workload in the Microsoft Fabric ecosystem because it serves people across the full spectrum of data work. A citizen developer shaping data in Power Query, a data engineer using Notebooks to clean, join, and enrich data with custom code, and a code-first team managing a dbt project are solving the same fundamental problem through very different tools and experiences. Our goal is to serve each of them in the way they work best on a shared foundation that does not compromise scale, performance, or governance. At FabCon, we are advancing that vision across Power Query, Dataflow Gen2, notebooks, and dbt — making transformation faster to run, easier to reuse and operate, and more consistent across Power BI and Fabric. In Dataflow Gen2, we are improving performance and scale with optimized Lakehouse writes, V-Order compression controls that help teams balance write cost with downstream query performance, and a modern evaluator expanding across connectors for more consistent execution. We are also introducing Shared Queries so teams can define preparation logic once and reuse it across dataflows, reducing duplication and keeping business rules consistent. We are broadening where Dataflow Gen2 can deliver prepared data by adding destinations across Fabric, Snowflake, and SharePoint. Other multicloud destinations, including Amazon S3 and Google BigQuery, are coming soon. The additions I find particularly compelling are Excel and email destinations: they put trusted data directly into the business tools and workflows where decisions happen, reducing the manual exports and handoffs that still sit at the end of too many data processes. We are also making Dataflow operations easier to manage. Downloadable diagnostics and Dataflow Gen2 run details in Monitoring Hub give teams the execution context they need to move from a failed refresh to an actionable cause faster. One of the innovations I am most excited about is bringing years of Power Query Online advancements to Power BI Desktop. This creates a more consistent Power Query experience across products and gives authors a more natural path from self-service preparation in Power BI to governed, scalable transformation in Dataflow Gen2. For our existing Power BI customers, we are also enhancing the Dataflow Gen1-to-Gen2 Migration Wizard to provide a guided, lower-risk path to modernization. At FabCon, we are adding API support to automate migration across larger estates, a downloadable upgrade report to capture readiness and follow-up actions, and new validation rules to surface compatibility issues earlier. Together, these enhancements help administrators plan and track the move to Fabric with greater confidence. For code-first teams, we are making dbt Job in Fabric generally available with broader enterprise support while preserving the familiar dbt workflow. We are landing dbt-generated logs in OneLake so run history, model execution time, and test failures can be analyzed; extending where teams can build models through Lakehouse and additional Fabric adapters; and carrying environment configuration through deployment pipelines with variable library support. Support for dbt Core v2, previously known as Fusion, is coming soon. Orchestrating data with ease: From low code to pro-code Scale, reliability, and flexibility are essential to any credible data integration platform. Pipelines in Fabric Data Factory power more than 25 billion orchestration runs each month. Built on Azure Data Factory’s proven platform, pipelines provide a widely used orchestration foundation for enterprise data integration. At FabCon Europe in Barcelona, we’re delivering the next wave of orchestration capabilities in Fabric Data Factory: more resilient pipelines, richer monitoring, agentic experiences that reason over pipeline runs, new Actions activities that enable pipelines to integrate directly with Fabric platform APIs, and business activities. The Lakehouse Maintenance activity enables you to run vacuum and optimize directly from your pipelines, so maintenance happens on the same cadence as the data that needs it — faster queries and lower storage overhead, with no separate job to own. Pipeline activities also support exponential retry, where retry delays increase over time, so transient throttling resolves itself instead of turning into a failed run and a morning of manual re-runs. Outlook activity now supports service principal and workspace identity, so notifications run on a workspace identity or service principal rather than a personal account — email workflows remain operational when personnel change and can be deployed cleanly across environments. Pipeline-level dependencies let you define relationships between pipelines, enabling dependent pipelines to run only after upstream pipelines succeed. Monitoring itself gets richer: runtime events, performance metrics, and intelligent error classifications now sit together in Monitoring Hub, so an engineer goes from alert to cause without leaving the monitoring surface. Agentic investigation uses AI-powered analysis to help identify whether an issue may be related to code, data, or capacity. New activities extend what a pipeline can do. We’re introducing activities that let you invoke Fabric platform APIs natively from pipelines and incorporate business activities into pipeline workflows. Agentic approvals with the Approval activity put human-in-the-loop decisions inside the pipeline, with an agent that evaluates signals and surfaces a risk score based on the environment, data classification, volume, and requestor, and leaves a full audit trail on every decision. AI-assisted data integration AI in data tools has traditionally taken the form of a chat window used primarily for authoring and starting conversations. What we’re delivering now is different: AI-assisted and AI-driven experiences integrated across the data integration lifecycle, from authoring and operationalizing to monitoring, troubleshooting, repairing, and automating workflows. Fabric Model Context Protocol (MCP) and Fabric Skills provide the foundation for this end-to-end continuum. The MCP gives agents a standardized way to reach tools and resources, which means a developer can work with an agent to create a dataflow, write and update queries, trigger a refresh, start a pipeline run, and check its status — without a bespoke integration for each one. Agent-driven automation scenarios build on this foundation, and the Data Factory MCP and related skills are publicly available for developers. Unified Copilot and Fabric Skills investments give the assistants integrated across different surfaces of Fabric a common understanding of the estate and shared context. AI-powered operations and observability-focused agents turn a wall of run history into an actionable answer about what broke. Taken together, they shorten the two tasks that consume most of a data engineer's week: writing the logic and finding out why it stopped working. Upgrading the integration estate you already have Azure Data Factory has earned the trust of customers worldwide by powering mission-critical data integration workloads over the last 10 years. Organizations that rely on Azure Data Factory and Azure Synapse pipelines have built critical data integration foundations that form the backbone of their business operations. Fabric Data Factory builds a trusted foundation while bringing customers into a unified analytics platform designed for the AI era. With OneLake, Copilot-powered experiences, integrated analytics, and Fabric-native innovation, customers can modernize their data integration estate while preserving the investments that matter most. At Fabric Conference Barcelona, we are excited to announce a streamlined upgrade experience that helps Azure Data Factory customers begin their journey to Fabric Data Factory with confidence. This new experience enables Azure Data Factory customers to bring their existing data factory into Microsoft Fabric, view their Azure Data Factory pipelines directly within Fabric, and continue using familiar management and monitoring experiences, all before making any migration decisions. Customers can experience Fabric immediately while preserving their existing Azure Data Factory investments. This is another important step toward our vision that every Azure Data Factory customer can become a Fabric Data Factory customer. Learn more about upgrading from Azure Synapse and Azure Data Factory to Microsoft Fabric. Customers leading the way The clearest way to explain what we are building is to watch a real customer use these capabilities for mission critical use. London Stock Exchange Group (LSEG) operates some of the world's most critical financial market infrastructure, and its data and analytics business turns operational data from many systems into governed data products that customers consume inside their own environments. Before Fabric, each of those three steps had its own machinery: pipelines to build and watch, analysis running on copies that engineers spent time reconciling, and a bespoke last mile for every customer of LSEG that was onboarded. LSEG’s data integration architecture is now vastly modernized. Mirroring brings the operational data into OneLake and keeps it current, the Fabric workloads shape it into the products customers pay for, and Copy job distributes those products out to customer environments — whether that environment is Fabric, another cloud such as Databricks or Snowflake, or a platform of their own. As Toni McDerment, who leads data interoperability at LSEG, puts it, the team is expanding distribution while streamlining integration. That is the whole data integration story in one customer: ingestion, analytics and delivery on a single estate. Across the conference, other customers showed the same shift from their own angles: Mediterranean Shipping Company — the world's largest container shipping company, with more than 1,000 vessels — replaced six-hour (sometimes multi-day) ETL cycles with real-time mirroring from SQL Server 2025 into Microsoft Fabric, moving operational data into analytics in seconds instead of hours while cutting storage costs 20% through new compression. For KPMG, onboarding clients and provisioning environments for new engagements — which previously required tickets and setup across multiple tools — decreased 87% from about 16 hours to 2 hours. Porsche Cup Brasil replaced spreadsheet-based, manual race reporting with a unified Fabric data pipeline — streaming more than 180 telemetry channels from 75 race cars via Eventstream into Eventhouse, Azure Data Factory, OneLake, and Power BI. The solution reduced engine-fault detection and response time from approximately 30 minutes to minutes, allowing teams to remove a failing engine from the grid before a breakdown. And we have many more customers achieving similar outcomes, with the same conclusion: the ceiling on what AI can do for a business is set by the quality, accessibility, and governance of the data underneath it. Looking ahead Data Integration is always a means to an end – data movement, orchestration, connectors are all structural elements that contribute toward the goal of turning massive amounts of data into business value. With Microsoft Fabric, our goal is to make these constructs disappear so that customers can focus on what ultimately matters – harnessing the value that resides in the data to improve business outcomes by leveraging AI. Our core focus in Data integration is making our products enterprise ready, work across clouds and be AI-driven. The work across our key investments and the 50-plus capabilities in this release are driving towards it. We are excited about what comes next and grateful to the customers, partners, and our community members who build this with us. Your ideas shaped this release, and they are already shaping the next one. Read the full list of FabCon announcements in the September release blog. Learn more Data Factory in Microsoft Fabric Get started with Microsoft Fabric What's new and planned for Data Factory In-depth technical blogs on the Microsoft Fabric Updates Blog
Diagnose Fabric Data Warehouse workloads with the SQL DW operations skill (Generally Available)
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. 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.Fabric July 2026 Feature Summary
Welcome to the July 2026 Fabric update! This month brings new capabilities across the Fabric experience, from improved deployment and governance experiences to expanded Spark, Eventstream, and Real-Time Intelligence functionality. Whether you're building data pipelines, managing analytics workloads, or monitoring real-time operations, these updates help you work more efficiently and get more value from your data. _______________________________ Events and Announcements Get Fabric certified for FREE This is your chance to take the DP-600 (Fabric Analytics Engineer) or DP-700 (Fabric Data Engineer) certification exams for free. As part of Data Days, we have over 100 live sessions, more than 5 contests and challenges, and dozens of study groups and learning opportunities. And free Fabric exam vouchers. Available now through August 10, 2026. Request your voucher. Join us for FABCON and SQLCON in Barcelona, September 28 – October 1, 2026 Explore what’s possible with Microsoft Fabric and get up to speed on the latest in SQL, analytics, and AI. From 130 sessions and 4 keynotes to workshops, the expo, community spaces, and the Power BI DataViz World Championships, this is where the data community comes together. Learn directly from Microsoft and community experts shaping the future of Fabric and SQL. Register now and save €200 with code FABCMTY200. Fabric Platform Fabric-CICD tool v1.2.0 – new bulk publish mode (Preview) The June release of the fabric-cicd Python library, v1.2.0 introduces bulk publish mode. It lets fabric-cicd publish multiple items in a single API call using the Fabric bulk import API instead of publishing each item individually through a separate API call. This can make deployments more efficient. Why this matters Because dependencies are managed by the API during publication, bpublishinglish reduces the rigidity of item-type-based staging and better supports cross-item dependencies when logical ID references are used. It can reduce the number of item-specific parameter values you need to configure. For unsupported scenarios, fabric-cicd automatically falls back to the standard publishing flow, so you can try bulk publishing without manually switching deployment paths. To learn more, refer to fabric-cicd bulk option documentation and the v1.2.0 release notes. Change Git branch with at least the contributor role (Preview) Fabric Git integration now let’s any workspace member with at least the Contributor role switch the workspace's connected Git branch. Previously, this action required the workspace Admin role, which forced developers to either be over-permissioned or wait on an admin every time they moved between branches. Why this matters Developers no longer need Admin rights to switch branches. Removes a key blocker in the branch-out to existing workspace flow. Keeps developers as Contributors, aligned with least privilege governance. Fewer hand-offs to admins mean faster time to code. You can find this new capability under the Git integration settings. To learn more about Fabric Git integration new setting, refer to the Allow Contributors and Members to switch branches documentation. We refreshed the Fabric CI/CD documentation this month to make it easier to get started and to follow best practices: New CI/CD intro page — a reworked Introduction to CI/CD in Microsoft Fabric that walks through the platform layer by layer with a new enterprise reference architecture. New best practices guide — Understand the best practices for Fabric CI/CD brings together practical guidance for structuring workspaces, branching, and promoting content safely across environments. Auto-bind for Git integration — new guidance on cross-workspace dependency binding, covering how item dependencies automatically rebind when you branch out or update from Git, and which dependency types are supported. Actionable recommended actions for data owners in the OneLake catalog The Govern tab in the OneLake catalog gives data owners a health view of their data estate, along with recommended actions to improve it, such as increasing sensitivity label coverage, removing items that are no longer in use, handle failed refresh, and more. Until now, these recommendations have told data owners what to improve, but not which items were affected, leaving them to track the relevant entities down manually before they could act. That gap turned a clear recommendation into a manual investigation, and the action often stalled before it started. This release closes that gap. When you open a recommended action, you now see the specific items behind the recommendation, with everything you need to act on them in one place, and a direct path to open item details and resolve the issue at the source. Selecting a recommended action now opens a dedicated view that includes: A breakdown of the affected items — a visual summary of how many of your items are impacted. Why it matters — a short explanation of the governance impact. How to fix it — clear, step-by-step instructions for resolving the recommendation. Newly added A complete list of affected items — displayed in a table with key details, including Name, Last Refreshed, Owner, Location, Endorsement, and Sensitivity, making it easy to review and prioritize actions. Filter and search — narrow the list by keyword or filters to focus on the items you want to handle first. Open item details — jump straight to any affected item to make the change, instead of searching for it across your workspaces. The same enriched experience applies across the recommended actions in OneLake catalog Govern, helping you act on each one without leaving the catalog: Increase Sensitivity label coverage — find and label items that create potential security risks while unlabeled. Remove unused items — review items that weren't accessed or refreshed recently to keep your estate organized and reduce costs. Investigate items that failed to refresh — see which items failed to refresh so your data stays current and reliable. Add descriptions to your endorsed items — surface endorsed items without a description so people can better understand and use them. Apply relevant tags to your items — make items more discoverable by tagging the ones that are missing tags. Why it matters Governance only improves when recommendations turn into action. By bringing the affected items and a direct way to reach them into every recommended action, OneLake catalog Govern removes the guesswork from following through. Data owners can move from understanding a recommendation to resolving it in just a few steps, keeping their data estate secure, organized, discoverable, and trustworthy with far less effort. Learn more about the OneLake catalog Govern tab recommended actions. Data Engineering Microsoft Fabric Runtime 2.0 (Preview) Based on feedback received directly from our customers and partners, we have upgraded Fabric Runtime 2.0 to the latest and compatible stack: Apache Spark 4.1 Delta Lake 4.2 Python 3.13 These upgrades bring access to the newest enhancements, performance improvements, and ecosystem innovations, while also providing a longer support window for enterprise customers to build large-scale analytics and AI workloads on Fabric. With Runtime 2.0, customers can take advantage of: Latest Spark and Delta Lake capabilities. Improved compatibility across the modern data ecosystem. Better developer productivity and runtime performance. Future-ready platform investments aligned with long-term supportability. Learn more about Fabric Runtime 2.0. Fabric Runtime Release Channels (Preview) Fabric Runtime Release Channels provide a structured and transparent way for customers to test upcoming runtime changes before they become the default. This feature helps organizations validate their production workloads early with these new changes in early access, avoid unexpected disruptions, and gain better control over Spark runtime upgrades. Instead of receiving silent updates that might break your production workloads, you can opt in to an early access release channel, test your workloads in a development or staging environment, and confirm compatibility before the update becomes default. How release channels work Each Spark runtime has at least two public release channels: Default channel — This production-grade channel runs the default version of the runtime. All users automatically use this channel unless they opt in to early access. Early access channel — This production-grade channel includes upcoming updates and library changes that are scheduled to become the next default channel. You can opt in to test your workloads against upcoming changes. Once the designated validation window ends, the early access release channel automatically gets promoted to become the new default, and a fresh early access channel is introduced with another set of new changes — continuing the cycle. This model gives you a predictable testing window before changes become default for everyone. Why release channels matter Spark runtime updates can include library upgrades, security patches, dependency changes, or even operating system upgrades. While all updates pass internal quality checks before release, those checks can't capture all customer-specific variations and use cases. Early access channels let you identify potential issues early and work with Microsoft by creating a support ticket to address them before updates affect your production environment. Benefit Description ✔ Predictable updates Customers know exactly when a new runtime becomes available and have time to validate against it. ✔ Reduced risk Testing workloads on early access ensures compatibility before changes reach production. ✔ Better visibility Customers can easily tell which runtime version they're running, reference release notes, and verify upgrade timing. ✔ Improved quality and security You receive well-tested builds with security patches applied faster, giving you confidence in runtime stability. Learn more about Fabric Runtime Release Channels: Fabric Runtime Release Channels. Spark Diagnostic Emitter: Spark 4.1 Runtime Support and New Log Ingestion API The Fabric Apache Spark Diagnostic Emitter is now supported on the Fabric Runtime with Apache Spark 4.1. Customers can collect driver logs, executor logs, Spark event logs, and metrics from workloads running on the latest runtime and route them to Azure Event Hubs, Azure Blob Storage, or Azure Log Analytics — using the same spark.synapse.diagnostic.emitter.* configuration model, so existing emitter setups carry forward as customers upgrade. The emitter also now supports the Azure Monitor Log Ingestion API for sending diagnostics to Log Analytics, available on both Spark 3.5 and Spark 4.1 runtimes. The new AzureLogIngestion emitter type replaces the legacy HTTP Data Collector API path, providing a structured ingestion model with DCR/DCE-based authentication, schema definition, and routing into custom Log Analytics tables. Customers currently on the legacy AzureLogAnalytics type are encouraged to migrate — migration involves creating Data Collection Rule and Data Collection Endpoint resources and updating the Spark properties in the Fabric Environment. To learn more, refer to the Collect logs and metrics with Azure Log Analytics for migration guidance and Spark Diagnostic Emitter documentation. The Fabric Spark Operations Skill — AI-Assisted Spark Diagnostics, Open Source (Preview) The Fabric Spark Operations Skill (spark-operations-cli) is now available in the open-source Skills for Fabric library on GitHub (microsoft/skills-for-fabric). The skill brings AI-assisted, read-only diagnostics to Spark workloads in Fabric — troubleshoot failed notebooks and Spark jobs, stuck Livy sessions, and performance bottlenecks (OOM, shuffle, skew) in plain English from GitHub Copilot CLI, Claude Code, VS Code, Cursor, or other compatible AI tools. It returns severity-ranked findings with root cause analysis and fix recommendations, and includes an automated diagnostic workflow spanning job triage, log mining, Spark Advisor findings, and mitigations. Setup takes minutes: install the skill, run az login, and ask, "Why did my notebook fail last night?" Get started with Skills for Fabric in GitHub. Faster Python UDFs, Scala UDFs, and complex data types in the native execution engine (Generally Available) The native execution engine in Microsoft Fabric, which is generally available, now accelerates Python user-defined functions (UDFs), Scala UDFs, and complex data types such as arrays, maps, and structs. You get faster Spark processing for expressive code without changing your existing notebooks or jobs. Python UDFs have historically carried serialization overhead as data moves between the JVM and Python worker processes. The native execution engine optimizes that data path and keeps vectorized processing intact, so scalar and Pandas (vectorized) UDFs run faster automatically. Scala UDFs and queries that work with nested, complex data types benefit from the same native acceleration. Why this matters Faster UDF execution with no code changes. Vectorized Pandas UDFs see the largest gains. Complex types (arrays, maps, structs) run natively. Existing notebooks and jobs benefit automatically. To use Efficient Scaledown, enable the native execution engine on your Fabric Spark pool or environment. Existing Python and Scala UDFs and queries over complex types are accelerated without any code changes. To learn more, refer to the Python UDFs, Scala UDFs, and complex data types in the native execution engine documentation. Efficient Scaledown with the remote shuffle manager (Preview) Efficient Scaledown decouples Spark shuffle data from executor lifetime in Microsoft Fabric. Instead of pinning shuffle output to local executor disks, Fabric Spark routes large shuffles to Azure Blob Storage and migrates blocks off executors before they're released. Clusters scale down faster, compute costs drop, and jobs become more resilient — with no changes to your queries, notebooks, or pipelines. The feature combines four cooperating capabilities: the Remote Shuffle Manager writes and reads shuffle data to Azure Blob Storage; Shuffle Migration moves blocks off an executor before decommissioning instead of dropping them; a Decision Layer routes small shuffles to local disk and large shuffles to remote storage per stage; and AQE Shuffle Write lets Adaptive Query Execution shape partitioning the first time. Why this matters Clusters scale down faster after demand drops. Lower compute cost from quicker executor release. More resilient jobs with fewer stage retries. No changes to queries, notebooks, or pipelines. To use it, enable the native execution engine and run on Runtime 1.3 (Apache Spark 3.5) or later; autoscale is recommended. Remote Shuffle Manager spark.conf.set("spark.remote.shuffle.enabled", "true") Decision Layer — per-stage routing of local vs. remote shuffle spark.conf.set("spark.sql.rsm.decisionlayer.enabled.level", "stage") AQE participates in shuffle write spark.conf.set("spark.sql.adaptive.shuffleWrite.enabled", "true") Shuffle Migration on executor decommission spark.conf.set("spark.storage.decommission.shuffleBlocks.enabled", "true") spark.conf.set("spark.storage.decommission.shuffleBlocks.cleanup", "true") spark.conf.set("spark.storage.decommission.shuffleBlocks.migrateToFallbackStorage", "true") spark.conf.set("spark.storage.decommission.fallbackStorage.cleanUp", "true") To learn more, refer to the Efficient Scaledown and remote shuffle manager in Microsoft Fabric documentation. Customer-managed key encryption for Spark shuffle data on disk (Generally Available) Microsoft Fabric Spark now generally supports customer-managed keys for Spark jobs through a disk encryption set. Shuffle data written to cluster disks during a Spark job is encrypted with a key you supply and control, giving you ownership of the encryption material that protects intermediate data at rest. With a disk encryption set configured, the cluster disks that hold Spark shuffle data are encrypted using your customer-managed key rather than a platform-managed key. You manage the key lifecycle — including rotation and access — in your own key vault, so encryption of intermediate Spark data follows your organization's key management policies. Why this matters You control the key protecting shuffle data. Intermediate Spark data on disk is encrypted at rest. Key lifecycle and rotation stay in your control. Encryption aligns with your key management policies. To use it, configure a disk encryption set backed by your customer-managed key and associate it with your Fabric Spark configuration. Spark jobs then encrypt shuffle data on cluster disks with your key. To learn more, refer to the Customer-managed key encryption for Fabric Spark documentation. Query your data instantly with the Lakehouse Query Explorer (Generally Available) The Lakehouse Query Explorer is a new, fully integrated query editor built directly into the Lakehouse experience in Microsoft Fabric. You can now write and run Spark SQL queries right where your data lives — no need to switch to a SQL endpoint or spin up a notebook for quick exploration. Whether you’re validating datasets, iterating logic, or exploring patterns, Query Explorer keeps you in flow. orer with the new integrated Query Explorer. Key capabilities Fast, lightweight Spark execution powered by the Lakehouse Livy endpoint. IntelliSense + rich editing experience for faster query authoring. Query across schemas and lakehouses in a single tab. Built-in results grid + inline charts to explore results instantly. Multiple dynamic tabs to analyze different slices of data side-by-side. From quick lookups to multi-table exploration, Query Explorer makes working with Lakehouse data faster and more intuitive—right from the explorer. Learn more and get started with the Lakehouse Query Explorer documentation. Analytics and Insights for Materialized lake views (Generally Available) Analytics and Insights bring continuous refresh intelligence to your lakehouse — two new tabs beside Recent run(s) that shift you from reacting to individual failures to staying ahead of performance drift, rising costs, and silent inefficiencies across your entire materialized lake view estate. The Recent run(s) page tells you what happened in a single execution, including which views succeeded, which failed, and how long the job took. That's valuable when something breaks, but it doesn't answer the questions that matter most for day-to-day operations. Are my durations stable or slowly climbing? Is a new error class appearing and spreading across views? Are my schedules still aligned with how often upstream data actually lands? Am I paying for full refreshes on views that could run incrementally? These are the questions that separate a well-tuned deployment from one that quietly accumulates cost and risk until something finally breaks loudly enough to notice. The Recent run(s) page answers all of them. The Analytics tab transforms your run history into trend lines, distributions, and comparisons you can read at a glance: duration trajectories, success-rate shifts, error-class frequency over time. The Insights tab goes further by watching those same patterns the way a seasoned reliability engineer would, recognizing the signatures behind slow, failing, or wasteful runs, and providing a prioritized list of worthwhile changes. Each recommendation names the affected view, explains why it's flagged, and estimates the payoff in runtime savings, so you can act in seconds rather than investigate for hours. Together, they move refresh management from a reactive, break-fix posture to a proactive, continuously improving one — keeping your materialized lake views fast, healthy, and cost-efficient as your estate grows. To learn more, refer to analytics charts, insight categories in Materialized Lake Views. Introducing Event-Driven Refresh for Materialized Lake Views (Preview) Event-driven refresh brings responsive refresh intelligence to your lakehouse — a new scheduling mode alongside time-based schedules that shifts you from refreshing on the clock to refreshing the moment your data is ready, so your materialized lake views reflect reality instead of an arbitrary calendar. Time-based schedules tell your views when to run: every hour, every morning, every night. That's dependable when upstream data lands like clockwork, but it doesn't answer the questions that matter most for day-to-day operations. Did the ingestion pipeline that feeds this view finish before I refreshed it? Am I recomputing gold-layer views on a fixed cadence while the source data only changes twice a day? Am I paying for refreshes that run before new data has even arrived — or worse, serving stale results because the next scheduled slot is still hours away? These are the questions that separate a refresh strategy tuned to your data from one that quietly burns compute on empty runs and lags the moments that matter. Event-driven refresh answers all of them. You bind a view or a lineage sub-chain to the events that should drive it, and we support two types of events: OneLake events — all file and folder events are supported, so a refresh can fire the moment data lands in OneLake (file or folder creation, update, and more). Job events — Pipeline and Notebook events are supported, so a refresh can fire when the ingestion job that feeds your views completes. The moment an event fires, Fabric resolves the dependency chain and refreshes exactly the views that depend on it. Each trigger names the source event, scopes precisely to the affected lineage, and can react to success or failure, so a stalled upstream job never silently cascades into stale downstream reports. Together with multi-schedule support, event-driven refresh moves refresh management from a fixed-clock, guess-the-cadence posture to a responsive, data-driven one — keeping your materialized lake views fresh the instant new data arrives, and idle when it hasn't, as your estate grows. Learn more and get started with the Schedule a Materialized Lake View Refresh documentation. Data Science AI functions: new models, no package dependency, better usage stats (Generally Available) Fabric AI Functions now use gpt-5-mini as the default model, with “low” reasoning enabled. This powers AI Functions across pandas, PySpark, Data Warehouse, and Dataflows Gen2. For more sophisticated transformations, users may configure gpt-5.1 or tune the reasoning_effort parameter for additional compute and higher-quality results. The gpt-4.1 model has been retired. Pipelines pinned to gpt-4.1 have migrated to gpt-5.1, and those pinned to gpt-4.1-mini migrated to gpt-5-mini. We’ve also simplified PySpark AI Function chaining. The PySpark .ai interface now stays bound to the result schema, so chains like summarize → classify no longer require intermediate DataFrames. In addition, PySpark now supports df.ai.stats for detailed token usage after any AI function call, including reasoning token breakdowns. For pandas, AI Functions no longer require the openai-python package. Capacity-limited rows are surfaced as CapacityExceededResult, enabling clean retries via aifunc.split_results. To learn more, refer to the AI Functions documentation. Data Warehouse Lakehouse table health check (Generally Available) Lakehouse Table Health Check gives you a simple, T-SQL–based way to validate whether your Lakehouse tables are optimized for the SQL analytics endpoint. A single stored procedure surfaces common layout issues, such as small files and fragmentation, offering the insights you need to determine if your tables need to be optimized. You can integrate health checks into pipelines and operational workflows, enabling proactive, at-scale optimization instead of reactive troubleshooting. -- Run a health check on a Lakehouse table from the SQL analytics endpoint EXEC sp_get_table_health_metrics 'dbo.FactSales'; aluate table health. To learn more about sp_get_table_health_metrics and how to integrate it into your Pipelines to optimize your table only if anomalies are detected, refer to sys.sp_get_table_health_metrics (Transact-SQL). Scalar User‑Defined Functions - Procedural computation for analytical SQL (Preview) Scalar User-Defined Functions now support procedural computation — including loops, multiple return paths, and rich IF/THEN/ELSE branching — running natively within the warehouse engine. Computation-based Scalar UDFs are designed for analytical query shapes, integrating naturally with CTEs, GROUP BY, HAVING, and ORDER BY, and executing efficiently at data warehouse scale. Defining business rules once, in SQL, and reuse them across queries, reports, and pipelines. To learn more, refer to the Create Function documentation. Usage-based resource estimations (Generally Available) The Query Optimizer uses learned resource estimation to correct underestimation in T-SQL query plans. It saves actual cardinalities from past executions and automatically adjusts row count estimates in subsequent runs. With this release, the optimizer will also begin correcting overestimations — closing the loop in accurate cardinalities, leading to more efficient resource requests and improved concurrency. Real-Time Intelligence Improved tile error experience in Real-Time Dashboard (Generally Available) We improved the way tile errors appear in Real-Time Dashboards to make them clearer, calmer, and easier to act on. Instead of showing a disruptive red error state, tiles now use a neutral grey error state with a short category header, such as Syntax error, Semantic error, Data source issue, Network error, or Something went wrong. Users can select Details directly from the tile to open a popover with the full engine error message, shown exactly as received. This keeps the dashboard readable while still making the technical details easy to access, copy, and share when needed. This update helps users understand what went wrong faster, while ensuring that one failed tile does not block or visually overwhelm the rest of the dashboard. To learn more, refer to the Troubleshoot Real-Time Dashboard Tile Errors documentation. Folders in Eventhouse tree (Generally Available) Folder support in the Eventhouse tree is now available through the UI. Previously, folders could only be created and managed via code. With this update, you can now organize your Eventhouse directly from the tree, making it easier to manage assets at scale. You can group tables, shortcuts, materialized views, functions, and data streams into a structured hierarchy, improving navigation and reducing clutter. Key capabilities Create, rename, and delete folders from the UI. Organize assets into folders. Move items via the context menu (⋯ → Move to). Create folders inline while moving items. This allows for a simplified and more intuitive way of managing growing Eventhouses. To learn more, refer to the Manage and monitor a KQL database table documentation. Eventstream connector private network support (Generally Available) Data is a critical asset for organizations, and access to real-time data is increasingly essential. However, many high-value data sources reside in private network environments — cloud virtual networks or on-premises infrastructure — particularly in highly regulated industries such as banking, finance, and telecommunications, where strict security and compliance requirements are mandatory. Eventstream's private network support establishes a secure, managed bridge using your Azure virtual network and VNet injection, allowing Eventstream streaming connectors to run inside your virtual network and reach private sources without opening them to the public internet. Whether your data sources reside in on-premises networks, private networks on third-party cloud services, or private networks on Azure, you can connect the bridge Azure virtual network to your source's private network using suitable connectivity options — such as VPN or ExpressRoute for on-premises environments, and private endpoints or network peering for Azure-based sources — enabling Eventstream connectors to securely ingest real-time data from these protected environments into Fabric. The solution leverages a new concept — Streaming virtual network data gateways — which abstracts the bridge Azure virtual network and subnet resource within Fabric. By creating a connector with a streaming virtual network data gateway associating it with your connection, the Eventstream connector is provisioned within your virtual network, ensuring secure communication with your private data sources. Once real-time data from your private network source is securely brought into Fabric Eventstream, you can fully leverage the comprehensive analytics tools in Fabric Real-Time Intelligence to power your real-time scenarios with enterprise-grade security. To learn more about configuration and advanced scenarios, refer to the Eventstream private network streaming guide. Azure Event Hubs source in Eventstream now supports workspace identity authentication (Preview) Currently, when configuring an Azure Event Hubs source in Eventstream, the only supported authentication method is Shared Access Key — a connection string containing static credentials. While simple to set up, shared access keys present several security risks in production environments: they have unlimited lifetime unless manually rotated, provide no per-user or per-application identity, and if accidentally leaked through source code, configuration files, or third-party sharing, grant full access to anyone who obtains them. Revoking a compromised key requires regeneration, which disrupts all services depending on it — with no straightforward way to audit which clients used the key. To address these challenges, we're introducing Workspace Identity as a new authentication option for the Azure Event Hubs source connector (Extended features) in Eventstream (Preview). A Fabric workspace identity is an automatically managed service principal associated with your workspace. Fabric manages the credentials entirely — there are no secrets to store, rotate, or risk leaking. It integrates with Microsoft Entra ID, providing identity-based access with full audit trails, fine-grained role-based access control, and automatic credential lifecycle management. To use workspace identity authentication with your Azure Event Hubs source in Eventstream: Navigate to your workspace settings and create a workspace identity on the Workspace identity tab. In your Azure Event Hub namespace, assign the appropriate role (e.g., Azure Event Hubs Data Receiver) to the workspace identity's service principal. When adding an Azure Event Hubs source in Eventstream, select Workspace Identity as the authentication method — no connection string or key is needed. Eventstream will automatically obtain tokens using the workspace identity to securely connect to your Event Hub, eliminating credential management overhead while strengthening your security posture. To learn more about the configuration, refer to the Azure Event Hubs source extended connector configuration documentation. Custom CA and mTLS support in Eventstream streaming connectors (Generally Available) Fabric Eventstream under Real-Time Intelligence provides various streaming connectors, enabling the integration of real-time data from popular sources into Fabric. When the Eventstream connector client establishes a connection with sources, it is required to implement TLS or mTLS encryption to fulfil the necessary security standards. Many organizations use certificates issued by private or internal Certificate Authorities or require mutual TLS (mTLS) authentication where both the client and server verify each other's identity before transmitting data. Without custom CA and mTLS support, Eventstream connectors cannot connect to these secured source systems. The Custom CA and mTLS support feature, is now generally available for MQTT, Apache Kafka, AWS MSK, and Confluent Cloud for Apache Kafka source connectors. Customers can specify their custom CA and client certificates managed in their own Azure Key Vault when configuring their source in Eventstream. Once specified, Eventstream connector will fetch the certificates from the customer's Azure Key Vault and use them to establish a mutually authenticated, encrypted connection — enabling secure, compliant real-time data ingestion across all supported streaming sources. To learn more about the configuration, refer to the Eventstream sources overview page and choose the corresponding source. Introducing the Oracle CDC connector for Eventstream (Preview) Eventstream now introduces the Oracle Database Change Data Capture (CDC) connector, enabling you to stream database change events directly from any Oracle Database — whether running in the cloud or on-premises — into Eventstream for real-time processing and analytics. Many organizations run important operational workloads on Oracle Database and need to react to changes as they happen. With the Oracle CDC connector, you can continuously capture change events from Oracle Database and bring them into Fabric without building custom polling applications or managing separate integration services. With the Oracle CDC connector, you can: Capture and stream databases changes from Oracle Database into Fabric in real time. Connect to Oracle databases running either on-premises or in the cloud. Process incoming change events using Eventstream transformations. Route processed change events to supported destinations such as Eventhouse, Lakehouse, Activator, or custom endpoints. This capability helps you build real-time analytics and event-driven applications from Oracle data. For example, you can route transaction changes to an Eventhouse Kusto table for operational analysis, send selected events to Activator for alerting, or combine Oracle change events with other streaming sources in the same eventstream. To learn more about Eventstream Oracle CDC connector, refer to Add Oracle Database CDC source to an eventstream (preview). Eventhouse update policies now support referencing accelerated shortcuts in update policies (Generally Available) Eventhouse update policies now support accelerated shortcuts in update policy queries, enabling ingestion-time enrichment scenarios. Use this for dimension lookups, such as enriching ingested fact events with customer, device, or product attributes stored in OneLake shortcut data. The shortcut-backed external table must have Query Acceleration Policy enabled, and Hot must cover all data. For update policy scenarios, set: .alter external table DimCustomer policy query_acceleration '{"IsEnabled":true,"Hot":"36500.00:00:00"}' Then join to it from the update policy query: .alter table EnrichedEvents policy update '[{ "IsEnabled":true, "Source":"RawEvents", "Query":"RawEvents | lookup kind=leftouter (external_table(''DimCustomer'')) on CustomerId","IsTransactional":true, "PropagateIngestionProperties":false }]' Processing uses the authorization context captured in the system-populated OwnerPrincipalDetails property: the user who creates or alters the update policy must have access to the shortcut data. This enables ingestion-time enrichment with governed shortcut data without separate orchestration. Shortcut Tables in Eventhouse Now Automatically Synchronize Schema Changes To help maintain consistency between source data and shortcut tables, the default schema synchronization behavior for Eventhouse shortcut tables is changing. Previously, schema changes made to the source table were not automatically propagated to the shortcut table unless schema synchronization was explicitly enabled. As a result, source and shortcut schemas could diverge over time. With this update, all new and existing shortcut tables in Eventhouse automatically synchronize schema changes from their source table by default, including: Adding new columns Changing column data types Renaming columns Deleting columns Automatic schema synchronization helps ensure that shortcut tables remain aligned with the source schema, preserving the latest business context and reducing manual maintenance. Customers who prefer to disable automatic schema synchronization can continue to control this behavior using the existing KQL management command: .create-or-alter external table ExternalTable kind=delta ( h@'https://storageaccount.blob.core.windows.net/container1;secretKey' ) with (AutoUpdateSchema=false) Note: Because schema changes are now automatically propagated, queries, dashboards, and downstream workloads may require updates if they reference columns that are renamed, removed, or otherwise modified in the source table. Investigator Insights in Operations Agent (Preview) When an anomaly is detected, understanding what caused it is often the hardest part. Investigator insights are designed to make that easier by analyzing the surrounding data and surfacing relevant context. When the operations agent detects that a rule has been met, there is an option to run an investigation in the background to identify correlated signals and patterns. Instead of manually digging through telemetry, you get a guided view into what changed, what stood out, and what may have contributed to the issue. This helps you move more quickly from detection to understanding. You can access these insights directly from Teams. Open the agent’s message and select Investigate further to generate a detailed analysis. The investigation provides a structured view of what happened: Investigation scope shows which tables were analyzed, whether from a single source or across related datasets. Key observations highlight the most important findings, including actual values, deviations from baseline, and notable trends or outliers. Pattern analysis surfaces meaningful changes around the time of the anomaly, such as dimensions with significant shifts, and clearly call out when no strong patterns are identified. Together, these insights help you quickly understand not just that something went wrong, but why it happened. To learn more, refer to the Operations Agent Actions documentation. Anomaly Detector Configurations Pane As you build on top of your data, it is often just as important to understand what already exists as it is to create something new. This update makes it easier to discover and build existing anomaly detection configurations. You can now view all anomaly detection configurations that have already been created for a given data source in one place. This lightweight experience gives you quick visibility into how anomaly detection is currently set up, helping you avoid duplicate work and better understand how others are using the data. From this view, you can explore existing configurations or create a new one if your use case is not yet covered. This makes it simple to extend existing setups or start fresh when needed, all without leaving the context of your data source. By making configurations easier to discover and reuse, this experience helps streamline workflows and ensures you can move quickly from exploration to action. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Ingestion time stamp in Anomaly Detector (Preview) Working with anomaly detection often assumes your data already includes a clean, reliable timestamp. With this update, you can now use the system-generated ingestion time as the timestamp for anomaly detection. This means that even if your dataset does not include a dedicated timestamp column, you can still run analysis without needing to modify or preprocess your data. This is especially helpful for scenarios where events are ingested in real time or where timestamps are missing, inconsistent, or not trustworthy. Instead of blocking data preparation, you can rely on ingestion time to move forward with detection and start identifying meaningful patterns right away. By reducing setup requirements and removing a common dependency on source data quality, this capability makes it easier to apply anomaly detection across a wider range of use cases. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Configuring Anomaly Detection without a Group by Column (Preview) With this update, Anomaly Detection now supports scenarios where you choose not to use a group by column. This provides an additional configuration option for datasets that already represent a single stream of data, allowing you to apply anomaly detection directly to the metric without first identifying a grouping dimension. This added flexibility helps the configuration experience better align with how your data is structured. Whether you are monitoring a single device, tracking a specific service, or analyzing a focused dataset, you can now create anomaly detectors without requiring a group-by column. At the same time, grouping remains available for scenarios where you want to monitor and compare multiple entities within the same dataset. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Introducing Fabric Maps Tilesets: High-Performance Visualization for Large Geospatial Datasets (Generally Available) Have location-based data sitting in OneLake but no simple way to see it come alive on a map? With Fabric Maps Tilesets, you can now turn that data into fast, interactive map experiences directly inside Microsoft Fabric. The Tileset Builder lets you create map-ready PMTiles from OneLake data without custom code, manual exports, or separate geospatial infrastructure making it easier for teams to explore large geospatial datasets, uncover patterns, and bring location intelligence into the analytics workflows they already use. Organizations can rely on Microsoft Fabric to manage operational data, analytics workflows, and business reporting. When that data includes locations, routes, assets, boundaries, or events with a location context, teams need a simple way to visualize it on a map. Traditionally, this required separate geospatial pipelines, custom polling services, or manual exports. Leveraging a Fabric Map removes complexity by allowing organizations to create and refresh map-ready tilesets from data already stored in OneLake. Try creating your own Tileset using the following steps: Connect to a lakehouse and select source files Configure tileset metadata Configure layer settings Tileset schedule (Preview) Review and create tileset What is a Tileset? Tilesets are map-optimized representations of geospatial data. Instead of trying to load a large geospatial data file all at once, data is divided into small tiles that are loaded and rendered as needed while users zoom and pan across the map. This makes tilesets especially useful for large datasets, such as infrastructure networks, delivery routes, asset locations, service areas, or operational events. Fabric Maps Tileset Builder Capabilities Build map-ready tilesets directly from OneLake data. Visualize large geospatial datasets with high performance. Enable smooth, interactive map experiences at scale. Keep map content synchronized with source data. Eliminate manual exports and external geospatial processing workflows. Integrate native geospatial visualization into existing Fabric data workflows. Common scenarios Tilesets help teams turn large location-based datasets into fast, interactive map experiences. Utility and energy companies can visualize nationwide power line grid systems as a single dataset to monitor field assets and service coverage. Supply chain and logistics teams can explore daily routes, regional boundaries, and operational areas. Retailers can analyze store territories, expansion opportunities, and new developments. Because the data stays connected to Fabric, these map experiences become part of the broader analytics workflow — not a separate geospatial process. To get started, refer to How to create tilesets. Cross-domain intelligence with Azure Monitor data in Microsoft Fabric (Preview) Have you ever detected an issue in your systems but struggled to understand what it meant for the business? As systems grow more complex, this gap becomes harder to bridge. Incidents no longer affect just systems; they affect customers, revenue, and operations in real time. Azure Monitor Logs mirroring into Microsoft Fabric helps close that gap. In just a few steps, telemetry from Log Analytics workspaces becomes available in OneLake alongside business and operational data — without duplication and with near real-time availability. This creates the foundation for Cross-domain insights and actions: Bring observability, operational, and business data together in Eventhouse for real-time analysis. The same unified data can be used by Real-Time Dashboards for investigation and by operations agents to recommend and drive actions informed by both business and observability context. For example, an operations team can identify that a check-in kiosk outage is impacting high-value customers and act before customer impact grows. Advanced Fabric analytics Apply tools like Spark and Power BI for long-term analysis, machine learning, and a wide range of analytical scenarios. For example, an operations team can create a Power BI report showing trends in customer impact and cost, helping management make informed decisions on resource allocation and understand the true cost of application failures. Together, these capabilities help organizations move from isolated technical signals to business-aware insights, decisions, and actions. To learn more, refer to Cross-domain intelligence with Azure Monitor data in Microsoft Fabric (Preview). Until next month That's a wrap for the July 2026 Microsoft Fabric Monthly Update. As always, we'll continue sharing new capabilities, enhancements, and improvements across Microsoft Fabric in future monthly updates. Thank you for being part of the Fabric community!
Fabric Data Agents in Microsoft Copilot Studio (Generally Available)
Organizations can now bring governed business data from Microsoft Fabric into Copilot Studio agents, enabling agents to answer questions, generate insights, and support business processes using trusted enterprise data. Fabric data agents make it easier to ground experiences in the data your organization already relies on. Since we announced this integration in preview, both Fabric and Copilot Studio have evolved significantly. General availability provides a more integrated experience, broader publishing options, and a stronger foundation for deploying data-powered agents across the Microsoft ecosystem. Fabric Data Agents are now integrated as tools Previously, you added a Fabric data agent from the Agents category as a connected agent. Now, Fabric data agents integrate through the new tool-based experience in Copilot Studio. Simply select Add a tool, search for Fabric, and select Fabric IQ Data MCP. Your Copilot Studio agent can then invoke the Fabric data agent the same way it calls any other tool. The orchestrator decides when to reach for enterprise data and when to rely on its other knowledge sources and tools. The Fabric data agent continues to execute in Fabric, respect permissions on underlying data sources, and return answers grounded in governed enterprise data. The benefit is a more composable architecture. A Fabric data agent becomes one capability among the connectors, workflows, and other tools available to your Copilot Studio agent. You can combine multiple Fabric data agents with other business systems to create richer, more capable solutions. Built on the new Copilot Studio experience and runtime Copilot Studio introduced a redesigned authoring surface and runtime powered by the GitHub Copilot harness. You can build, test, evaluate, publish, and monitor agents from a unified environment while using natural language to describe agent behavior and capabilities. For Fabric customers, the biggest benefit is improved orchestration. The harness uses an improved reasoning model that is better at deciding which tool to call and how to combine what comes back, which matters when a Fabric data agent sits next to SharePoint knowledge, connectors, and other tools in the same agent. You choose the harness when you create the agent. Agents built with the standard harness remain fully supported. Instead of building isolated data experiences, organizations can create agents that reason across multiple sources of enterprise knowledge while using Fabric as their trusted data foundation. Publish to Microsoft Teams and Microsoft 365 Copilot Another improvement since preview is broader reach. You can now publish your Copilot Studio agent to Microsoft Teams and Microsoft 365 Copilot, bringing governed, data-grounded experiences directly into the tools people use every day. For example, a business user can ask about last quarter's regional performance in Microsoft 365 Copilot and get an answer from governed Fabric data without leaving the conversation they are already in. As always, permissions continue to apply. Users must have access to the Fabric data agent and its underlying data sources. d GIF - Add Fabric data agent as a tool to your Copilot Studio Agent. Why this matters The rise of AI agents is creating a new challenge for organizations: how to ensure agents are grounded in trusted business data rather than disconnected information sources. Fabric and Copilot Studio solve different parts of that challenge. Fabric provides the intelligence layer. It is where organizations bring together, govern, and publish data expertise through data agents. Copilot Studio provides the orchestration layer. It is where organizations build agents, workflows, and business processes that put that expertise to work inside a broader business process. Adding a Fabric data agent means everything you compose there can reason over governed enterprise data. Now, Fabric data agents and Copilot Studio (Generally Available) makes it easier than ever to bring governed data, business context, and intelligent action together in a single agent experience. Together, they enable organizations to: Build multi-agent solutions. Fabric data agent supplies the analysis while other agents and tools carry the rest of the process, such as drafting the document, updating the system of record, or routing an approval. Bring data together with everything else your agent knows. A Copilot Studio agent can pull a number from Fabric and a policy from SharePoint in the same answer. Meet users where they work. Publish to Teams and Microsoft 365 Copilot so business users get data-grounded answers in the flow of their work. Keep one definition of your data. Fabric data agent stays the single source of truth for every Copilot Studio agent that consumes it, so answers do not drift between teams. Build it once in Fabric and reuse it across departments. Getting started Getting started with Fabric data agent integration with Copilot Studio (Generally Available) is easy: Build and publish a Fabric data agent with a clear, detailed description. Create or open an agent in Copilot Studio. Under Tools, select Add a tool, search for Fabric, and add Fabric IQ Data MCP. Test your agent in Preview. Publish to Microsoft Teams or Microsoft 365 Copilot. To learn more, refer to the Add a Fabric data agent as a tool in Microsoft Copilot Studio documentation for the full setup, and join the community discussion to share feedback and report issues.Fabric August 2026 Feature Summary
Welcome to the August 2026 Fabric update! Microsoft Fabric continues to evolve with new capabilities that help organizations build, manage, and scale their data and AI solutions more efficiently. This month's updates introduce enhancements across Fabric Platform, OneLake, Data Engineering, Conversational Analytics, Data Warehouse, Real-Time Intelligence, and Data Factory. Whether you're strengthening governance, improving performance, streamlining development workflows, or expanding AI-powered experiences, these updates are designed to help you get more value from your data while simplifying day-to-day operations. Explore the following highlights to see what's new in Microsoft Fabric this month. Events and Announcements Join us for FABCON and SQLCON in Barcelona, September 28 – October 1, 2026 Explore what’s possible with Microsoft Fabric and get up to speed on the latest in SQL, analytics, and AI. From 130 sessions and 4 keynotes to workshops, the expo, community spaces, and the Power BI DataViz World Championships, this is where the data community comes together. Learn directly from Microsoft and community experts shaping the future of Fabric and SQL. Register now and save €200 with code FABCMTY200. Fabric Platform KQL-Dashboard Embed in Fabric (Preview) A new capability that lets you add interactive KQL-Dashboard content directly into your own browser-based web applications is available. Now, you can bring Fabric analytics into the apps, portals, and workflows your users already use. Analytics are most useful when they are available where decisions happen. With Fabric Embed, you can place Fabric content inside a custom application or internal portal instead of requiring users to switch to the Fabric portal. Fabric Embed can help you: Bring interactive analytics into an existing business workflow. Explore Fabric analytics without switching between your application and the Fabric portal. Keep Fabric workspace permissions and Microsoft Entra ID identities at the center of access control. Build user-based embedded experiences for people who already have access to the underlying Fabric item. The embedded experience complements the Fabric portal. Content owners can continue to create and manage analytics in Fabric while application developers present that content in the context most useful to their users. To learn more, refer to the Microsoft Fabric Embed documentation. Git Integration – Workspace Relation API (Preview) Following our recent announcement of branch workspaces and the relationship that’s automatically created when a user performs a branch-out operation, we’re introducing the new Workspace Relations API. These endpoints let you create, query, update, and delete relationships between Fabric workspaces programmatically — and for anyone building automation around Git integration, branched workspaces, and CI/CD, it’s a big deal! The workflow is straightforward. A developer creates a feature branch. An ADO pipeline or GitHub Action then provisions a new feature workspace, configures Git, applies the right settings and permissions, and synchronizes the workspace. Finally, the Workspace Relations API links that feature workspace back to its parent — closing the loop and giving your automation a first-class, queryable connection between parent and branched workspaces. Figure: Branch workspace relation. To learn more, refer to Development process using Branch-Out experience. Git Integration and Deployment Pipeline – Item level permission restriction Starting December 1, 2026, users without read-write permissions on workspace items can't use Git integration and won’t be able to deploy a workspace or assign workspace to a stage via Deployment Pipeline. This restriction can result in loss of access to certain items because of sensitivity labels and protection policies applied to those items. To learn more, refer to Information Protection in Microsoft Fabric. OneLake Resource instance rules for OneLake (Generally Available) Resource instance rules for OneLake are ready for production workloads across enterprise analytics environments. They give workspace admins a precise way to allow access from trusted Azure resource instances while continuing to enforce network and data-level protections. Use resource instance rules when you need to enable secure service-to-service access to OneLake without relying solely on IP allowlists or requiring private networking for every integration. Combined with Private Link, IP firewall rules, and identity-based permissions, they help organizations apply layered security based on the needs of each workspace and workload. Resource instance rules support a broad set of Azure services that can present a verifiable Azure resource identity, including Azure Databricks, Azure SQL Server, Azure Data Factory, Azure Event Grid, Azure Machine Learning, and more. Configuration requires only the Azure resource ID, simplifying setup while maintaining control over which Azure resources can access OneLake. To learn more, refer to Manage inbound access to OneLake with Resource Instance Rules. Data Engineering Native Execution Engine performance improvements This month, we continued to improve the Native Execution Engine (NEE) with a new set of query execution optimizations designed to accelerate Spark workloads while reducing compute consumption. Key enhancements include broadcast joining reuse across queries, native acceleration for ranking window functions such as RANK and DENSE_RANK, and automatic materialization of reused Common Table Expressions (CTEs). Together, these optimizations eliminate redundant computation, keep more processing within the engine's vectorized execution path, and improve performance for common data engineering patterns including large joins, analytical reporting, ranking workloads, and complex transformation pipelines. Because these improvements are enabled automatically when NEE is available, customers benefit from faster execution times, lower Fabric capacity consumption, and improved price-performance without requiring code changes to existing notebooks, Spark Job Definitions, or pipelines. These optimizations are enabled by default once the Native Execution Engine is turned on, allowing customers to realize performance gains immediately without additional configuration or tuning. Customers can enable NEE at the workspace environment level by navigating to Environment > Acceleration and turning on Native Execution Engine, ensuring it is available for all Spark sessions using that environment. It can also be enabled at the session level by setting spark.native.enabled=true in Spark configuration. With NEE enabled, customers can seamlessly take advantage of the latest runtime innovations to process data faster, improve resource efficiency, and maximize the value of their Fabric capacity investments. To learn more about Native Execution Engine explore our documentation Native execution engine for Fabric Data Engineering. Fabric Runtime 2.0 (Generally Available) As the execution foundation for Microsoft Fabric's Data Engineering and Data Science experiences, Runtime 2.0 delivers a modern, high-performance platform built on Apache Spark and deeply integrated across the Fabric ecosystem. Purpose-built for large-scale data processing and analytics workloads, Runtime 2.0 represents a major advancement in performance, reliability, security, and future readiness. Built on the latest open-source innovations, it enables customers to accelerate data processing, simplify operations, and take advantage of the newest capabilities across Microsoft Fabric. This release includes significant platform upgrades, including Apache Spark 4.1, Delta Lake 4.2, Python 3.13, Java 21, Scala 2.13, and Azure Linux 3.0, providing a modern and enterprise-ready foundation for the next generation of data engineering, data science, and analytics workloads. These enhancements enable customers to take advantage of the latest open-source innovations while continuing to benefit from a fully managed, enterprise-grade experience in Microsoft Fabric. Whether you're building data pipelines, developing AI and machine learning solutions, processing streaming workloads, or powering enterprise analytics, Runtime 2.0 provides a more capable, scalable, and performant platform for your workloads. With improved performance, updated open-source foundations, and continued investment in capabilities such as the Native Execution Engine, Runtime 2.0 provides a modern platform for data engineering, data science, and analytics workloads in Microsoft Fabric. Explore the full documentation and start using Runtime 2.0 in production Runtime 2.0 in Fabric. Enhanced Spark Properties Support in Notebook and Spark Job Definition Notebook and Spark Job Definition (SJD) activities now enable users to specify Spark properties directly within the data integration pipeline. This enhancement allows Spark properties to be set inside the activity panel, ensuring that the values provided are used for activity execution. If an Environment item is linked to the Notebook or SJD and both the activity panel and Environment item define the same property, the value specified in the activity panel will take precedence and overwrite the Environment value. In the case of Notebooks, if the %%configure command is used within the notebook code to set a Spark property, the value set using %%configure will be applied for execution. This update offers users maximum flexibility, allowing Spark properties to be defined at different layers based on their specific use cases. By supporting property configuration in the activity panel, Environment item, and notebook code, users can tailor property values to meet the unique requirements of each execution of Notebook/SJD. To learn more on Transform data by running notebook and Transform data by running a Spark Job Definition activity. Conversational Analytics Enhanced Data Agent Visualizations with Fabric Visuals The data agent now uses Fabric visuals to render the charts it returns, bringing higher-quality, more consistent visualizations into your conversations with your data. When you ask a question like "Generate a bar chart of revenue by region" or "Show me my top 10 customers by sales," the data agent responds with an interactive, polished visual alongside its text and table answers, so you can spot trends, comparisons, and outliers. Because the data agent now shares the same visual foundation as Fabric Apps, charts look and behave consistently with AI-generated visuals in Fabric, with refinements to formatting, legends, tooltips, and axis scaling. Supported chart types include line, bar, stacked bar, pie, scatter, and area charts. To learn more, refer to the Get visual responses from a Fabric data agent documentation. Advanced DAX Generation for Semantic Models in Data Agents Advanced DAX generation for Power BI semantic models is now available in Fabric data agents when you use the Preview runtime. Instead of generating a DAX query in a single pass, the new system works iteratively as a specialized sub-agent that can use tools, inspect results, and refine its approach across multiple steps, providing significant improvements in response accuracy. It also uses instance value indexing to resolve values from the semantic model before generating a query, resulting in more accurate and reliable filters. This update is built on the same semantic-model query engine used across Fabric Skills, Power BI, and M365 Copilot, providing more consistent answers across Microsoft experiences. To use the new experience, open the Runtime dropdown in the data agent ribbon and switch from Standard to Preview. More improvements for semantic models in data agents are coming soon, including data source description and instructions, granular schema selection, and example queries. In the Preview runtime, the data agent uses advanced DAX generation to answer a question over a connected semantic model, enabling more accurate DAX generation and responses. To learn more, refer to the Semantic model best practices for data agent documentation. Data Agent orchestrator upgraded to GPT 5.1 The data agent orchestrator now runs on GPT-5.1, across both the standard and preview runtimes. The orchestrator handles how questions are rephrased, how work is planned across your data sources, and how the final answer is composed — so this upgrade changes behavior in all three. Most of what you see should be an improvement in answer quality and planning, but the change is not behavior-neutral: prompts tuned against the previous model may produce different results. We recommend re-running your evaluations, reviewing the results against your saved baselines, and updating your agent instructions and prompts where the new behavior doesn't match what your scripts expect. To learn more, refer to the data agent runtimes documentation. Example Query Usability Improvements in Data Agent We've made several usability improvements, for example queries. Errors now surface inline, directly alongside the query, so you can identify and correct issues without leaving the editor. The editor also resizes automatically based on the length of your query, removing the need to adjust the pane manually as you write. To learn more, refer to the example queries in data agent documentation. Add Schema Descriptions for SQL Sources in Data Agent Users can now provide tailored schema descriptions through the new schema description editor, available for SQL sources on the Preview runtime. Schema descriptions improve query generation and accuracy by giving the agent more context about what everything in your data means — use them to resolve ambiguous columns, or to give a table or field a more precise meaning than its name conveys. Instead of inferring intent from column names alone, the agent works from what your data team documented, so it selects the right tables and interprets fields the way you intended. To learn more, refer to the schema descriptions documentation. Data Agent is migrating from Assistants API to Responses API The OpenAI Assistants API that powers the orchestration layer for the Microsoft Fabric data agent, is currently scheduled to be shut down by OpenAI on August 26, 2026. After that date, direct calls to the Assistants API will stop working. If you connect to a Fabric data agent programmatically through the Assistants API, you need to migrate to the data agent Model Context Protocol (MCP) endpoint. SDK and Fabric portal users require little or no action because Microsoft will migrate those experiences internally, although conversation history may reset once. Existing agent data sources, instructions, and tools remain unchanged. To learn more, refer to Prepare your Fabric Data Agent integrations for Assistants API retirement. Fabric Data Agents in Microsoft Copilot Studio (Generally Available) Now, you can bring governed business data from Microsoft Fabric into Copilot Studio agents, so those agents can answer questions and support business processes using trusted enterprise data. Since preview, the integration has moved to the new tool-based experience: select Add a tool, search for Fabric, and add Fabric IQ Data MCP, and your agent can call the Fabric data agent like any other tool. The Fabric data agent still runs in Fabric and respects permissions on the underlying data sources. You can also publish your agent to Microsoft Teams and Microsoft 365 Copilot, so business users get data-grounded answers where they already work. To learn more, refer to the Fabric Data Agent MCS GitHub documentation for setup steps and join the community discussion to share feedback. Fabric data agents in Microsoft Foundry: Easier to connect, easier to trust Fabric data agents in Microsoft Foundry are now easier to connect and easier to monitor. The integration moves to Model Context Protocol, so your Fabric data agents appear as tools that Foundry agents can invoke when they need enterprise data in OneLake. Connecting them no longer means hunting for workspace and artifact IDs. You add the Fabric IQ (OneLake Catalog) tool, filter for data agents, and pick the ones you want by name. You can also connect more than one Fabric data agent to a single Foundry agent, so an agent can draw on a sales agent, a supply chain agent, and a customer support agent and choose the right one for the question. On the operations side, you can now view logs and traces for Fabric data agents through Foundry Observability. Traces show which tools were invoked, how long each step took, and what came back, which makes it much easier to troubleshoot an answer that looks wrong or a workflow that runs slow. This is the visibility teams need to move agents from experiments to production. The update is rolling out to all regions over the coming days. Add Fabric data agent as part of Fabric IQ to your Foundry agent. To learn more, refer to the Observability for Fabric data agents in Microsoft Foundry documentation. Add co-publishers for data agents in Microsoft 365 Copilot When you publish a Fabric data agent to Microsoft 365 Copilot, the Microsoft 365 agent platform registers the agent and records you as its only owner. That created a problem for teams. Your co-creators could still edit the data agent in Fabric, but when they tried to republish it, the operation failed, because Microsoft 365 only lets registered owners publish. Fabric access and Microsoft 365 ownership are two separate lists, so giving someone edit rights in Fabric was never enough. Now, you can avoid this with co-publishers. After you publish the data agent, open Settings, go to the Publishing pane, and add your Fabric co-creators under Microsoft 365 Copilot co-publishers. Each person you add is registered as a co-owner on the Microsoft 365 agent platform, so anyone on that list can republish the agent. Add co-publishers right after your first publish so no one hits a failure in the meantime. Publishing pane in the Fabric data agent settings, showing where you add Microsoft 365 co-publishers. To learn more, refer to the Consume a data agent from Microsoft 365 Copilot (preview) documentation. Data Warehouse Identity columns with identity insert (Generally Available) Since preview, thousands of customers have adopted IDENTITY to auto-generate surrogate keys and streamline migrations from SQL Server, Azure SQL Database, and Azure Synapse. Now we're introducing support for IDENTITY_INSERT and reseed operations - two highly needed additions - so you can insert explicit key values, migrate data in bulk with COPY INTO, and safely realign identity ranges with DBCC CHECKIDENT. Figure: Using identity insert on Fabric Data Warehouse. IDENTITY columns are available now in every Fabric Data Warehouse. To learn more, check our updated tutorial and documentation. CI/CD 2.0 with DacFx (Preview) Microsoft Fabric Data Warehouse is introducing a major update to the DacFx engine that powers schema comparison, Git integration, and deployment pipelines. DacFx builds a declarative model of your warehouse and determines the schema changes required to move safely between development, test, and production environments. Git-integrated CI/CD workflow for Microsoft Fabric, showing feature workspace synchronization, branch merging, and deployment pipeline promotion across development, test, and production workspaces. With this update, Git integration uses DacFx-based incremental extraction to produce cleaner, more focused commits. Deployment pipelines also use the updated model to generate more accurate comparisons and smarter deployment plans, with settings tuned for schema evolution. The new warehouse item definition version 2.0 updates the SQL project SDK, moves shared queries into a .sharedqueries folder, adds project-level Git configuration, and re-extracts object definitions to support constraints, identity columns, clustering, and consistent formatting. These changes make future commits easier to review and reduce noisy diffs. For more information, refer to the Upgrade Fabric Data Warehouse System File Version in a Git Integrated Fabric workspace documentation. Microsoft Fabric source control notification prompting users to apply the latest Warehouse system update, with a warning that the update will introduce differences between the workspace and its connected Git repository. The update also improves comparison accuracy. Git-connected workspaces can adopt the update when ready through the System update available experience, giving teams control over upgrade timing. Review and commit the generated changes before continuing normal development and deployment workflows. To learn more, refer to the Development and Deployment Overview documentation. Simplify Fabric Warehouse deployments with Schema Compare in VS Code Database deployments should not feel like a guessing game. With Schema Compare in Visual Studio Code, developers can see exactly what changed before those changes reach a Fabric Warehouse—bringing clarity and control to every release. Compare a Fabric Warehouse with another warehouse or a SQL database project, then review differences across tables, views, stored procedures, functions, and other database objects in a clear, object-by-object view. Choose the changes you want, update the project from the warehouse, or deploy selected changes to the target—without manually assembling and reviewing every deployment script. By keeping database projects synchronized in Git, teams gain a reliable source of truth and can bring schema changes into familiar pull-request and CI/CD workflows. The result is a safer, more intentional path from development to production, with fewer surprises at deployment time. Before applying changes, review the generated script for unsupported operations and potential data loss. To learn more, refer to the Develop warehouse projects in Visual Studio Code and Schema Compare in the MSSQL extension documentation. GPU Query Acceleration (Preview) Query Acceleration brings GPU-powered performance directly to Fabric Data Warehouse, enabling eligible analytical queries to run faster without query rewrites, special syntax, or additional systems to manage. Query Acceleration in Fabric Data Warehouse uses GPUs to accelerate the most compute-intensive portions of analytical queries, helping overcome the limits of CPU-only execution. It works transparently with existing T-SQL, Direct Query reports, applications, and tools, automatically offloading eligible operations such as scans, filters, joins, and aggregations to GPUs while the CPU continues to manage the rest of the execution pipeline. Customers can use Query Insights, Data Warehouse Monitoring, and SQL Server Management Studio (SSMS) for query execution plans to identify accelerated queries and understand how Query Acceleration is applied during query execution. Designed for analytical and high-concurrency workloads, Query Acceleration can improve throughput, reduce query latency, and deliver more consistent performance for dashboards and interactive analytics. Acceleration is applied selectively, enabling performance gains even when only part of a query is eligible for GPU execution. The capability is built with reliability in mind. Unsupported operations or runtime constraints can seamlessly fall back to CPU execution without affecting query correctness. Performance improvements depend on workload characteristics, but Microsoft benchmarks have demonstrated gains of up to 7× across reporting, application, and AI-driven analytics scenarios. Query Acceleration builds on Microsoft's Tensor Query Processor research, described in CoddSpeed: Hardware Accelerated Query Processing in Microsoft Fabric, which was selected as the SIGMOD Companion 2026 Best Industry Paper. To sign up for the Preview, please fill out the form. Metadata Sync supports Delta Checkpoint V2 (Generally Available) Metadata Sync (MD Sync) now supports Delta Checkpoint V2, enabling synchronization of modern Delta tables across both MD Sync (Legacy) and MD Sync (New). Delta Checkpoint V2 is a Delta Lake enhancement designed to improve scalability for large tables through a more efficient checkpoint structure. Previously, tables using Checkpoint V2 couldn't be synchronized and were reported as unsupported. With this release, MD Sync can discover and synchronize Delta tables that use the Checkpoint V2 format. This enhancement helps customers: Synchronize Delta tables that use Checkpoint V2. Improve interoperability with Spark, Databricks, and other Delta-based platforms. Support metadata synchronization for large-scale Delta tables more efficiently. Continue using existing checkpoint formats without any changes. MD Sync support for Delta Checkpoint V2 is available in both MD Sync (Legacy) and MD Sync (New), helping ensure consistent access to Delta tables across Fabric experiences. Secure data ingestion with COPY INTO and Workspace Identity (Generally Available) COPY INTO in Fabric Data Warehouse now supports Workspace Identity, enabling users to load approved data from OneLake or ADLS Gen2 without requiring direct access to the source files. Previously, ingestion users often needed permissions to both the target warehouse and the source storage location, or teams relied on SAS tokens, account keys, or service principals. With this release, source access can be centrally assigned to the workspace identity, while users retain only the SQL permissions required to load data into the target table. Key Capabilities: Load approved data without granting users direct access to raw storage. Use managed identity-based authentication for OneLake and ADLS Gen2 sources. Reduce reliance on SAS tokens, shared keys, and service principal secrets. Maintain separate authorization boundaries for source access and target-table permissions. Support least-privilege ingestion and separation of duties between storage and warehouse administrators. Workspace Identity support for COPY INTO is generally available in Fabric Data Warehouse, providing a simpler and more governed approach to secure data ingestion. To learn more, refer to the Ingest Data into Your Warehouse Using the COPY Statement and COPY INTO (Transact-SQL) documentation. SQL Audit Logs: More Signal, Less Noise with Predicate Filtering (Generally Available) SQL Audit Logs in Fabric Data Warehouse and SQL Analytics Endpoint now support identity-based predicate exclusion filtering, enabling administrators to reduce repetitive audit events generated by selected users and service principals. Previously, expected activity from automation identities, scheduled processes, metadata synchronization jobs, and other operational actors could create significant audit noise. With this release, administrators can configure exclusions through the API or SQL Audit Logs user experience, while activity from identities that do not match the exclusion predicate continues to be audited normally. Key Capabilities: Reduce repetitive audit events from known users and service principals. Focus investigations on higher-value and unexpected activity. Lower the storage, processing, export, and query burden associated with low-value events. Manage identity exclusions through either automated APIs or the user experience. Apply a governed audit policy aligned with organizational monitoring and compliance requirements. Identity-based predicate exclusion filtering is generally available for SQL Audit Logs in Fabric Data Warehouse and SQL Analytics Endpoint, providing a cleaner audit stream, less operational overhead, and more focused investigations. To learn more, refer to the SQL Audit Logs in Fabric Data Warehouse documentation. OneLake security improvements for SQL analytics endpoints (Generally Available) OneLake Security for SQL analytics endpoints now includes improvements for nested groups, shortcut-backed tables, column-level security, and service principals, enabling more consistent enforcement of OneLake security policies across enterprise Fabric environments. Previously, limitations with group expansion, shortcut scenarios, and service principal ownership could make centralized security difficult to apply at scale. With these improvements, customers can define security at the source lakehouse and rely on the SQL analytics endpoint to honor those policies across producer and consumer workspaces. Key Capabilities: Manage access through nested Microsoft Entra group hierarchies. Honor source-side OneLake Security policies for shortcut-backed tables in hub-and-spoke architectures. Apply column-level security consistently when users receive access through groups. Use service principals for automated deployments, pipelines, and application-owned data products, including service principal-owned lakehouses. Define security once in OneLake and reduce the need to duplicate permissions across consumer workspaces and Fabric engines. These OneLake Security improvements help make security synchronization more practical for enterprise architectures while providing consistent access control across lakehouses and SQL analytics endpoints. Microsoft is also continuing to improve security sync notifications, error handling, and permission propagation across Fabric experiences. To learn more, refer to the OneLake Security for SQL analytics endpoints documentation. Real-Time Intelligence Set Alerts Directly from Anomaly Detector (Generally Available) Detecting anomalies becomes more valuable if you can act on them. Previously, after publishing an anomaly detector configuration, you had to leave Anomaly Detector and navigate to Real-Time Hub to create an alert. This added extra steps and interrupted your workflow right after completing your configuration. With this update, you can now create alerts directly from Anomaly Detector. Once you publish a configuration, use the Set alert button in the ribbon to launch the alert creation pane without leaving Anomaly detector. If your configuration hasn't been published yet, you'll be guided through publishing first and then taken directly to the alert setup experience. This helps you move seamlessly from configuring anomaly detection to monitoring it in production. The integrated experience allows you to monitor your anomalies on each event, helping you get notified as soon as anomalies are detected. If you have more complex business logic, select on each event when to add in additional logic to your conditions. Whether you're monitoring operational metrics, business KPIs, or real-time telemetry, you can now complete the entire workflow in one place and start acting on detected anomalies faster with fewer clicks. Create alerts directly from your anomaly detector configuration and continue your workflow without navigating to another experience. Configure notifications for anomaly detector events directly within Anomaly Detector and start monitoring your published configuration immediately. Anomaly detector supports Eventhouse shortcut tables Anomaly Detector now supports Eventhouse shortcut tables, making it possible to analyze data without first copying or moving it into a dedicated Eventhouse table. You can create anomaly detectors directly on supported shortcut tables and use the same analysis, model recommendations, and continuous monitoring experiences available for native Eventhouse data sources. This expands anomaly detection to a broader range of data already connected through Eventhouse shortcuts, helping teams monitor external and federated data sources with less setup and duplication. By enabling anomaly detection directly on shortcut tables, you can move more quickly from connecting data to detecting issues, while continuing to work within a unified Real-Time Intelligence experience. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Operations Agent Activity Log Understanding what your agent is doing and why is key to building trust and improving outcomes. The activity log is designed to provide that transparency. It gives you a clear view into the agent’s behavior, including the conditions it evaluated, the recommendations it generated, and how those recommendations were handled. Whether you are validating results, troubleshooting unexpected behavior, or refining your configuration, the activity log helps you better understand how decisions are being made. You can access the activity log from the Activity log section in the side navigation. It presents a chronological timeline of events with timestamps and relevant context for each entry. Selecting any event allows you to explore additional details and understand what happened at each step. In the Operation details page, you can view the operation details and status. To learn more, refer to the Create and Configure Operations Agents documentation. Eventstream MQTT connector (Generally Available) It is now easier than ever to ingest real-time data from MQTT brokers directly into Microsoft Fabric Real-Time Intelligence. MQTT is one of the most widely adopted messaging protocols for lightweight, low-bandwidth event driven messaging scenarios. Eventstream MQTT connector simplifies the ingestion of operational and IoT data into Microsoft Fabric, helping organizations turn real-time device events into actionable insights. Key Benefits: Connect to any MQTT broker and ingest messages directly into Fabric Eventstream. Production-ready reliability and support with General Availability readiness. Enterprise-grade security with support for TLS, mutual TLS (mTLS), and custom certificate authorities managed through Azure Key Vault. Private network connectivity through Eventstream's streaming connector virtual network capabilities, enabling secure access to brokers hosted in private and on-premises environments. To learn more, refer to the Add MQTT source to an eventstream documentation. Reference data enrichment in Eventstream (Preview) Eventstream now enables you to enrich real-time event streams with contextual business data using Reference Data Join. Simply add a Reference Data node to your Eventstream, select a Delta table from a Fabric Lakehouse, and use it to enrich streaming events with lookup, metadata, or reference information. You can also leverage Lakehouse shortcuts to access Delta tables across OneLake, making it easy to bring contextual data from anywhere in your Fabric environment into your real-time processing pipelines. Reference Data Join supports both no-code and SQL-based enrichment experiences. Use the built-in Join operator to visually configure INNER and LEFT OUTER joins or use the SQL operator for advanced scenarios. Select only the columns you need from the reference dataset and configure optional refresh intervals to keep slowly changing reference data up to date. This enables Eventstream to continuously use the latest lookup information for real-time enrichment, without requiring additional data movement or downstream processing pipelines. You can easily add multiple reference data sources to a single Eventstream and combine them with streaming data to create richer, more contextual event pipelines. Developers and data engineers can test and validate join conditions, preview join results, and verify SQL-based enrichment queries before deploying them into production, helping ensure accuracy and confidence in real-time data processing workflows. Reference Data Join unlocks powerful real-time enrichment scenarios in Eventstream. Users can enrich IoT telemetry with device metadata, correlate operational events with customer and product information, perform lookups against business reference datasets, and add contextual information to streaming data in flight. By bringing reference data and event processing together in a single experience, Eventstream enables customers to transform raw events into actionable business insights in real time. To learn more, refer to the Reference data join in Eventstream using Lakehouse documentation. Eventstream observability in Workspace Monitoring re-enabled with per-Eventstream control (Preview) Eventstream observability in Workspace Monitoring is back — now with granular control over which Eventstreams emit monitoring data. A new ‘Log Eventstream activity’ toggle in Eventstream Settings lets you enable or disable observability per Eventstream, so you can balance monitoring coverage with capacity consumption. When enabled, your Eventstream emits performance metrics, error counts, and health status to three tables in your Workspace Monitoring Eventhouse: EventStreamMetrics: throughput, backlog, and watermark delay EventStreamErrorMetrics: deserialization, conversion, and runtime error counts EventStreamNodeStatus: node health (Running / Failed) The toggle defaults to OFF for all Eventstreams. To get started, open any Eventstream, go to Settings, and turn on Log Eventstream activity. Your monitoring data will appear in the Workspace Monitoring database within minutes. Eventstream activity" within Monitoring. The panel highlights an active toggle switch, a description explaining that enabling this feature emits performance and error metrics to a monitoring database. To learn more, refer to the Monitor Eventstream data flows in Workspace Monitoring documentation. Eventstream UI editor improvements (Preview) We've redesigned key parts of the Eventstream editor to make building and troubleshooting faster and more intuitive. Always Publish: No more blocked publish buttons. Publish your work at any stage, the editor gives you clear, contextual guidance on what still needs attention instead of preventing you from moving forward. Inline error indicators: Errors now appear directly on the node that needs fixing, with actionable guidance on click. No more hunting through a detached error list to find what's broken. Operator and destination descriptions: Each option now includes an inline description explaining what it does, so you can build confidently without switching to docs. These changes reduce friction during authoring and make it easier to go from idea to running your pipelines. Secure Azure Event Hubs Connections in Eventstream with Workspace Identity (Preview) Bringing real time event data into Microsoft Fabric is now simpler and more secure with Azure Event Hubs integration for Eventstream. Organizations can connect Event Hubs directly to Eventstream and start routing event data to destinations such as Eventhouse for analytics and operational insights. A key capability is Workspace Identity, which removes the need to manage shared access keys. Instead, Eventstream can authenticate to Azure Event Hubs using the Fabric workspace identity. Administrators simply grant the workspace the Azure Event Hubs Data Receiver role, enabling secure access through Microsoft Entra based permissions. This approach improves security, simplifies credential management, and aligns with enterprise governance requirements. The integration supports both public and private network deployments. For Event Hubs hosted in private networks, organizations can connect through a streaming virtual network gateway while continuing to use Workspace Identity for authentication. For advanced event processing scenarios, users can enable schema support, associate schemas from the event schema registry, and route structured events to destinations such as Eventhouse. Combined with Workspace Identity, this provides a secure and scalable foundation for building real time data pipelines without the operational overhead of managing secrets or credentials. Schema Registry and Event SchemaSet Region Availability Previously, Schema Registry feature and the Event SchemaSet artifact was available for preview in 31 regions. Expanded to 10 additional regions: Geography Region Americas Central US Americas Mexico Central Americas West US 3 Europe Italy North Europe Poland Central Europe Spain Central Europe West Europe Asia Pacific Australia Southeast Asia Pacific Israel Central Asia Pacific Japan West If you were previously blocked from trying SchemaSets and schema-based Eventstream data ingestion, you can now do so in these regions. For more information on Event SchemaSets and how you can create and manage them, visit Schema Registry Overview. To learn more about configuring Eventstreams with schema-based sources, visit Use schemas in Eventstreams. Data-driven styling and UX improvements for Maps (Generally Available) Maps become most valuable when they help users understand not just where things are, but what the data means. Now, Data-Driven Styling, along with Markers Rotate by Data, Traffic Flow visualization, additional Map View options, and an improved Layer Settings experience. Together, these enhancements help organizations transform raw geospatial data into intuitive, actionable business insights. Let Your Data Tell the Story Understanding patterns hidden within geographic data can be challenging when every feature on a map looks the same. With Data-Driven Styling, Fabric Maps enables map builders to visually represent business data directly on the map, helping viewers quickly identify trends, hotspots, and outliers without inspecting individual records. The new Color by Value Range capability allows authors to style map layers using numeric measures such as revenue, utilization, sensor readings, environmental measurements, or operational KPIs. Instead of applying a single color to an entire layer, Fabric Maps visualizes value distributions chromatically, making important differences immediately visible. Organizations can choose between two visualization approaches: Gradient Styling uses continuous color transitions to reveal magnitude, trends, and geographic variation across a dataset. Step-Based Styling allows users to define custom value ranges with distinct colors, making it easy to visualize business thresholds, risk levels, performance bands, or service categories. To make these visualizations easier to interpret, Fabric Maps automatically generates corresponding data legends that explain how colors map to underlying values. This helps viewers understand the meaning behind the visualization and make decisions with greater confidence. Fabric Maps also includes thoughtfully designed color palettes, including options that support colorblind-friendly visualization scenarios, helping more users accurately interpret map-based insights. Combined with clear, automatically generated legends, these capabilities improve accessibility and make data-driven maps easier to understand across a wider range of audiences. per street and road and high-value exposure in flood-prone areas. Visualize Direction and Movement with Markers Rotate by Data Many operational scenarios involve not only location but also direction. Fabric Maps now supports Markers Rotate by Data, allowing marker symbols to automatically rotate based on values stored in a data column. This capability is available for Marker layers, enabling builders to visualize directional information directly on the map. Whether visualizing aircraft headings, vehicle movements, equipment orientation, or other operational workflows, map authors can represent direction without requiring custom visualization development. By transforming static points into directional indicators, organizations can add valuable operational context and communicate movement patterns more effectively. Add Real-World Context with Traffic Flow Visualization Location data alone doesn't always tell the full story. Fabric Maps now supports Traffic Flow overlays, allowing map builders to bring current traffic conditions into their existing map experiences. By combining business data with real-world traffic information, organizations can gain additional situational awareness for logistics operations, field service planning, transportation monitoring, and operational decision-making. The added context helps users better understand the environment surrounding their assets and activities without leaving the map experience. Configure the Right Map View for Your Audience Organizations often create maps for users across different regions and business contexts. Fabric Maps introduces additional Map View settings that allow map builders to configure how geographic information is presented, helping ensure maps are displayed in a way that aligns with organizational needs and audience expectations. This flexibility gives authors greater control over creating a consistent and intuitive viewing experience across a variety of business scenarios. A More Discoverable Authoring Experience UX research and user feedback showed that some key layer settings were difficult to discover. We updated the experience by moving geometry and visualization options—including visual type, Data-Driven Styling, and marker rotation—higher in the configuration pane. We also renamed General to Visibility, making the settings clearer and map authoring more intuitive. Turn Location Data into Business Insight Data-Driven Styling, built-in data legends, Markers Rotate by Data, Traffic Flow overlays, enhanced Map View options, and the improved Layer Settings experience help organizations transform location data into meaningful business insight. Together, these capabilities make it easier to uncover patterns, understand operational context, and communicate geospatial insights across teams. Start building with these capabilities today: explore the customization options, apply them to your own geospatial data, and create map experiences that turn location into action. To learn more, refer to the Customize a map in Microsoft Fabric documentation. Workspace Outbound Access Protection (OAP) for Operations Agent (Preview) Workspace Outbound Access Protection (OAP) in Microsoft Fabric helps admins secure outbound connections from workspace items to external resources. Admins can control outbound access by blocking unwanted connections by default and allowing only approved connections through configured rules. As organizations adopt AI-powered operations at scale, governance and security remain critical requirements. With this preview release, Microsoft Fabric introduces Outbound Access Protection (OAP) for Operations Agent, enabling workspace administrators to control the outbound actions an agent can perform. OAP applies workspace-level policies to actions such as Teams notifications, workflow triggers, and cross-workspace operations, helping organizations enforce security and compliance requirements while continuing to benefit from AI-driven automation. When OAP is enabled, Operations Agent continues to perform core functions including reasoning, recommendation generation, rule evaluation, and telemetry collection. However, outbound actions are governed by the workspace's configured access policies. Administrators gain greater visibility through in-product notifications, Teams messaging experiences, and the Operations Agent Activity Log, making it easier to identify and troubleshoot blocked actions What's new with Operations Agent and OAP? Govern outbound agent actions through workspace-level OAP policies. Control whether Operations Agent can send Teams notifications based on allowed connections. Prevent unauthorized cross-workspace actions when OAP policies restrict outbound access. Receive clear visibility when actions are blocked through in-product notifications and Teams messaging experiences. Monitor agent activity and OAP-related outcomes through the Operations Agent Activity Log. During the preview, some limitations apply. Cross-workspace actions are blocked when OAP is enabled. For example, Power Automate actions are not yet supported when OAP is applied, and only connectors that explicitly support OAP policies can be permitted. By extending Fabric's outbound governance framework to Operations Agent, organizations can adopt AI-powered operational automation with greater confidence while maintaining control over how and where agent-initiated actions are executed. Resources Workspace outbound access protection for operations agent (preview) Workspace Outbound Access Protection (OAP) Workspace Outbound Access Protection for Operations Agents Configure and manage Activator rules directly in Eventstream (Generally Available) You can now create and manage rules directly in Eventstream. Previously, setting up an alert required switching from Eventstream to Activator. While powerful, this meant moving between experiences to complete a single workflow. Now, alert creation is embedded directly into Eventstream. Capabilities for building or editing your Eventstream: Select the stream you want to monitor. Choose Set Alert. Define your condition (thresholds, aggregations, patterns). Configure the action. Create the rule. Capabilities for Activator destination created on Eventstream: Select Activator node Select Rule icon Create the rule Once you have the rule(s) created on your Eventstream, you can manage them by editing, deleting or opening in Activator. To learn more, refer to the Add a Fabric activator destination to an eventstream documentation. Data Factory Introducing Hierarchical Navigation in Monitoring Hub for Fabric Pipelines Modern data estates rarely consist of a single job running in isolation. Pipelines trigger notebooks, notebooks invoke other workloads, and business processes span multiple interconnected executions. When troubleshooting a failure or understanding lineage, customers often need visibility into how these executions relate to one another. Hierarchical Navigation in Monitoring Hub, is a new capability that helps you understand the relationships between runs and quickly navigate across upstream and downstream executions. With Hierarchical Navigation enabled, Monitoring Hub can display: Upstream runs that initiated a workload Downstream runs triggered by a workload Execution relationships across supported Fabric artifacts This provides a richer observability experience by helping you move beyond individual run monitoring and understand how your workloads operate together. This enhancement is another step toward a richer observability experience in Fabric, helping customers gain deeper insight into workload execution and dependencies at scale. To learn more, refer to the Hierarchical Navigation for Pipelines in Monitoring Hub documentation. Explore the modern Fabric Pipeline canvas (Preview) The new Fabric Pipeline canvas experience is designed to make pipeline authoring easier than ever. Key capabilities with modern canvas: Better visibility when navigating large pipeline graphs Cleaner, more structured layouts for complex orchestration logic Improved responsiveness when working with enterprise-scale workflows A more intuitive experience for pipelines with many activities and branches The modern Fabric Pipeline canvas, showing the updated node experience and option to disable the preview if needed. If you haven't tried it yet, now's the perfect time. The new experience is rolled out automatically and can be disabled at any time. Whether you're building your first pipeline or managing hundreds of activities across complex workflows, the new canvas is designed to help you stay productive and focused on what matters most. To learn more, refer to the Modern Pipeline Node Experience documentation. Upgrade Dataflow Gen1 to Dataflow Gen2 (CI/CD) using the Upgrade Wizard (Preview) The Dataflows Upgrade Wizard is a guided, end-to-end experience that upgrades your existing Power BI Dataflow Gen1 items to Dataflow Gen2 (CI/CD) in Microsoft Fabric with minimal effort. You can upgrade a single dataflow, or several dataflows from a workspace in a single flow. Previously, bringing a Gen1 dataflow into Fabric meant recreating it and repointing everything that depended on it. The Upgrade Wizard upgrades in place instead. Each dataflow keeps its ID, name, schedule, and connections, so the reports and semantic models that connect to it keep working without any changes. Before anything changes, the wizard assesses every dataflow in the workspace and tells you which ones need attention and why, such as incremental refresh settings to reconfigure or a linked entity to update, so you know what to expect before you upgrade. Why this matters Upgrade in place, with nothing to rebuild and nothing to repoint. Upgrade a whole workspace at once instead of one dataflow at a time. See what needs attention before you upgrade. Unlock Dataflow Gen2 innovations: improved performance, deeper Fabric integration, CI/CD and Git support, data destinations of your choice, richer diagnostics, Copilot-assisted authoring, and a modern data transformation foundation. The wizard is available for Dataflow Gen1 items in Premium or Fabric workspaces and requires Fabric to be enabled. To learn more, refer to the Upgrade Dataflow Gen1 to Dataflow Gen2 (CI/CD) using the Upgrade Wizard documentation. Extended watermark support in Copy job Watermark-based incremental load support enables Copy Job to efficiently ingest only new or changed data from key enterprise and SaaS data sources, avoiding costly full reloads. This reduces source-system impact, network traffic, and runtime while improving scalability for production analytics workloads. Customers can now use incremental loading across more of their critical data sources, including Salesforce, Informix, Cassandra, Greenplum, Presto, and Databricks, by leveraging Copy job’s built-in watermark mechanism and without building custom ingestion logic. To learn more, refer to the Incremental copy in Copy job documentation. Enable Change data feed during Lakehouse table creation in Copy job Copy job can now create Lakehouse tables with Change Data Feed (CDF) enabled automatically. There’s no longer a need to pre-create destination tables or manually configure Delta table properties. Simply select Enable CDF on destination and Copy job takes care of the setup for you. This ensures the table is immediately ready for incremental processing and downstream CDC scenarios, helping reduce data movement and improve replication efficiency. By eliminating manual configuration steps, it makes advanced data integration patterns much easier to adopt and operate at scale. To learn more, refer to the Automatic table creation and truncation on destination documentation. Amazon Redshift as new source in Copy job As part of our mission to enable multi-cloud data movement at petabyte scale with Copy job, we are bringing Amazon Redshift support as a source. This enables customers to seamlessly ingest data from one of AWS's most widely adopted data warehouse platforms directly into Fabric. Redshift support further strengthens Fabric's vision of delivering an open, connected, and multi-cloud data platform. To learn more, refer to the Connectors for Copy Job documentation. Copy job supports timestamps without time zone in Lakehouse Support for timestamps without time zones (timestamp_ntz) allows Fabric Lakehouse tables to preserve date and time values exactly as stored, without applying time zone conversions. Copy job can now automatically map timezone-independent datetime values to Delta Lake timestamp_ntz, ensuring greater compatibility with source systems that allow storing date and time values without time zone information. Migration Assistant for SQL database in Fabric (Generally Available) The guided, Fabric-native wizard takes you from a source SQL Server schema to a running SQL database in Fabric: upload a DACPAC, review compatibility results, deploy the schema with Copilot-assisted fix suggestions, and copy your data using built-in Fabric Copy Jobs. We've added the capability preview customers asked for most: Validate. You can now check out a DACPAC for compatibility before creating a SQL database in Fabric. Upload the file and the assistant reports which schema objects will deploy cleanly, which ones use features that aren't supported, the reason behind each failure, and the dependencies between objects — with nothing provisioned and no capacity consumed. That means you can scope migration effort, plan remediation, and get change-approval sign-off before you commit to a target database. To get started, select Migrate in your Fabric workspace and choose Migrate to SQL database in Fabric. To learn more, refer to the Fabric Migration Assistant documentation. Until next month That's a wrap for the August 2026 Microsoft Fabric Monthly Update. As always, we'll continue sharing new capabilities, enhancements, and improvements across Microsoft Fabric in future monthly updates. Thank you for being part of the Fabric community!
