Modern Power BI architecture choices for reporting on Azure Databricks: A performance benchmark for Power BI storage modes
Many enterprise Power BI semantic models use Azure Databricks as a data source. When building these models, developers and architects face an early and consequential decision: which storage mode to use. Cost, security, and ease of development and tuning all factor in — but report performance is probably the most important of them, because reports that are slow to load are one of the most common causes of end-user dissatisfaction. In practice, that decision is often made on intuition rather than evidence. To help change that, we've published a new white paper, Modern Power BI Architecture Choices for Reporting on Azure Databricks, benchmarking four ways of serving the same Delta tables to a Power BI report: Direct Lake on OneLake — over Delta tables in a Fabric lakehouse or warehouse Direct Lake on mirrored Unity Catalog tables — shortcuts, no copy DirectQuery — on a Databricks SQL warehouse Composite Model on Databricks — DirectQuery combined with Import-mode aggregations Figure: The four Power BI storage modes benchmarked to evaluate their impact on report performance and scalability. What the results suggest: there's no universal winner — but there are clear patterns. Direct Lake on OneLake performed well across the widest range of situations in this benchmark. It's highly competitive at smaller and mid-size volumes, and for the typical Power BI workload — where reports are used repeatedly throughout the day — it delivers interactive performance without extra modeling effort. At the top end of the volume curve, the picture shifts. With billions of rows, a Composite Model with aggregations was the fastest and most consistent pattern, staying sub-100ms on queries the aggregation tables can resolve. The caveat is equally clear: that advantage doesn't extend to queries that fall through to the underlying DirectQuery source, so the payoff depends on how well your aggregations match real user behavior. These are just the headline findings — the detailed results vary considerably by data volume, cache state, filter scenario, and query type. We'd encourage you to read the white paper for the full picture before deciding on a pattern. One thing worth noting up front: this is a point-in-time comparison as of June/July 2026, and both platforms are moving quickly. It also measures the end-user query experience within Power BI, rather than raw database execution speed. Treat it as a guide for running your own testing, on your own data. Explore the white paper for a full walkthrough of through each pattern in detail — the test setup, what was measured, and how results break down by data volume, cache state, and query type. Visit the Power BI download center to access the paper and other related resources.Fabric September 2026 Feature Summary
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. Welcome to the September 2026 Fabric Feature Summary! As the Microsoft Fabric community gathers in Barcelona for the European Microsoft Fabric + SQL Community Conference, this month brings one of our biggest updates yet. From governance, CI/CD, and data engineering enhancements to AI-powered experiences, analytics, data integration, real-time intelligence, and Fabric IQ innovations, we're sharing the latest capabilities designed to help organizations build, manage, and scale their data estate with confidence. Whether you're joining us in person or following along from afar, this roundup is your guide to everything new across Microsoft Fabric this month. Fabric Platform Policies in Fabric (Preview) As Fabric adoption grows, broad tenant switches can force admins to enable a capability for everyone or restrict it for everyone. Fabric Policies provide a more precise option: define who may perform an action, what the rule covers, and where it applies. For organizations applying least privilege, this means preserving self-service without extending sensitive capabilities across the organization. Policies are stored in Policy Set Fabric items and managed through the Policies Center in OneLake Catalog, public APIs, and CI/CD. Available policy types and conditions Policies evaluate contextual conditions when a user attempts an action. Conditions within a rule use AND logic, and rules use OR logic: a user must match every condition in at least one rule. If no policy rule matches, the action is denied. Supported operators include AnyOf and NoneOf. Item Creation Policy: capacity scope gives capacity administrators granular control over who can create specific Fabric item types in workspaces assigned to their capacity. Conditions can target the item type, user or security group, and workspace. Edit Workspace Settings Policy: tenant scope gives Fabric administrators granular control over who can modify security-sensitive workspace settings, without removing broader workspace administration capabilities. Organizations can define which users are authorized to manage settings such as network security and customer-managed keys, helping reduce compliance risk while enabling self-service at scale. The policy allows tenant admins to delegate workspace management confidently, striking the right balance between agility and governance. External Data Sharing Policy: tenant scope: gives Fabric administrators granular control over who can share data externally, from which workspaces, for items with selected sensitivity labels, and specified recipient email domains. Examples Allow Dataflow Gen2 creation A capacity admin selects Item creation > Advanced and creates an Allow rule where Item type is Dataflow Gen2 and only in Workspace ‘Finance Data’, optionally limited to selected security groups. Other item types must be added to this rule or explicitly allowed by another rule; otherwise, their creation is denied. Existing workspace access requirements still apply. Figure: Policies in Fabric – Policy rule examples. Public APIs and auditing Public REST APIs support Policy Set and policy rule CRUD, listing, and activation or deactivation. Policy rule definitions support Fabric CI/CD with Git integration. Policy Set and policy rule lifecycle operations, including activation and deactivation, are recorded in the Microsoft 365 Audit Log and surfaced through Microsoft Purview Audit and APIs. Important to know Hosting and enforcement can use different capacities. A policy set can be hosted on one capacity and enforce policies on another. To learn more, refer to the Policies in Fabric (Preview) documentation. Fabric CI/CD - Deployment Plan (Preview) Deployment plan is a new Fabric workspace item that gives you explicit control over how related items are deployed across environments. Using a visual canvas, you can organize items into ordered sets and add actions that run before or after deployment. Fabric normally determines deployment order from item dependencies. A deployment plan lets you extend that behavior when your solution has dependencies Fabric cannot automatically detect, or when an item must be deployed and run before another item can be deployed successfully. Why this matters Deploy related Fabric items in a predictable, repeatable order. Run notebooks, data pipelines, copy jobs, Dataflow Gen2 items, and data functions as part of the deployment. Handle application dependencies that are not represented by Fabric lineage. Use the same deployment intent across Git integration and deployment pipelines. For example, you can deploy a lakehouse, deploy and run a notebook that prepares its data, and only then deploy a warehouse that depends on the resulting tables. If an action or deployment fails, the plan stops before continuing to dependent items. This makes failures easier to identify and prevents incomplete deployments from progressing. Figure: Deployment plan canvas with ordered deployment sets and actions. To learn more, refer to the Plan CI/CD for Microsoft Fabric Solutions documentation. Restrict access to sensitive data with data loss prevention policies (Generally Available) DLP Restrict Access in Microsoft Fabric helps organizations automatically protect sensitive data by enforcing access controls when Microsoft Purview DLP policies detect sensitive information. Instead of only alerting administrators, this action can automatically restrict access to affected Fabric items for guest users or all users, helping reduce the risk of data leakage, oversharing, and non-compliant data exposure. This capability is especially valuable for regulated industries such as financial services and healthcare, where identifying sensitive data is not enough, and organizations must actively control who can access it. Combined with policy tips, alerts, audit trails, and remediation workflows, DLP Restrict Access enables organizations to confidently adopt Fabric for analytics and AI while maintaining strong security and compliance controls. When configuring DLP policy rules in Purview, admins can add an action that restricts access to all users or to guest users once sensitive data is detected within the item. Workspace admins will always retain access to fix the data where necessary. Figure: DLP policies restrict access policy tips on a Fabric Lakehouse, showing the type of restriction and detected PII type. Refer to the Restrict access action for DLP policies in Fabric documentation to learn more. Browse and explore objects in OneLake Catalog Object browsing in OneLake Catalog helps users discover and understand data at a more granular level. Instead of opening individual Fabric items and navigating through different experiences, users can browse their underlying objects, including schemas and tables, directly from the catalog. This capability makes it easier to understand how data is structured, locate the specific asset needed, and determine whether it is the right data for a particular scenario. By bringing item- and object-level discovery together, OneLake Catalog enables faster exploration and more confident reuse of data across the organization. Users can expand and collapse supported items to navigate their objects in a clear tree structure. Clicking an object opens its details page, where users can explore additional metadata, take available actions, and preview the data—all without opening the underlying Fabric item or switching experiences. Figure: Browse schemas and tables within a Fabric item and preview an object’s data in OneLake Catalog. To learn more, refer to the OneLake Catalog Overview documentation. Discover tables and more with the improved OneLake Catalog Search API (Preview) Reach deeper into Microsoft Fabric data and get more complete, contextual search results with the OneLake Search API. With this release, you can find more types of data objects, refine searches with new filters and operators, and use richer metadata to help you choose the right result. The API is agent ready, you can access the API through remote and local MCP servers or use it as a skill from the Fabric Skills library in GitHub Copilot and other compatible AI coding tools. This makes it easier to bring OneLake Catalog discovery into agentic workflows and natural-language development experiences. Tables are now first-class search results The OneLake Catalog Search API now supports table-level discovery across Semantic Models, Lakehouses, and Mirrored Databases. Search by table name, column name, or description and receive each table as a standalone result, making it easier to find the exact data you need without navigating through parent items first. Table visibility follows the permissions on the parent item: You can discover a table only if you have Read permission or higher on its parent. Data-plane permissions like OneLake Security do not affect catalog discoverability. However, tables in semantic models protected by object-level security (OLS) are currently excluded from search for all users. Fabric administrators can turn off object discovery for their organization by disabling the "Users can find objects in search" tenant setting. When disabled, search results include only top-level Fabric items. Figure: Tenant Setting allowing Admins to disable the object-level search. Tables are the focus of this release, but they’re only the beginning. We plan to support tables from more Microsoft Fabric item types, along with additional object types, as OneLake Catalog expands beyond item-level discovery. Richer metadata, new filters and broader coverage New filters and expanded metadata make search results more precise and useful. Return and filter results by endorsement status, workspace ID, and sensitivity label ID. Find dataflows and dashboards in search results. Identify reports and dashboards included in a workspace app and retrieve the relevant app context. Refine searches with new operators New query syntax gives you more control over how search terms are interpreted: Use quotation marks (" ") to search for an exact phrase. Use an asterisk (*) as a wildcard for multiple characters. Use a question mark (?) as a wildcard for a single character. Use double ampersands (&&) to return only results that contain all specified terms. Together, these enhancements make it easier to build richer discovery experiences, refine results using governance and workspace metadata, and get the context you need to choose the right item or object. To learn more, refer to the full API documentation. Find the right data faster with the new Global Search experience The enhanced Global Search experience helps you find the right data across Fabric and Power BI faster, with more precise and comprehensive results. Built on OneLake Catalog’s new search foundation, Global Search delivers more relevant results for each query, helping users quickly find the assets they need from anywhere in Fabric. The search results page has also been redesigned to display results as visual cards rather than a list. Each card surfaces key metadata and provides clearer context about why the result matches the query, making it easier to compare results and identify the right asset. Users can further refine the results using filters, then open an item’s details page in OneLake Catalog to explore additional context and act. With a single selection, users can continue their search in Fabric Copilot, where they can ask follow-up questions, refine their search through conversation, and further explore relevant data. Global Search now goes beyond top-level Fabric items, enabling users to search for and discover supported objects within items they have permission to access. This more granular discovery experience makes it easier to find the exact data needed for a specific scenario. Figure: Search from anywhere in Fabric using Global Search, then open the new search results page to explore and refine the results. More enhancements are coming soon, including support for additional items and object types, expanded filters, richer relevance signals, and semantic search. By understanding user intent alongside keywords, these capabilities will make data discovery more intuitive and effective. To learn more, refer to the OneLake Catalog Overview documentation. Fabric Core MCP Server (Generally Available) Fabric Core MCP Server now provides AI agents with a secure, cloud-hosted way to work with Microsoft Fabric through Model Context Protocol (MCP). Any compatible MCP client can connect to the Fabric endpoint and authenticate with Microsoft Entra ID, without installing a local server or building a custom integration. Agents can search the OneLake catalog; manage Fabric workspaces, items, folders, permissions; and view capacity information. Every operation respects existing Fabric role-based access control and is recorded in Fabric audit logs, helping organizations automate Fabric tasks while preserving established security and governance controls. Figure: Fabric Core MCP Server authenticates agents with Microsoft Entra ID and executes authorized Fabric API operations through a single remote endpoint. To learn more and get started, refer to the Get started with Fabric Core MCP Server documentation. Git Integration Branch workspace admin profile (Preview) When you branch out to a new workspace in Fabric, the branch workspace admin profile lets a workspace admin define the identity and settings used to create that branch workspace. Developers can then create branch workspaces on their own, without needing permission to create workspaces or assign capacity. Why this matters Developers self-serve branch workspaces without elevated permissions. No create-workspace or assign-capacity permission required. Every branch starts from a governed baseline. The workspace must be connected to Git first. When a developer branches out to a new workspace, they select ‘Use branch workspace admin profile’ in the Branch Out dialog, where Fabric shows that the new workspace uses the admin profile settings. Fabric creates the branch workspace with the profile the admin configured, so isolated development stays consistent and governed across your team. Figure: Branch workspace admin profile settings. To learn more, refer to the Development process using branch workspace in Microsoft Fabric documentation. Compare and commit changes (Generally Available) A few months ago, we introduced the compare experience in Fabric Git integration, and it keeps getting better. This release brings clearer conflict resolution, sub-folder support, coverage for all supported Fabric items, and the new ability to commit Fabric items. Before you commit, update, or resolve conflicts, you can inspect exactly what changed between your workspace and the connected Git branch, side by side or inline. Why this matters Resolve conflicts with clear, scoped context. Commit Fabric items across workloads. See exactly what changed before you act. Review incoming updates before you apply them. Figure: Review and commit changes. To learn more, refer to the Compare and commit items in Fabric Git integration documentation. File level commit (Preview) As part of the enhanced compare and commit experience, we are introducing a new capability in preview: committing only specific files within a supported Fabric item. Sometimes only part of your work is ready. File-level commit lets you commit completed files while unfinished changes remain in the workspace until they are ready. Why this matters Commit only the files you finished working on. Keep unfinished changes out of the commit. Avoid large commits by committing files in smaller batches. Say you’re working in a Warehouse, and you have finished one view while your other changes are still in progress. Instead of committing the entire item, you can select just that view and commit it, leaving the rest of your edits in the workspace for later. This keeps each commit tied to one finished change, so your Git history and pull requests are easier to follow. Figure: Review and commit changes – file level. File-level commit (Preview) is available for supported items in the Fabric UI, and through the Commit to Git API. To learn more, refer to the Compare and commit items in Fabric Git integration documentation. Branch out with selective branching (Generally Available) When you branch out to another workspace in Fabric, you can include only the items you need instead of copying the entire workspace, giving you a smaller, purpose-built workspace and faster time to code. The headline of this release is performance. The Select items dialog now loads quickly, even when the connected branch contains many items. You can pick the items you want and start the branch out while Fabric calculates item dependencies in the background, so you no longer wait for the full dependency calculation to finish before you act. Why this matters Branch out with only the items you need, instead of copying an entire workspace. Smaller, purpose-built workspaces and faster time to code. Reduced risk of unintended changes. Select items and branch out while dependency calculation runs in the background. Figure: Select specific items when branching out to another workspace. To learn more, refer to the Development process using the Branch-Out experience documentation. Branch workspace (Generally Available) A branched workspace is linked to a source workspace, so you can work on changes in an isolated environment and see how your workspace fits into the rest of your development flow, all inside Fabric. For this release, we focused on the developer's experience. The branch out, switch, and checkout operations now live in the main Source control pane, so you manage branching from one place instead of moving between menus. The pane also shows the full connected repository and folder in the main view, so you always know which branch, repository, and folder your workspace is connected to. If you automate branch creation outside Fabric, you can also establish the relationship with the Create Workspace Relation API. Why this matters Branch out, switch, and check out from one place in Source control. See the connected repository and folder directly in the main view. A clear relationship between a branched workspace and its source workspace. Figure: Source control pane in Fabric Git integration. To learn more, refer to the Development process using the Branch-Out experience documentation. Bulk export / import API (Generally Available) With a single call, Bulk Export Item Definitions reads the definitions of many Fabric items from a workspace, and Bulk Import Item Definitions writes them into a workspace, so deployment tools can move a whole set of items together instead of one item at a time. The endpoints are no longer on the beta path, and error responses now include more detail when an export or import fails, so you can see what went wrong and fix it faster. These APIs also power fabric-cicd, the open-source tool many teams use to automate their Fabric deployments. Its bulk option is now production ready, so you can publish all your items in a single operation. As part of this effort, the bulk option now supports dynamic replacement, a frequently requested capability that resolves values which change between environments during deployment. Why this matters Export and import a full set of item definitions in a single call. The endpoints are generally available and no longer on the beta path. Clearer error details when an export or import fails. Dynamic replacement in fabric-cicd for values that change per environment. Figure: Suggested build and release pipelines using the bulk-import API or fabric-cicd. To use the APIs, refer to the Core Items REST API documentation. To use bulk deployment, explore Fabric-cicd Bulk Option. OneLake OneLake Outbound Access Protection with external shortcuts (Generally Available) When enabled, this control helps protect sensitive data by blocking outbound shortcuts and copy operations by default, while permitting approved connections through the connector allowlist. This reduces the risk of data exfiltration from Fabric workspaces. Figure: Configure data connection rules for outbound access protection, including cloud and gateway connection policies. This release also introduces support for cross-workspace shortcuts with the OneLake File Connector. Now, you can build an allowlist of supported shortcut targets to other Fabric workspaces using the OneLake File Connector, or external destinations like Azure Blob Storage or Amazon S3 using the relevant connector. Outbound access protection gives workspace admins granular control over their organization’s data security, without compromising on open access to approved data sources. To learn more, refer to the outbound access protection and OneLake documentation. OneLake Table Read API (Preview) Securely query data to power AI agents and applications using the OneLake Table Read API. This API extends the existing Delta and Iceberg compatible Table APIs, by allowing you to read data directly from discovered tables. This API fully integrates with OneLake security, applying row and column level security to each request. The result is a lightweight read surface with security built in. Figure: Discover and query data securely from your data agents through the Table Read API. The Table Read API enables seamless integration of up-to-date Iceberg and Delta tables directly in Rayfin apps and data agents through Apache Arrow. To learn more, refer to the Table Read API documentation. New OneLake security UX with Members and Data Tabs (Generally Available) Understand and manage OneLake security roles more easily with the new OneLake security Members and Data experiences in the UX. Use the Members tab to understand which roles are assigned to a given user. You can drill into that user’s access to see specific table permissions and which roles are providing the access. Likewise, you can answer questions like “who can see Table A?” with the new Data tab. This page gives you a single view of what data in your item has been added to a role, which roles are giving those permissions, and then who is assigned to those roles. Figure: View users that can access data in your item, and which roles granted those permissions with the new Members tab. We have also made role management easier, with bulk role assignments for members. Grant a user access to multiple roles in a single UI gesture or quickly remove all their permissions with a single click to de-permission users. To learn more, refer to the OneLake security documentation. Data Engineering Custom Live Pools for Fabric Data Engineering (Generally Available) Custom live pools for Microsoft Fabric Data Engineering give notebook workloads fast, predictable Spark session startup with your custom libraries ready to go. Custom live pools keep Spark clusters pre-warmed during a schedule you define, reducing the time teams spend waiting on compute before they can start working. With pools fully warmed and libraries preinstalled through a Fabric environment using Full publishing mode, notebook sessions can start in as little as five seconds in internal testing. This supports interactive exploration, scheduled notebook runs, and notebooks orchestrated through pipelines. *Note: Startup time based on internal Microsoft testing; actual results may vary by workload and environment configuration. Figure: The cluster-level monitoring experience shows the warm-up status of individual clusters, so you know when they're ready to serve notebook sessions. Now, you can also manage custom live pools through public APIs, including editing and updating pool configurations and managing and monitoring schedules — making it easier to automate pool management and align compute availability with your operational workflows. Together with control over schedules and the number of warm clusters, these capabilities help you plan compute readiness for daily data preparation and time-sensitive analytics. To learn more, refer to the custom live pools documentation. Native JSON acceleration in the Native Execution Engine (Preview) The Microsoft Fabric Spark Native Execution Engine now supports accelerated JSON file reads in Fabric Runtime 2.0. Existing Spark DataFrame and Spark SQL workloads can read and parse JSON through the engine's vectorized C++ execution path, helping more of an eligible query stay columnar as data moves through projections, filters, joins, and aggregations. This update is useful for application and device telemetry, nested API and partner payloads, configuration and control files, schema and manifest files, metadata-driven orchestration, and semi-structured landing data prepared for Delta tables. Customers can continue using familiar Spark JSON read patterns, including spark.read. json(...), without adopting a new API or rewriting downstream transformations. JSON acceleration (Preview) with Fabric Runtime 2.0, powered by Apache Spark 4.1. This release covers the JSON file-read and parsing path; JSON writes, structured streaming, and unsupported operations in the same query continue to use or fall back to the standard Spark execution path. To learn more, refer to the Native Execution Engine documentation. Delegated management of Custom Live Pools for workspace Members (Preview) Workspace administrators can now empower workspace Members to configure Custom Live Pools through Fabric environments. Administrators enable this capability by using the existing Customize compute configuration for items workspace setting, extending self-service compute management while retaining centralized governance. Once enabled, Members can select an existing administrator-created custom Spark pool, configure session-level driver and executor compute properties, create or update the live-pool configuration, activate live-pool compute, configure its schedule, and save and publish the environment. This helps workload owners respond more quickly to changing analytics needs without routing every environment-level compute adjustment through a central platform team. Figure: Administrators delegate Custom Live Pool configuration to workspace Members while retaining centralized governance. Administrators continue to create and manage the underlying custom Spark pools and can remove delegated configuration by turning off the workspace setting. Custom Live Pools require a paid Fabric capacity and an existing custom Spark pool. Trial capacities and Starter Pools are not supported. To learn more, refer to the Configure Custom Live Pools documentation. Notebook toolkit for agentic development support (Preview) Fabric Notebook Toolkit (FNTK) is the python library that supports end-to-end agentic development of Microsoft Fabric Notebooks possible from GitHub Copilot CLI, OpenAI Codex, and Claude Code. Today’s coding agents can generate Spark code but cannot reliably complete the surrounding Fabric workflow, including selecting the correct workspace and notebook, understanding the Lakehouse and runtime context, editing the intended cell safely, running the notebook, or diagnosing failures. Developers must handle these steps manually, limiting agents code suggestions rather than completed outcomes and increasing the risk of errors. FNTK closes this gap by giving supported LLM clients a consistent, safe, notebook-aware command surface for discovery, authoring, targeted modification, execution, monitoring, and diagnostics. FNTK transforms notebook agents from code generators into development agents capable of completing and validating work. Capabilities End-to-end development: An agent can understand a request, inspect the existing notebook, generate context-appropriate code, apply it to the correct cell, execute it, and analyze the result. Fabric-aware behavior: Operations preserve workspace, notebook, Lakehouse, Environment, language, runtime, cell structure, and execution context. Safe automation: Target identity, changes, and destructive operations are validated and confirmed before remote state is modified. Cross-client consistency: Copilot CLI, Codex, and Claude Code expose the same core notebook capabilities, safety rules, and failure behavior. Reduced development friction: Developers no longer need to copy code between the terminal and Fabric, manually locate cells, start runs, or navigate several monitoring surfaces. Why FNTK is critical for agentic notebook development FNTK is not simply another notebook CLI. It is the missing control plane between an LLM’s reasoning and a Fabric Notebook’s state and execution environment. Without FNTK, the agentic workflow stops after code generation: Prompt → generated code → manual developer intervention With FNTK, the agent can close the development loop: Prompt → context discovery → notebook inspection → code generation → targeted change → remote execution → diagnostics → correction To learn more, refer to the Fabric Notebook Toolkit documentation. Integration with Codex/Claude Code in Fabric Data Engineering VS Code extension The Fabric Data Engineering VS Code and agent extension integration enables developers to use GitHub Copilot, Claude Code VS Code extension, or Codex VS Code extension to author Fabric Notebooks with the same notebook context and workflow. Now, the Fabric Data Engineering VS Code extension understands the active notebook, selected cell, language, workspace, runtime, and attached resources. GitHub Copilot can use this context, but Claude Code VS Code extension and Codex VS Code extension do not receive it consistently. Developers using that agent extension must manually restate the context, copy generated code, and repair incorrect imports, languages, or cell placement. This feature closes that gap by exposing a secure, local MCP server from the Fabric DE VS Code extension. After explicit user approval, Claude Code or Codex can retrieve the minimum required notebook context and return code targeted to the correct cell. The developer can then preview, edit, accept, or reject the result before any changes are applied to the notebook. Following is a typical workflow this update enables: Open and select the target: The developer opens a Fabric Notebook through the Fabric Data Engineering VS Code extension and selects the cell or insertion point to modify. Submit the prompt to Codex: The developer asks Codex in Codex VS Code extension: “Read the sales table from the attached Lakehouse, calculate monthly revenue growth, and display the result.” Retrieve Fabric context: Codex calls the Fabric DE extension’s local MCP server to obtain the notebook language, target cell, document revision, runtime context, and relevant Lakehouse metadata. Generate and preview the cell change: Codex returns notebook-ready code for the selected cell. The Fabric DE extension validates the language, Fabric APIs, target, and document revision, then lets the developer preview, edit, accept, or reject the result. Apply and run: After acceptance, only the selected cell is updated. The developer runs it using Fabric Notebook’s existing execution controls and continues iterating with Codex if the output requires changes. Select the corresponding VS Code command to enable the integration. Figure: Enable codex/Claude code integration. Spark connector for SQL databases (Generally Available) Run Spark reads and bulk writes against SQL Server, Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VM, and SQL database in Fabric using a connector that is ready for production data engineering workloads. Built for analytics and data engineering scenarios, the connector supports table reads, custom query reads, and high-performance bulk writes. In Fabric, it automatically uses Microsoft Entra authentication. SQL authentication and service principal or access token-based authentication is also supported. The connector honors SQL engine security controls, including object-level security (OLS), row-level security (RLS), and column-level security (CLS). The latest enhancements improve bulk-write compatibility by mapping Spark timestamp types to SQL datetime2, preserving the precision of timestamp data across Spark and SQL workloads. Figure: A Spark notebook reading from and writing to a SQL database using the Spark connector. The connector is preinstalled in the Fabric runtime, so you don't need to install it separately. To learn more, review the Spark connector for SQL databases documentation. High Concurrency Support for the Fabric Livy API (Generally Available) With this release, high-concurrency support for the Microsoft Fabric Livy API (Generally Available) is ready for production Spark automation workloads. Applications, orchestration services, and CI/CD processes can execute multiple Spark statements concurrently without creating and coordinating a separate Spark session for every request. Fabric can place compatible execution contexts into a shared underlying Spark session while keeping each request in an isolated read-evaluate-print loop (REPL). An optional 'sessionTag' provides a server-side hint for packing related workloads into existing sessions when capacity is available. Existing Livy session and batch workloads continue to work without modification. Figure: Accessing Livy API connection strings from the Lakehouse setting pane. To learn more, see High-concurrency support in the Fabric Livy API documentation. High-concurrency support in the Microsoft ADO.NET driver (Generally Available) Organizations can use high-concurrency mode in the Microsoft ADO.NET Driver to run concurrent Spark SQL queries in Fabric workloads without provisioning a separate classic Spark session for every connection. This can be used with ADO.NET connection pooling which reuses client-side resources, while high-concurrency mode manages shared Spark capacity on the server. To enable high-concurrency mode, add 'HcEnabled=true' to the connection string. To learn more, review the high-concurrency section in the Microsoft ADO.NET driver high-concurrency documentation. High-concurrency mode for the Microsoft JDBC driver (Generally Available) High-concurrency mode in the Microsoft JDBC Driver for Fabric Data Engineering is ready for production use, helping Java applications run concurrent Spark SQL workloads through shared Fabric Spark capacity. High-concurrency mode can reduce connection startup time, avoid repeated Spark session provisioning, and improve capacity utilization for applications that open multiple connections to the same Fabric workspace and lakehouse. Each connection continues to execute statements through its assigned context within the shared session. To enable high-concurrency mode, add 'hcEnabled=true' to the JDBC connection URL: String url = "jdbc:fabricspark://api.fabric.microsoft.com;" + "FabricWorkspaceID=<workspace-id>;" + "FabricLakehouseID=<lakehouse-id>;" + "AuthFlow=2;" + "hcEnabled=true"; You can also add an optional session tag, such as 'sessionTag=', to provide a server-side session-matching hint. Figure: Connecting to a Fabric Lakehouse with the Livy JDBC driver in DbVisualizer. To learn more, refer to the Microsoft JDBC driver for Fabric Data Engineering documentation. High-concurrency support in the Microsoft ODBC driver (Generally Available) The Microsoft ODBC Driver for Fabric Data Engineering now supports high-concurrency mode on Windows and Linux, enabling ODBC-based applications and tools to run concurrent Spark SQL workloads more efficiently within Fabric. The driver has also reached general availability and is ready for production workloads. ODBC applications can attach compatible connections to shared, warm, server-managed Livy sessions instead of provisioning a separate Spark session for every connection. This mode is designed for workloads that open many short-lived connections, including BI dashboards, application services, notebook kernels, and ETL fan-out scenarios. Session tags, Fabric environment settings, and Spark configuration values help the Livy service determine which connections can safely share a session. Linux users can configure the same capability through unixODBC files or environment variables. To enable high-concurrency mode, set 'LivyMode=HighConcurrency' in the ODBC connection string: connection_string = ( DRIVER={Microsoft ODBC Driver for Microsoft Fabric Data Engineering}; WorkspaceId=<workspace-id>; LakehouseId=<lakehouse-id>; AuthFlow=AZURE_CLI; LivyMode=HighConcurrency; SessionTag=<customTag>; ) Figure: Configuring the Microsoft ODBC Driver for a Fabric Lakehouse. To learn more, refer to the Microsoft ODBC driver for Fabric Data Engineering and Microsoft ODBC driver for Fabric Data Engineering on Linux documentation. Resize columns in your Lakehouse Explorer table preview (Generally Available) You can now adjust column widths in any table preview in the Lakehouse Explorer. Inspect long values, descriptive column names, and complex datasets more efficiently when working with wide tables. Data professionals can tailor the preview to the data they're reviewing for their custom needs. For example, when validating a customer dimension table, expand columns containing names, addresses, or other long text values to see more information without exporting the data or repeatedly scrolling across the table. To use this capability, open a table in the Lakehouse Explorer for preview, point to the boundary between two column headers in the table, and drag it to the preferred width. Figure - Resizing columns in the Lakehouse table preview. To learn more, refer to the Navigate the Lakehouse explorer documentation. Project Osmos: Data engineering in Microsoft Fabric (Preview) Project Osmos is an agentic data engineering experience in Microsoft Fabric that brings governed, autonomous execution to complex, long-running data engineering work. You define the desired outcome, provide the relevant Fabric context and guardrails, and delegate the work as a persistent Task. Within those guardrails, Osmos autonomously inspects the workspace, plans the work, writes and runs Spark, creates or updates Fabric items, and validates the result. You delegate the Task. Osmos carries it through to a shippable outcome. Optimized for project-scale data engineering: Project Osmos is designed for complex initiatives spanning many assets, dependencies, and execution steps, including data platform migration projects, ERP consolidation, ETL modernization, Lakehouse modernization, compliance transformation, and performance optimization. A Task can coordinate multiple agents and explore hundreds of approaches in parallel to converge on a high-quality outcome. Built for work you can ship: Osmos maps the workspace context and reuses existing assets. It designs for reuse, creates maintainable and documented Spark code, and tests and refines the outcome before reporting completion. Multiple surfaces, unified experience: Tasks are not tied to sessions. Start, monitor, and steer the same autonomous Task from supported Fabric and coding-agent experiences without losing context or progress. Collaborative, by design: Project Osmos Tasks inherit Fabric workspace permissions. Authorized members can view and interact with the same Task from supported surfaces. Osmos requests decisions in context and notifies members when their input is needed. Shared context, progress, decisions, and items persist as people step in and out. Figure: Project Osmos autonomously executes and tracks long-running data engineering tasks in Microsoft Fabric. To learn more, refer to the What is Data Engineering in Microsoft Fabric? Documentation. AI Functions: model migration, simpler setup, and richer usage insights We have retired the older gpt-4.1 model series. Pipelines pinned to gpt-4.1 (retired May 30, 2026) should migrate to gpt-5.1, and those pinned to gpt-4.1-mini (retiring July 2) should migrate to gpt-5-mini. The PySpark .ai interface now remains bound to the result schema, making it easier to chain multiple AI functions, such as summarize → classify, without intermediate DataFrame computation. In addition, PySpark now supports df.ai.stats for detailed token usage after any AI function call, including a breakdown of reasoning tokens. For pandas, AI Functions no longer require the openai python package, enabling faster starts. Capacity-limited rows are surfaced as CapacityExceededResult, enabling clean retries via aifunc.split_results. To learn more, refer to the AI Functions documentation. Data Science Spark 4.1 Support for ML Endpoints (Preview) Fabric ML Endpoints now support models trained on Spark 4.1, enabling customers to take advantage of the latest runtime innovations while operationalizing machine learning models for real-time inference. With Spark 4.1 support, data scientists can train and deploy models on a consistent runtime, reducing friction when moving from experimentation to production. This enhancement helps customers modernize their machine learning workloads while continuing to use managed, scalable model serving in Microsoft Fabric. Tensor-Based Models on Endpoints (Preview) Fabric ML Endpoints now support tensor-based models, expanding real-time serving scenarios beyond traditional tabular machine learning. Customers can deploy and score models with tensor input and output signatures, including models built with popular frameworks such as PyTorch and TensorFlow. This enhancement enables a broader range of AI and machine learning workloads to be operationalized through Fabric model endpoints, helping organizations serve advanced predictive models with greater flexibility and scale. Data Warehouse Modernize Teradata Workloads Faster with Migration Assistant (Preview) Migrating legacy data warehouses can require significant effort to translate schemas, SQL code, and business logic. Migration Assistant for Microsoft Fabric Data Warehouse now supports Teradata, helping organizations modernize their workloads faster and with greater confidence. Migration Assistant provides a native, guided experience in Microsoft Fabric. Customers can upload Teradata SQL and BTEQ files and convert key warehouse assets, including: Tables Views Stored procedures Functions Macros Migration Assistant automates conversion of database objects, identifies unsupported constructs, and highlights areas that may require attention. This reduces manual effort and gives teams earlier insight into migration readiness. Teradata remains critical to many enterprise analytics environments, but its proprietary SQL constructs and platform-specific scripting can make migrations complex. By bringing Teradata migration capabilities directly into Fabric, Migration Assistant provides a streamlined, first-party path to modernization. Figure: Teradata as a supported source system in Migration Assistant for Fabric Data Warehouse. Teradata support removes another barrier for customers migrating off legacy platforms, letting them assess, convert, and move warehouse workloads to Fabric Data Warehouse without leaving the Fabric experience. Fabric warehouse Custom SQL pools (Generally Available) Custom SQL pools for Fabric Data Warehouse give administrators finer-grained control over how SQL compute resources are allocated across workloads. Custom SQL pools build on the warehouse’s autonomous workload management by letting you define your own isolation boundaries, explicitly assign resources, and route queries based on application context. With Custom SQL Pools, you can create multiple isolated SQL pools within a single workspace and allocate a percentage of available compute to each. Queries are routed to the appropriate pool ensuring that critical workloads get the resources they need without being impacted by other activities in the warehouse. , Fabric_portal_view_of_the_custom_sql_pool_configuration._3_pools_are_configured Key benefits include: Predictable performance for critical workloads: Reserve compute for business critical reporting or dashboards, so they aren’t disrupted by adhoc queries or background processing. Flexible workload isolation without added complexity: Allocate resources where they matter most without needing to split workloads across multiple workspaces or scale capacity just to protect one workload. Custom SQL Pools are especially useful when multiple applications share a single Fabric warehouse or SQL analytics endpoint and have different performance or priority requirements. As your capacity scales up or down, your pool allocations automatically scale with it, preserving the relative resource distribution you’ve defined. To learn more about custom SQL pools in Fabric Data Warehouse, refer to the Custom SQL Pools documentation. SQL pools Statement Type classifier (Generally Available) SQL pools statement-type classification provides a simpler way to align SQL compute with your workload. Fabric automatically classifies SQL statements into two pools: SELECT for query and reporting workloads, and NONSELECT for ingestion, transformation, data modification, and schema-management workloads. You can adjust the compute percentage available to each pool instead of using the built-in 50/50 distribution. For a read-heavy environment, you can allocate a higher percentage to the SELECT pool. For an ingestion- or transformation-heavy workload, you can allocate more to the NONSELECT pool. Fabric continues to route each statement automatically based on its type. Unlike application-name classification, which routes requests according to the application that submitted them, statement-type classification does not require you to identify or maintain application names or matching patterns. Figure: Configure the compute percentages available to SELECT and NONSELECT workloads using SQL pools statement-type classification. To learn more, refer to the Custom SQL Pools documentation. Distributed Bitmap Filters (Generally Available) In analytical workloads, it’s common to JOIN between large fact tables and smaller dimension tables with some additional filtering. With Distributed Bitmap Filters (DBF), these queries are optimized to preemptively filter out irrelevant rows before the JOIN. This means less unnecessary data movement, smaller resource requests, and faster queries. In internal testing, two customers with JOIN-heavy, selective queries achieved 50%-60% faster workloads with DBF. Figure: Visual demonstration of the reduction of rows that need to be shuffled during JOINs with Distributed Bitmap Filters, compared to before New analytical functions (Preview) Fabric Data Warehouse and SQL analytics endpoint now support a new set of analytical functions that make advanced statistical analysis simpler and more efficient. New built-in functions include MEDIAN, QUANTILE, APPROX_MEDIAN, and APPROX_QUANTILE, available in both aggregate and window forms. These functions enable developers to calculate distribution metrics and percentiles with significantly less code. Figure: Using new functions in T-SQL script in Fabric Data Warehouse. In addition, PERCENTILE_CONT and PERCENTILE_DISC have been enhanced to support aggregate syntax, complementing their existing window-function capabilities and providing greater flexibility when analyzing data distributions. Learn more, refer to the new analytical functions documentation. T-SQL language enhancements (Preview) T-SQL in Fabric Data Warehouse continues to evolve with new language enhancements that make query development more intuitive, concise, and productive. New constructs such as GROUP BY ALL, ORDER BY ALL, and the QUALIFY clause reduce query complexity and eliminate common boilerplate code, enabling developers to express their intent more clearly. Figure: Using new syntax in T-SQL script in Fabric Data Warehouse. In addition, Fabric introduces support for the more ergonomic FROM ... SELECT query format. This alternative syntax follows a natural data-flow approach by allowing developers to define data sources first and then specify the columns to project, improving readability and making complex queries easier to author and maintain. Together, these enhancements help both new and experienced T-SQL developers write cleaner, less verbose, and more maintainable code while preserving the full power and familiarity of the T-SQL language. Learn more about QUALIFY, GROUP BY ALL, ORDER BY ALL, and FROM - SELECT syntax in Transact-SQL documentation. Integration with Fabric User Data Functions (Preview) Fabric Data Warehouse now integrates with Fabric User Data Functions (UDFs), enabling developers to extend T-SQL with custom Python logic. By creating T-SQL external functions that reference Python functions in a Fabric User Data Functions item, developers can invoke Python code directly from T-SQL code. Figure: Direct invocation of a Fabric User Data Function from T-SQL queries in Fabric Data Warehouse. Calling the functions from T-SQL delegates execution to the remotely hosted Python function, where the code runs in a secure environment. This integration combines the simplicity of T-SQL with the flexibility and richness of Python, unlocking a wide range of scenarios. Developers can call Fabric or external APIs, send emails and Teams notifications, process Excel, XML, PDF, and other file formats, and access data across One Lake, Warehouses, Fabric databases, and external data stores. In addition, external functions can retrieve secrets and configuration values from Azure Key Vault or Fabric variable libraries, implement custom encryption and masking logic, and enrich or validate data through tasks such as geocoding, VAT and IBAN verification, and machine learning scoring. By bridging T-SQL and Python, Fabric Data Warehouse enables developers to seamlessly combine analytical workloads with custom business logic, external services, and AI-powered data processing directly within their data solutions. To learn more, refer to the integration with Fabric User Data Functions documentation. Automate Every Deployment with Confidence: Introducing Pre/Post Deployment Support (Preview) – Pradeep Srikakolapu Deployments should accelerate delivery, not add operational complexity. Yet many Fabric Warehouse teams still depend on manual validation steps, custom scripts, and deployment runbooks to prepare environments and verify production readiness. These tasks slow down releases, increase operational overhead, and introduce unnecessary risk. With CI/CD Pre/Post Deployment Support, organizations can automate critical tasks before and after Fabric Warehouse deployments, making release processes faster, more predictable, and more reliable. Before deployment, teams can automatically validate environments, verify dependencies, configure settings, and prepare warehouses for change. This ensures deployment prerequisites are executed consistently across every environment and reduces opportunities for human error. After deployment, automated validation and governance checks help confirm that warehouses are healthy, secure, and production ready. Teams can automate post-deployment verification, cleanup activities, and compliance checks to ensure every release meets organizational standards. The result is a more resilient and enterprise-ready deployment process. Development and operations teams spend less time managing deployment mechanics and more time delivering data products, analytics capabilities, and business value. By automating pre- and post-deployment workflows, Fabric Warehouse customers can improve release consistency, detect issues earlier, and reduce production risk, enabling confident, repeatable deployments at scale. Figure: Selecting a shared query to run as a pre- or post-deployment script. Automate Fabric Warehouse Lifecycle Management with Item definition support in CRUD APIs With Warehouse CRUD APIs and Item Definition Support, organizations can programmatically create, retrieve, update, and deploy Fabric Warehouse items as code. Item definitions can be integrated with source control systems, enabling versioning, changing tracking, and automated promotion through deployment pipelines. Development teams can automate environment provisioning, deployment workflows, and release validation using a consistent API-driven approach. This reduces manual effort, improves repeatability deployment, and ensures warehouse configurations remain synchronized across environments. The result is a modern DevOps experience for Fabric Warehouse, enabling reliable CI/CD workflows, faster releases, and governance at scale. Learn more in the Items - REST API (Warehouse) documentation. Diagnose warehouse workloads with the SQL DW operations skill (Generally Available) The SQL DW operations skill helps administrators, engineers, and data professionals troubleshoot Fabric Data Warehouse environments using natural-language prompts. Using GitHub Copilot CLI or another compatible AI coding tool, start with the operational question instead of first choosing system views or writing diagnostic SQL. The skill runs bounded, read-only diagnostics and returns a structured diagnosis with supporting evidence, recommended actions, and validation steps. Use it to investigate failed and canceled queries, explain performance slowdowns, find recurring resource-consuming query patterns, correlate capacity spikes with warehouse activity in the same time window, assess SQL pool pressure, and check lakehouse table health. By bringing these diagnostic steps into one workflow, the skill helps teams move from a symptom to evidence and a clear next step while keeping changes under the user's control. Figure: Using a natural-language prompt to investigate a Fabric Data Warehouse issue with the SQL DW operations skill. Learn how to diagnose warehouse workloads with the SQL DW operations skill and explore the open-source Microsoft Fabric skills repository. More ways to use scalar UDFs (Preview) Microsoft Fabric Data Warehouse and SQL analytics endpoint now support scalar UDFs across more query patterns and more complex procedural logic. These enhancements make it easier to bring existing T-SQL functions to Fabric or create new reusable business logic across analytical queries. New capabilities include: Loop control: BREAK and CONTINUE within WHILE loops. LOB query shapes: Expression Block inlining now supports large object types, such as VARCHAR(MAX), allowing scalar UDFs to be used in GROUP BY, ORDER BY, and common table expressions (CTEs). Conditional query shapes: Expression Block inlining now supports scalar UDF calls within IF EXISTS (SELECT ...) statements. More UDFs per query: Scalar UDF Inlining now supports more UDFs within a single query. Resource estimation: Improved resource estimates for UDFs that contain IF and WHILE control flows. For example, a scalar UDF that processes VARCHAR(MAX) data can now use BREAK and CONTINUE within a WHILE loop to control how values are processed. Figure: A VARCHAR(MAX) scalar UDF uses BREAK and CONTINUE before being called from an analytical query. To learn more with the CREATE FUNCTION syntax and Create scalar user-defined functions documentation. Real-Time Intelligence Business Events (Generally Available) A business event is a meaningful occurrence or change in state that should cause another team, application, or automated process to respond. For example, an order being placed, a payment failing, inventory falling below a threshold, or an approval being required. Unlike raw telemetry or a diagnostic log, a business event captures the business meaning of what happened. In Fabric Real-Time Intelligence, every event follows a shared schema in an Event Schema Set, so independent publishers and consumers agree on its fields, data types, version, and meaning. Business Events becomes generally available in September 2026 Real-time hub provides the central place to discover events, manage publishing and consumption access, inspect schemas, connect new participants, and validate the data moving between them. Teams can now publish from the Fabric tools where business logic already lives, route events through Eventstream for real-time distribution, consume them in Eventhouse for real-time and historical analysis, and act on them through Activator to trigger alerts, automate actions, and power analytics or AI-driven workflows, all without changing the original publisher. Together, these capabilities provide an end-to-end Real-Time Intelligence solution, from event generation and event consumption to real-time analysis and action. Route business events through Eventstream Eventstream is now a native Business Events consumer. From an existing Eventstream, users can add Business Events as a source, select one or more events from the same Event Schema Set, review the shared contract, and then apply transformations, enrichment, filtering, and routing. The publisher remains independent while new processing paths can subscribe and evolve at their own pace. Figure: Start from Eventstream and add Business Events as a source. The same experience can start from Real-time hub. Select a business event, choose Add consumer > Eventstream, and Fabric opens a prepopulated creation flow. This event-first path removes repetitive configuration and makes it faster to fan out an existing signal to analytics, automation, or downstream destinations. For step-by-step guidance, learn how to add Business Events to an Eventstream or create an Eventstream consumer from Real-time hub. Figure: Start from a business event and add Eventstream as a consumer. Test and inspect the complete event flow See what every publisher sends and every consumer receives Data preview provides an immediate view of recent payloads for each publisher and consumer, together with event metadata and the active schema version. Users can compare both sides of the flow, confirm that a representative event arrived, and quickly isolate schema, permission, or routing issues. This built-in validation loop replaces guesswork with direct evidence. Explore how to preview Business Events data. Figure: Inspect recent publisher or consumer payloads alongside the governed event schema. Generate a representative event in seconds The sample publisher creates a JSON template directly from the selected event schema. Users can replace the generated values or upload a representative JSON file, publish the sample, and validate it immediately in Data preview and across connected consumers. Teams can test contracts, demos, and integrations before a production publisher is ready without writing temporary publisher code. Learn how to publish a sample Business Event. Create a UDF publisher from Real-time hub A new guided path connects an existing User Data Function to one or more selected business events. From Real-time hub, choose Publish > Publish from Functions and select the UDF from the OneLake catalog. Fabric adds the Event Schema Set connection, imports sample publisher code, and deploys or publishes the function when needed. The generated starting point keeps event emission close to validated inputs and domain logic. Users can focus on the condition and payload that matter to the business instead of configuring an external eventing SDK or custom integration plumbing. Learn how to use a User Data Function as a Business Events publisher. Figure: Launch the UDF publisher experience directly from the selected business event. A production-ready publisher and consumer ecosystem The native integrations introduced during Public Preview are also moving to general availability, completing a flexible ecosystem in which each team can use the Fabric experience closest to its work while every participant relies on the same governed event contract. GA integration Customer value Notebook publisher Turn analytical, data science, or machine learning results into governed business signals directly from a notebook. User Data Function publisher Emit events from reusable domain logic at the point where validated inputs and business rules are evaluated. Activator publisher Publish events when conditions are detected in Power BI reports, Real-Time Dashboards, KQL queries, or Fabric Warehouse SQL queries. Activator consumer Trigger notifications, workflows, and automated actions in response to business events, enabling real-time operational responses without custom development. Eventhouse consumer Automatically retain every published event for historical or near real-time KQL, T-SQL analysis and live visualization in Real-Time Dashboards. Data can also be queried and analyzed using Copilot with natural language. Together, these capabilities deliver the complete Business Events lifecycle: define a shared contract, publish from the tool closest to the business logic, test and inspect the flow, route events to real-time processors, retain them for analytics, and trigger independent downstream actions. Dive deeper into how to publish Business Events from a notebook, use Activator as a Business Events publisher, and analyze Business Events in Eventhouse and Real-Time Dashboards. Continue with the Fabric Events developer community. Whether you are designing your first event-driven solution or expanding an existing architecture, visit the Fabric Events developer site for developer-focused guidance, samples, architecture patterns, and resources that help you build with Business Events in Microsoft Fabric. Create richer visuals and denser layouts for smarter live monitoring (Generally Available) Operational dashboards need to communicate more than a metric’s current value. Viewers must be able to quickly understand whether that value is healthy, approaching a limit, or already within a critical range. Figure: KPI visualization modes for monitoring bike availability, dock utilization, station occupancy, and fleet usage. You can display a KPI in four responsive modes - Number, Bar, Gauge, or Donut - to suit different metrics and dashboard layouts. Configure the minimum and maximum scale, value format, decimal places, and units, then define conditional ranges with custom thresholds, colors, and status labels. Reference lines provide additional operational context by highlighting targets, service-level agreements, expected values, or capacity limits. By combining the current value with status ranges and reference indicators, the KPI visualization helps viewers identify important changes briefly and quickly focus on the metrics that require attention. Title, Text, and Divider visuals are now available in Real-Time Dashboards, providing additional options for organizing dashboard content and presenting operational information. These visuals enable dashboard authors to add descriptive context, section headers, explanatory text, and visual separation between related areas of a dashboard. Combined with existing dashboard capabilities, they support more structured layouts that help organize metrics, visualizations, and operational workflows into clearly defined sections. Figure: Real-Time Dashboard using a title banner, text box, and divider to organize transit KPIs, charts, and detailed data. These additions complement other dashboard experiences, including Fabric Maps, KPI, and Multi-KPI visuals, enabling teams to combine quantitative metrics, geographic context, and supporting narrative information within a single dashboard. Divider visuals can be used to separate operational areas, business processes, or monitoring scenarios, while text and title visuals can provide instructions, context, status explanations, or links to operational procedures. Together with dashboard layout improvements and command-driven interactions, these capabilities give authors greater flexibility in how dashboard information is arranged and presented. They can be used to create dashboards that accommodate a larger amount of operational information while maintaining a clear structure for viewers. In environments where teams monitor live operations, these capabilities can be used alongside ingestion-aware refresh, which updates dashboard visuals when new data arrives. By combining operational metrics, contextual information, and dashboard organization tools in a single experience, Real-Time Dashboards support a broad range of monitoring, investigation, and decision-making scenarios. To learn more about configuring and organizing dashboard visuals, review the Customize Real-Time Dashboard visuals documentation. Real-Time Hub Manage all your Activator rules from Real-time hub (Preview) Activator rules can be created from several places across Fabric, including Power BI reports, Eventstreams, Real-Time Dashboards, Warehouse queries, and Real-time hub. Until now, managing those rules meant returning to the experience where each rule was created or opening the corresponding Activator item. As the number of rules grows, that can make them difficult to find and manage. The new “Rules” page in Real-time hub brings together all the Activator rules you can access. From one place, you can review their status, start or stop them, and open a rule in Activator when you need to change its conditions or other settings. The Rules page also provides a quick view of recent activation activity for each rule. This makes it easier to see which rules are actively detecting conditions and which may need attention, without opening each Activator item and navigating through its monitoring experience. The result is a simpler way to discover, monitor, and manage rules across Fabric. Figure: With the new "Rules" page in Real-time hub, you can manage all your Activator rules in one place. To learn more, refer to the Manage Rules in Real-time hub documentation. Learn to monitor streaming data in Real-time hub in minutes (Generally Available) Want to turn your streaming data into actionable insights without writing code? Real-time hub includes a guided Monitor Streaming Data experience that walks you through the entire process, from connecting a data source of weather data to creating intelligent alerts. This guided walkthrough helps you go from data ingestion to actionable notifications in just a few steps. Simply select the Monitor Streaming Data card in Real-time hub and follow these steps: Connect your weather data source. Find your stream in Real-time hub. Preview live data as events arrive in real time. Create an alert based on the conditions you specify. Manage connected alerts and automate actions when events occur. Figure: Step-by-step walkthrough to monitor streaming data To learn more, refer to the Get started with Fabric Real-time hub documentation. Create capacity alerts quickly with ready-made templates (Generally Available) Capacity alerts help administrators respond before high usage levels or changes in capacity state affect users. Previously, creating an alert such as “notify me when capacity usage exceeds 80%” required configuring several technical details across multiple steps. The new capacity alert experience in Real-time hub makes these alerts easier to set up. Real-time hub now provides ready-made templates for common scenarios, including usage or capacity metrics exceeding a threshold and changes in capacity state. Choose a template, select the capacity, metric, and threshold that matter to you, and Fabric configures the underlying event source and rule conditions automatically. You can review the pre-filled rule, choose how you want to be notified or act, and save it. This reduces the setup needed to monitor capacity health and makes it easier to put proactive alerts in place. Figure: Quickly create capacity alerts in Real-time hub with ready-made templates. To learn more, refer to the Set alerts on Fabric capacity overview events in Real-time hub documentation. Capacity Overview Events in Real-time hub (Generally Available) Capacity Overview Events gives Fabric capacity administrators a continuous, near real-time stream of signals to monitor capacity health, trigger alerts, and automate actions. Two event types are included: Capacity Summary, emitted every 30 seconds with a high-level view of utilization and health across workloads, and Capacity State, emitted when a capacity is paused, resumed, or hits throttling-related conditions. Combined with Real-Time Intelligence, you can configure alerts when capacity metrics cross defined thresholds, trigger automated workflows, and stream the events through Eventstreams into an Eventhouse, where you can query them with KQL, visualize them in Real-Time dashboards, and retain them for historical analysis and long-term retention. For example, an administrator can be notified automatically when usage approaches a threshold, enabling proactive action before users are impacted. To speed up deployment, the community-built Capacity Events Accelerator provides prebuilt templates, dashboards, and configurations. Figure: Real-time hub Capacity overview events category, showing the event profile schema and the Set alert action. To get started, follow the Monitor capacity health tutorial, and refer to the Explore Fabric capacity overview events documentation for the full schema. Capacity Operation Events in Real-time hub (Preview) Capacity Operation Events, extend Capacity Overview Events from overall capacity health to operation-level root cause. Where Overview Events answer "what is happening to my capacity?", Operation Events answer "which operations are causing it?" Fabric emits one event per operation that consumes capacity, with details such as the workspace and item, capacity unit (CU) consumption, operation duration, throttling delay, status, and smoothing-window attribution. With this granular telemetry and Real-Time Intelligence, administrators can pinpoint the operations, workspaces, and artifacts driving capacity pressure, answering questions like which refreshes consumed the most capacity or which operations were throttled. Create no-code alerts in Activator when high-cost operations exceed a threshold or an operation fails, trigger automated remediation, and stream the events through Eventstreams into an Eventhouse, where you can query them with KQL, visualize them in Real-Time dashboards, and retain them for historical analysis, such as CU chargeback and governance. Figure: Real-time hub Capacity operation events (preview) category, showing the event profile schema and the Set alert action. To get started, review the Explore Fabric capacity operation events documentation for the full schema. New Item Soft-Delete and Recovery Events in Real-time hub (Preview) Fabric now surfaces lifecycle events for item soft-delete and recovery operations in Real-time hub, extending the existing Fabric workspace item events family. You can subscribe to notifications when a workspace item is soft deleted (moved into the recovery state) or recovered (restored), giving you real-time visibility into item lifecycle activity that wasn't previously available as events. Four new event types are included: Microsoft.Fabric.ItemSoftDeleteSucceeded Microsoft.Fabric.ItemSoftDeleteFailed Microsoft.Fabric.ItemRecoverSucceeded Microsoft.Fabric.ItemRecoverFailed Because these events use the same schema as existing workspace item events, you can consume them with the tools you already know. Set no-code alerts in Activator to notify a workspace admin the moment a critical item is accidentally soft-deleted, trigger automated workflows when an item is deleted or restored, and stream the events through Eventstreams into an Eventhouse, where you can query them with KQL, visualize them in Real-Time dashboards, and retain them for governance, auditing, and historical analysis. Figure: Fabric workspace events profile highlighting the new item soft-delete and recovery event schemas. To get started, review the Explore Fabric workspace item events documentation for the full schema. Eventstreams Fabric Event Schemaset and Schema Registry (Generally Available) Real-time applications evolve quickly, but they stay reliable only when producers and consumers agree on the structure of their data. With Schema Registry, you can now discover, define, and collaborate on the schemas used by Business Events and Eventstreams across your Fabric Tenant. You can group related schemas in Event Schema Sets and reuse them across multiple workspaces. Teams can replace disconnected schema definitions with shared data contracts to improve data quality, simplify collaboration, and reduce failures caused by unexpected changes to event structures. Figure: Schema registry showing list of schemaset and schemas across all Fabric Workspaces in your tenant What's new A shared source of truth: Organize related event types and Avro schemas in one governed Fabric item that teams can discover and reuse across real-time applications. Faster onboarding with bulk imports: Bring multiple schemas into an Event Schemaset in a single operation, reducing repetitive setup when onboarding an existing collection of event contracts. Figure: Detailed view of a Schemaset with ability to import schemas. Figure: Import AVRO schemas in bulk or one at a time. Safer schema evolution: Publish new schema versions while preserving their history and lineage. Compare schema versions side by side to quickly identify added, removed, or changed fields before adopting an update. Figure: Schema view - Compare schema versions in rendered preview mode. Figure: Code view - Compare schema versions in code view mode. Governance built into Fabric: Manage Event Schema Sets alongside other Fabric items using familiar workspace access controls and lifecycle-management experiences. Standards-based interoperability: Build on the vendor-neutral xRegistry specification to establish portable event metadata and governance patterns without relying on a proprietary schema model. With Event Schema Sets, schemas become durable contracts from event producers through downstream analytics. Platform teams gain centralized governance, while developers and data engineers can move from event to insight with greater clarity and confidence. Get started by creating an Event Schema Set in your Fabric workspace, adding or importing your Avro schemas, and defining your event types. Event Schema Sets also provide the foundation for schema-aware Eventstreams, now in preview, the topic of the next post. Learn more Schema Registry & SchemaSets documentation Business Events documentation xRegistry specification Schema-aware Fabric Eventstreams (Preview) Schema-aware Fabric Eventstreams (Preview) Modern streaming solutions often need to process events with different or evolving/drifting schemas, and multiple event types within a single pipeline. With Schema-aware Eventstreams (Preview), we are introducing a unified event processing experience that enables Eventstreams to work seamlessly with both schematized and unschematized events. Built with Event SchemaSet (Generally Available), schema-aware Eventstreams simplify event discovery, exploration, and processing while reducing the complexity of working with heterogeneous event streams. Users can create a schema-aware Eventstream and then ingest, understand, and process event data regardless of whether the events arrive as semi-structured payloads or tagged with registered schemas. Schema-aware Eventstreams introduces a redesigned data preview experience that makes it easier to inspect and understand streaming data. Explore deeply nested event payloads, view event headers and metadata, and export event details for further analysis. A new Classifier workflow helps users work with unschematized events that have different shapes all flowing through the same stream. By identifying a classifier or discriminator field, such as deviceType, Eventstream can distinguish and organize different event types while keeping them in a single pipeline. Schema-aware Eventstreams integrates with Event SchemaSet and Fabric's tenant-level schema registry. Ingested events with registered schemas can be automatically recognized and processed using their corresponding schema definitions. This makes it easier to govern, discover, and reuse data contracts across your organization. Last but not the least, Schema-aware Eventstreams enable schematized events, classified events, and untyped events to coexist within the same Eventstream. Updated operators and destinations can process all event types without requiring separate pipelines. Learn More Schema-aware Eventstreams documentation (Preview) SchemaSet documentation (Generally Available) Eventstreams documentation Real-Time Intelligence documentation Eventstream Custom Stream Connector (Preview) Real-world streaming environments are diverse. While Fabric Eventstream already supports a growing ecosystem of streaming sources, many organizations rely on proprietary systems, industry-specific platforms, licensed third-party software, or custom-built applications that don't yet have a native connector. Customer challenges: Required connectors are not yet available. Connector development timelines do not align with project schedules. Third-party licensing restrictions prevent Microsoft from redistributing certain drivers or connectors. ISVs and partners want to distribute and manage their own integrations. Custom Stream Connector addresses these challenges by giving customers control over how they connect real-time data into Fabric. Capabilities with Custom Stream Connector Upload and manage your own Kafka Connect-based source connector packages. Version and update connector implementations over time. Publish partner-developed or internally developed connectors into Fabric. Discover and use uploaded connectors directly from Real-time hub. Connect custom data sources to Eventstream using the same familiar connection experience as Microsoft-managed connectors. Route ingested data to Eventhouse, Lakehouse, Activator, Real-Time Dashboards, and other Fabric destinations. Feature: Upload a custom Kafka Connect-based source connector package to Eventstream. Simplify connector development with AI: Custom stream connectors are built using the Kafka Connect framework. Creating a custom stream connector has never been easier. Users can use natural language prompts to generate much of the connector implementation, configuration, and integration logic, dramatically reducing development effort and accelerating onboarding new data sources. If you already have a Kafka Connect connector, you can upload it directly into Fabric and start streaming events through Eventstream within minutes. Organizations can use existing open-source, partner-developed, or internally developed connectors to unlock new real-time analytics scenarios across Microsoft Fabric. Figure: Upload and manage new Eventstream custom connector from Real-time hub. To learn more, refer to the Custom stream connector in Fabric Eventstream documentation. Expanding Connectivity with New Connector Releases in Eventstream- Vaibhav Shrivastava Organizations increasingly need to connect operational systems, enterprise applications, cloud platforms, and modern data stores to their real-time analytics solutions. To help customers reduce integration complexity and accelerate onboarding, Eventstream continues to expand its portfolio of native connectors, enabling more data sources to stream directly into Microsoft Fabric. This release introduces several new generally available connectors, giving customers additional out-of-the-box options for bringing real-time and change-data-capture (CDC) workloads into Fabric without requiring custom integration development. Generally Available Cribl Connector: Stream observability, security, and telemetry data from Cribl pipelines directly into Fabric Eventstream. Solace PubSub+ Connector: Ingest events from Solace PubSub+ brokers and event mesh deployments for enterprise event-driven architectures. SAP Datasphere Connector: Connect SAP business data and analytics workloads from SAP Datasphere to Fabric in real time. MongoDB CDC Connector: Capture database changes from MongoDB collections and stream them into Fabric for real-time analytics and downstream processing. Mirror DB Change Data Feed Connector: Consume change data generated through Fabric Mirroring scenarios and integrate operational data changes into real-time pipelines. These new connectors further expand Eventstream's connectivity ecosystem, helping customers build end-to-end real-time intelligence solutions using the systems and platforms they already rely on today, while complementing the new Eventstream Custom Connector framework for scenarios requiring additional extensibility. Figure: Use Cribl, Solace PubSub+, SAP Datasphere, MongoDB CDC, and Mirror DB Change Data Feed connectors directly from Real-time hub using the familiar Eventstream connector experience. Learn more Add Cribl source to an eventstream Add Solace PubSub+ as source to an eventstream Add MongoDB CDC source to an eventstream Add SAPDatashpere source to an eventstream Add Mirrored Database Change Feed source to an eventstream Workspace Private link for Eventstream (Preview) Organizations often need to secure sensitive streaming workloads without applying network restrictions across an entire Fabric tenant. With Workspace-level Private Link (Preview) Microsoft Fabric provides a more granular approach to network isolation by enabling private connectivity at the workspace level. This allows teams to protect specific workspaces while maintaining existing network configurations for the rest of their Fabric environment. Workspace-level Private Link enables organizations to establish secure connectivity between an approved Azure virtual network and a specific Fabric workspace through Azure Private Link and private endpoints. For Eventstream workloads, inbound traffic can traverse Microsoft's private network infrastructure rather than the public internet, helping reduce exposure and support enterprise security requirements. Workspace administrators can configure inbound networking settings to restrict access to approved networks and workspace-level private links. When public inbound access is disabled, users, applications, and services can access the workspace only through configured private connectivity paths or other allowed network configurations. Feature: Configure inbound networking settings to restrict workspace access to selected networks and workspace-level private links. Unlike tenant-level private link, workspace-level private link allows organizations to apply network isolation only where it is needed. Teams can secure workspaces that contain sensitive, regulated, or business-critical workloads without requiring tenant-wide networking changes. Workspace-level Private Link is supported for Eventstream, allowing organizations to build and operate real-time streaming solutions through approved private network connections. This helps customers align Eventstream deployments with corporate security, governance, and compliance requirements while maintaining a consistent experience for authorized users and services. By providing workspace-specific network controls, Workspace-level Private Link offers greater flexibility for managing connectivity across Fabric environments. Organizations can selectively protect critical workloads, enforce network boundaries, and support secure real-time data streaming without impacting other workspaces that do not require private connectivity. To learn more, refer to the Overview of Microsoft Fabric eventstreams documentation. Variable Library support for Eventstream (Preview) As Fabric solutions grow, managing configuration across environments can become increasingly complex. Development, test, and production environments often require different connections, item references, parameters, and settings. Maintaining these values across multiple Fabric items can introduce duplication, increase manual effort, and make deployments harder to manage. Variable Library (Preview) provides a centralized way to create, manage, and share configuration values across supported Fabric workspace items. Instead of embedding environment-specific settings directly within each item, teams can define reusable variables once and consume them wherever they are needed. Variable libraries support multiple value sets, allowing organizations to maintain different configurations for development, test, and production environments from a single location. Variable libraries help separate configuration from business logic, making solutions easier to manage as they move through the application lifecycle. When a shared configuration value changes, teams can update it centrally rather than modifying the same setting across multiple items. Figure: Store and manage connection and item references in Variable Library, allowing the same Eventstream to be deployed across environments without manual connection updates. Variable Library integrates with Fabric application lifecycle management capabilities, including Git integration, deployment pipelines, and Fabric APIs. Teams can associate different value sets with different deployment stages, helping ensure the correct configuration is used as content moves between environments. Variable libraries can be used to manage values such as connections, item references, query parameters, and other reusable configuration settings. This centralized approach helps reduce duplication, improve consistency across workspace items, and simplify configuration management for large-scale Fabric solutions. For organizations adopting CI/CD practices, Variable Library provides a scalable foundation for managing configuration throughout the development lifecycle. By centralizing shared settings and supporting environment-specific value sets, teams can streamline deployments while maintaining control over configuration changes across their Fabric environments. To learn more, refer to the Overview of Microsoft Fabric eventstreams documentation. Workspace Monitoring Azure Stream Analytics Log Support for Eventstream When an Eventstream processes, transforms, or routes data, issues such as malformed input, query errors, type-conversion failures, and destination-access problems can interrupt or affect data processing. Without detailed processing logs, teams may know that an Eventstream is not behaving as expected but lack the information needed to understand what happened and where the problem occurred. With Workspace monitoring ASA log support for Eventstream (Preview), customers can access Eventstream processing logs through the Workspace Monitoring KQL database. These logs provide additional context about warnings, errors, recovery events, and other important conditions encountered while Eventstream processes and delivers data. Processing logs are available when an Eventstream uses processing logic or sends data to a Lakehouse, Activator, or Eventhouse in push mode. This can help teams investigate input deserialization errors caused by events that do not match the expected format, query runtime failures encountered while applying Eventstream processing logic, and type-conversion failures that occur when processed values cannot be written using the expected destination type. Teams can also use these logs to identify late, early, or out-of-order events that do not meet configured event-time policies, output access or connection problems affecting the delivery of processed data, and warnings or recovery events generated when Eventstream responds to processing problems or restarts. Feature: Enable Eventstream activity logging to automatically surface diagnostic events in Workspace Monitoring, allowing teams to query operational logs, investigate failures, and troubleshoot streaming workloads through the EventStreamDiagnosticLogs table. To use this capability, Workspace Monitoring must first be configured for the Fabric workspace. Users can then open the Monitoring settings for an individual Eventstream and enable Log Eventstream activity. Monitoring is enabled separately for each Eventstream, so users can control which Eventstreams send processing logs to the workspace’s monitoring KQL database. By bringing Eventstream processing logs into Workspace Monitoring, customers can investigate processing failures directly within the Fabric workspace, identify the affected operation, and use detailed diagnostic context to accelerate troubleshooting. To learn more, refer to the Overview of Microsoft Fabric eventstreams documentation. Real-Time Dashboard Copilot creation of Real-Time Dashboard (Preview) Copilot-powered Real-Time Dashboard creation helps organizations move from data to actionable monitoring experiences in minutes. Instead of starting with a blank canvas, users are guided by AI-generated starter prompts that are automatically grounded in the data available in their Eventhouse. These prompts are designed around common business scenarios and user personas, such as business analysts looking for trends and correlations, operations managers monitoring service health and utilization, or decision makers tracking key performance indicators and emerging issues. Users can select a suggested prompt that best matches their goals or modify the prompt to capture more specific requirements. This natural language approach allows users to express their intent directly, describing the outcomes, metrics, and operational questions they want the dashboard to address. Copilot then combines that intent with an understanding of the available data to generate a Real-Time Dashboard with relevant visualizations, metrics, and layout recommendations. Figure: Describe your goals, let Copilot build the dashboard. By bridging the gap between business objectives and technical implementation, Copilot accelerates dashboard creation while helping ensure the resulting experience is aligned with the user's needs from the outset. The generated dashboard opens ready for review and customization, giving users full control to refine, extend, and operationalize the experience. The result is a faster, more intuitive path to insights, enabling teams to focus less on dashboard setup and more on monitoring and acting on what matters most. To learn more, refer to the Generate Real-Time Dashboard Using Copilot documentation. AI-native custom visual builder in Real-Time Dashboard (Preview) AI Custom visual brings a new way to create custom dashboard experiences in Real-Time Dashboard by allowing users to describe the visual they need in natural language and generate it instantly, without writing visualization code. Figure: Create custom dashboard visuals using natural language with Copilot. Instead of being limited to a fixed catalog of charts, teams can create purpose-built, responsive HTML experiences tailored to the specific operational insight, workflow, and audience they support. This enables organizations to move beyond generic dashboards and design visual experiences that match how decisions are made, whether that is a service health command center, an operations status board, or a workflow-specific monitoring experience. By combining AI-assisted query generation and visualization creation, AI Custom visual reduces the effort required to assemble dashboards while making it easier to communicate complex operational context in the most effective format. The result is a more flexible, insight-driven dashboard experience that adapts to the needs of each scenario rather than forcing every problem into a standard chart. To learn more, refer to the AI Custom visual in Real-Time Dashboards documentation. Real-Time Dashboards with Ontology as a source (Preview) Real-Time Dashboards can now use Fabric Ontology as a data source, bringing an organization’s business entities, properties, and relationships directly into real-time visualizations. Dashboard authors can create tiles that draw from one or more related ontology entities, apply filters and aggregations, and then use the familiar Real-Time Dashboard experience to configure visual types, axes, series, legends, and formatting. By building on the shared business context defined in an ontology, dashboards can present real-time insights using terminology and relationships that users already understand. Figure Create dashboard using Ontology item as a source. Copilot is front and center in the authoring experience, making it easier to move from a business question to a working dashboard tile. Authors can describe the insight they want in natural language, and Copilot creates the tile and provides queries that access the Ontology’s underlying data sources. Users can review and refine the generated query and visualization, reducing the need to understand the structure or query language of each underlying source. Figure: Use NL to create a dashboard tile. This integration helps teams move more quickly from governed business context to operational insights, while preserving the relationships defined in Ontology throughout query and tile creation. To learn more, refer to the Ontology as a source for Real Time Dashboard documentation. Activator KQL/SQL query visibility in Activator UI (Generally Available) Fabric Activator makes it easy to create alerts and automated actions from streaming and operational data. As organizations increasingly use KQL and SQL queries to power Activator alerts, understanding the logic behind those alerts becomes critical. With query visibility in Activator, users can now view the underlying KQL or SQL query directly from the Activator experience. Figure: View and validate KQL/SQL queries directly from Activator. The "Manage source" tab in the Activator UI now displays the full KQL query in a read-only code editor. You can see source details including the Real-time Dashboard link, KQL Database link, query run frequency, connection status, and the complete KQL query with syntax highlighting. To learn more, refer to the Create Activator alerts from KQL Queryset documentation. Create and manage rules from OneLake catalog & Workspace (Preview) Users can now create and manage Activator rules directly from the OneLake catalog and Workspace view. Whether you're starting from scratch or using a pre-built template, you can quickly automate actions and workflows across your Fabric items with just a few clicks. Supported item types and templates User-Defined Functions (UDFs) Create and manage rules for UDFs directly from the OneLake catalog or workspace experience. Pipeline Automate action when Pipeline run failed Automate action when Pipeline run succeeded Trigger Pipeline runs when specific event happens Notebook Automate action when Notebook run failed Automate action when Notebook run succeeded Trigger Notebook runs when specific event happens Spark Job Definition Automate action when Spark Job Definition run failed Automate action when Spark Job Definition run succeeded Trigger Spark Job Definition run when specific event happens KQL Database Automate action when a file or folder is created in KQL Database Automate action when a file or folder is deleted in KQL Database Lakehouse Automate action when a file or folder is created in Lakehouse Automate action when a file or folder is deleted in Lakehouse Warehouse Automate action when a file or folder is created in Warehouse Automate action when a file or folder is deleted in Warehouse Mirrored database Automate action when a file or folder is created in Mirrored database Automate action when a file or folder is deleted in Mirrored database SQL database Automate action when a file or folder is created in SQL database Automate action when a file or folder is deleted in SQL database Figure: Create and manage rule templates for Pipeline in OneLake catalog. To learn more, refer to the Create and activate a Fabric Activator rule documentation. Trigger Copy job as an action (Generally Available) Modern data workflows often begin when a business event occurs. With Copy job actions in Activator, organizations can automatically start data movement processes the moment a monitored condition is met. Instead of manually launching a copy operation or building additional orchestration layers, users can directly connect real-time business signals to Fabric Data Factory Copy jobs. This creates faster event-driven data pipelines while reducing operational overhead. Figure: Automatically start Fabric Copy jobs when real-time conditions are detected. To learn more, refer to the Trigger Fabric items documentation. Trigger Dataflow as an action (Generally Available) Many organizations rely on Dataflows to prepare and transform analytical data. Activator now supports Dataflow refresh as an automated action, enabling real-time business events to initiate data preparation processes immediately. Rather than waiting for scheduled refreshes, teams can react to operational changes as they occur, ensuring that downstream reports, analytics, and dashboards always use the most current data available. Figure: Automatically refresh Dataflows when operational events occur. To learn more, refer to the Trigger Fabric items documentation. Trigger UDF as an action (Generally Available) Every business has unique requirements that cannot always be addressed through standard notifications or predefined actions. Activator's User Data Function (UDF) action enables developers to execute custom business logic whenever a rule fires. Running User Data Functions (UDFs) from your Activator rules enables fast, programmatic responses when issues occur. For example, you can automatically create a support ticket, incident, or work item when a threshold is exceeded, passing along the context such as entity IDs, measured values, and timestamps. UDFs can also trigger predefined actions like restarting a service, adjusting a configuration, or invoking an internal automation or runbook, helping teams respond quickly and consistently without manual intervention and integrate Activator directly into existing operational workflows. To learn more, refer to the Use Function as Activator action documentation. Stateful conditions in Activator for Event based triggers (Generally Available) Many real-world scenarios require understanding changes over time rather than evaluating events independently. Stateful conditions enable Activator to track event state transitions. Activator can now evaluate patterns such as status changes, prolonged conditions, and sequential events, making it easier to model complex business processes. When to use stateful conditions: Detect when a machine enters a failure state. Track device status changes from Healthy → Warning → Critical. Monitor inventory levels dropping below thresholds. Figure: Trigger actions based on changes in event state over time. To learn more, refer to the stateful vs. stateless rules documentation. Dynamic thresholds in Activator (Generally Available) Activator rules can now use another object property as the threshold value, instead of relying only on a fixed number. This makes it possible to create rules that adapt to each object you monitor. This is useful whenever allowable limits vary between objects, for example, equipment with asset-specific operating limits, buildings with different temperature limits, or customers with individually configured alert thresholds. For example, a building object might include both a temperature property and a maximumAllowedTemperature property. You can create a rule that activates when temperature is greater than maximumAllowedTemperature, so each building is evaluated against its own configured limit rather than a single threshold shared by every building. To configure a dynamic threshold, open the object in Activator and select the property you want to monitor. Create a new threshold-based rule, then use the property selector in the threshold field to choose another property from the object. Complete the remaining rule settings and save. Figure: Select an object property as the threshold value in an Activator rule. To learn more, refer to the Detection conditions for Activator documentation. Eventhouse Large Messages support in Eventstream and Eventhouse (Preview) Bring large event payloads into Fabric in real time Applications and services are increasingly generating richer events that can contain large JSON payloads, detailed application data, and other large values. Until now, the size of individual values could be a limitation when streaming data from Eventstream and indexing it properly in Eventhouse. Large message support enables Eventstream and Eventhouse to process larger event payloads. New items default to a 5 MB event size limit, and customers can increase this value through artifact settings when larger messages are required. Feature: Configure the maximum event size for an Eventstream by using the Event Size setting, which supports values between 1 MB and 20 MB. This enables end-to-end scenarios where large messages can flow from Eventstream into Eventhouse without requiring you to split the message just to meet the default size limit. When to use Large Message Support Large Message Support gives you the flexibility to keep a large payload together when that's what your application needs. For example, storing and processing a large JSON document in a single Eventhouse string or dynamic column. When your scenario benefits from a more structured data model, you can transform the payload into separate columns using Eventstream's Event Processing Editor before ingestion, or an Eventhouse update policy after ingestion. This can also be a more efficient approach for large payloads, as working with smaller, structured values can reduce memory consumption. Large Message Support gives you the flexibility to choose the approach that best fits your scenario. Keep large payloads intact when preserving the original message is important or transform them into a structured schema when downstream analytics require it. Either way, you can now support larger event data volumes within the same end-to-end Real-Time Intelligence experience in Fabric. Feature: Eventhouse displays cells with data of 20 MB. The text is fully available during query time and when using the Copy full value button. Large Message Support (Preview) is now available as a feature in Microsoft Fabric Eventstream and Eventhouse. To learn more, refer to the Eventstream and Eventhouse documentation. Granular Sharing for Shortcut Databases in Eventhouse (Generally Available) As organizations scale their Eventhouse deployments, they often need to share data across teams without exposing an entire database. While shortcut databases (followers) make it easy to bring data into Eventhouse from another Eventhouse or from an Azure Data Explorer (ADX) cluster, many customers have asked for more granular control over what gets shared. With this update, you can now create a shortcut database that includes only the specific entities you choose, rather than all entities from the source database. Whether the source is an Eventhouse database or an ADX database, you can selectively share only the tables, shortcut tables, materialized views, and functions that are relevant to your consumers. Share only what you need from Eventhouse or ADX When creating a shortcut database, you can now select exactly which entities to include from the source database. This works regardless of whether the source database resides in another Eventhouse or in an Azure Data Explorer cluster. This allows teams to create targeted sharing experiences for different audiences. For example, a central Eventhouse can expose only a curated set of business-ready tables to downstream teams, while keeping operational, staging, or internal datasets private. Another common scenario is bringing Azure Data Explorer data into Fabric. Organizations can share a subset of monitoring, telemetry, or network analytics tables with business users in Eventhouse while keeping the remaining source tables outside the shortcut database. Figure: Select specific entities from a source KQL DB. To learn more, refer to the OneLake shortcuts documentation. Update Policy on Accelerated Shortcuts in Eventhouse (Preview) We are expanding update policies in Eventhouse to work directly on Query Acceleration Policy (QAP) enabling OneLake shortcuts in Microsoft Fabric Real-Time Intelligence. With this update, you can attach an update policy to accelerated shortcuts and have transformations run continuously as new data lands in the underlying lake. Capabilities Continuously transform and enrich data into delta tables without standing up a separate pipeline. React to changes in lake-resident delta tables in near real time, including filtering, projection, and joining with other Eventhouse tables. Build downstream KQL tables, materialized views, and alerts on top of always fresh, transformed data. Update policies on accelerated delta tables are configured the same way as on native Eventhouse tables, so existing tooling and KQL knowledge carries over directly. No additional setup is required beyond having QAP enabled on the source delta table. To learn more, refer to expanded update policies. Entity Diagram in Eventhouse (Generally Available) As Eventhouse and its KQL databases grow, it can become harder to understand how tables, functions, materialized views, shortcuts, update policies and data sources are connected. The Entity Diagram provides a visual way to see these relationships and understand how data flows through your database. With the latest updates, we're making it easier to get to the diagram, focus on what matters, and troubleshoot issues. Figure: Entity Diagram in Eventhouse. Start from the entity you're working with The Entity Diagram is available from the main KQL database page, and you can now also open it directly from a specific table page or function page. When you open it from a table or function, the diagram automatically provides a focused view centered on that entity and its related items. This makes it easy to understand what feeds the entity, what depends on it, and how it connects to the rest of your database. Filter the diagram to what you need For larger databases, seeing everything at once can be overwhelming. From the main KQL database page, you can now use the Entity Diagram to explore your database more broadly. Filter the diagram by entity type and choose which entities to show, including tables, shortcuts, materialized views, functions, or data sources. This is particularly useful for tasks such as investigating dependencies before changing a table schema, tracing a materialized view back to its source tables, or focusing on the data sources involved in your ingestion flow. Figure: Choose which entities to include in the diagram. More visibility into data sources We've also expanded the data sources shown in the diagram to include Azure Storage, Azure Event Hubs, and Business Events. You can now see additional details about a data source, including its mapping, data format, connectivity status, and the number of records ingested. If a connection is no longer needed, you can delete it directly from the Entity Diagram. Figure: Different data sources are shown, including the number of records ingested for the selected time frame. From understanding to action The Entity Diagram brings these capabilities together in one place, giving you a clearer picture of your KQL database and the data flowing through it. Whether you're exploring dependencies, troubleshooting ingestion, or checking the impact of a change, you can quickly move from a high-level view to the specific entity or connection you need to investigate. To learn more, refer to the View an entity diagram in KQL database documentation. New Workspace Monitoring logs for Eventhouse: throttling events, sub-optimal size, and scale-out events (Preview) Eventhouse now provides three new logs in Workspace Monitoring, giving admins and Eventhouse users deeper visibility into performance, capacity utilization, and scaling activity. With these insights, you can spot potential issues early, understand what’s happening in your Eventhouse, and act before they impact your workloads. Understand when your Eventhouse is being throttled The Fabric Eventhouse Capacity Throttling Events log shows when an Eventhouse enters throttling and records the different throttling stages. This helps you identify when your workload is hitting capacity limits and understand when capacity or workload optimization may be needed. Instead of discovering performance issues through a slow query or failed operation, you can use the telemetry to see that throttling occurred and investigate what was happening at the time. Know when your Eventhouse is undersized At the time of capacity throttling, an Eventhouse may remain at a smaller size to exit the throttling state and maintain availability. Scaling up again could cause the capacity to become throttled again, creating a recurring cycle of scale-out and throttling. The Sub-Optimal Eventhouse Size log makes these situations visible. It helps you understand when the current capacity is no longer an optimal fit for the workload and gives you a signal to take action. Depending on the situation, you may want to add capacity, reduce the workload or hot cache, or restart the capacity. This gives admins a way to identify potential capacity issues before they turn into ongoing performance problems. Understand why your Eventhouse scaled out Eventhouse can scale out when additional resources are needed. The new Eventhouse Scale-Out Events log provides a daily summary of scale-out activity and the reasons behind it. You can see whether the scale-out was triggered by: Minimum consumption settings High memory, CPU, or cache usage Increased ingestion load Increased query acceleration load Scale-out events are aggregated and reported every 24 hours, giving you a simple way to understand scaling behavior over time. Get quick insights with a Real-Time Dashboard You don't need to build your own queries or dashboards to get started. A Real-Time Dashboard template is available from the Workspace Monitoring Database ribbon, giving you a quick overview of the new Eventhouse telemetry. The dashboard brings the key signals together, so you can quickly see what's happening with throttling, sizing, and scale-out activity. From there, you can also set up alerts on the logs using Activator to be notified when specific conditions occur. Figure: A Real-Time Dashboard template is available from the Workspace Monitoring Database ribbon Get started Together, these three logs give you a better picture of what's happening with your Eventhouse workload, from capacity pressure and throttling to sizing and scaling. For admins, this means better visibility across the workspace. For Eventhouse users, it means a clearer way to understand workload behavior, investigate performance issues, and make informed decisions about capacity. To learn more, refer to the Eventhouse monitoring documentation. Support for workspace outbound access protection (Generally Available) OAP helps organizations reduce the risk of data exfiltration by controlling which external resources Eventhouse and other Real-Time Intelligence items can access. When OAP is enabled, outbound traffic from the workspace is blocked by default. Workspace administrators can then permit access to approved destinations by creating data connection rules. Combine outbound access protection with Private Link Organizations can use OAP together with Private Link to protect traffic in both directions. Private Link controls inbound access to Eventhouse, while OAP controls outbound access from the workspace. This combination helps organizations establish stronger network boundaries for Eventhouse workloads and meet the requirements of security-sensitive and regulated environments. Run cross-cluster queries against approved destinations Eventhouse can run cross-cluster queries against Azure Data Explorer clusters and Eventhouses located in other workspaces when the destination has been explicitly allowed. This capability enables users to analyze distributed operational and real-time data while retaining control over the external systems that a protected workspace can reach. Creating a data connection rule permits the network connection but doesn't grant access to the destination. Users must still have the required permissions for the target cluster, Eventhouse, and database. Ingest data from Azure Storage Eventhouse supports both one-time and continuous ingestion from approved Azure Blob Storage and Azure Data Lake Storage accounts. Administrators must allow the storage account before users ingest data or configure a continuous data connection. Streaming ingestion from approved Azure Event Hubs destinations is also supported. These capabilities enable organizations to bring batch and streaming data into Eventhouse without allowing unrestricted outbound connectivity. Access Fabric data securely Eventhouse continues to support Eventstream, OneLake, and follower database scenarios when OAP is enabled. Access to these resources within the same workspace doesn't require an outbound access rule. Access to supported resources in another workspace requires a rule that allows the destination workspace. This approach keeps common Fabric data flows available while ensuring that cross-workspace access is explicitly approved. To learn more, refer to the Workspace outbound access protection for Eventhouse documentation. Workspace-level Private Link (Generally Available) This release expands the Eventhouse experiences that work in private-link-enabled workspaces, helping organizations ingest, query, monitor, and reuse real-time data while keeping network traffic within approved private connections. Create follower databases Users can now create follower databases in a private-link-enabled workspace. A follower database provides a read-only shortcut to a source database, allowing teams to query and analyze its data without copying or reingesting it. This capability supports secure data sharing between Eventhouse environments while the source remains responsible for data storage and ingestion. Pull events with Eventstream Eventhouse can now pull data from Eventstream when workspace-level Private Link is enabled. Organizations can build real-time ingestion flows that deliver events to KQL databases through private connectivity, extending Eventstream scenarios to workspaces that don't permit public inbound access. Monitor protected workspaces Workspace monitoring now works with Eventhouse in private-link-enabled workspaces. Administrators and developers can use monitoring Eventhouse to investigate query and ingestion activity, analyze performance trends, troubleshoot failures, and build operational dashboards without weakening the workspace's network isolation. Stream data with the Spark connector The Spark connector now supports streaming ingestion into Eventhouse through workspace-level Private Link. Spark applications can continuously write events to KQL databases over private connections, enabling low-latency analytics for streaming data produced by data engineering and data science workloads. Run cross-cluster queries Users can run cross-cluster queries involving Eventhouses protected by workspace-level Private Link. This capability makes it possible to analyze data distributed across Eventhouse and Azure Data Explorer environments without consolidating it into a single database. Standard database permissions and the required private network connectivity still apply. Generate KQL from natural language The KQL queryset side pane can now generate KQL from natural-language requests when the connected Eventhouse uses workspace-level Private Link. Users can describe the data they want to explore and receive a generated query that they can review, refine, and run, making real-time data analysis more accessible while preserving private access to the underlying Eventhouse. Together, these enhancements extend core Eventhouse workflows to security-sensitive and regulated environments, allowing teams to work with real-time data through private connectivity from ingestion and monitoring to querying and AI-assisted analysis. To learn more, refer to the Secure inbound connections with Tenant and Workspace Private Links documentation. Cluster-level Customer-Managed Key Support (Generally Available) Eventhouse now supports customer-managed key (CMK) encryption for dedicated physical clusters, giving organizations direct control over the Azure Key Vault keys used to protect Eventhouse data and metadata at rest. When CMK is enabled for a Fabric workspace, Eventhouses in that workspace move to physical clusters so the service can apply the customer-managed key consistently. This helps organizations meet security, governance, and regulatory requirements that call for customer-controlled key creation, access, rotation, and auditing. If access to the key is revoked, Eventhouse automatically suspends access to the protected resource and removes cached data. When key access is restored, the Eventhouse resumes automatically. This gives security teams an immediate way to block access to encrypted data while maintaining a recoverable operational path. Before enabling CMK, plan for the dedicated-cluster resource requirement. Eventhouse scales to a minimum of 16 Capacity Units, which can increase capacity consumption. CMK protects Eventhouse data and metadata at rest; queries themselves are not encrypted with the customer-managed key. To learn more, refer to the Data Encryption with Customer-Managed Keys in Fabric Eventhouse documentation. Maps Connect to External Geospatial Services with Feature Service Support (Preview) Feature Service Support (Preview) for Fabric Maps enables organizations to work directly with authoritative geospatial data managed in hosted GIS platforms and standards-based services. By connecting to data where it already resides, organizations can reduce duplication, avoid unnecessary ingestion pipelines, and simplify data management. Fabric Maps supports direct connectivity to three widely adopted service standards: OGC Web Feature Service (WFS) for interoperable access across government, research, and multi-vendor geospatial environments. OGC API - Features, a modern, web-native standard for REST-based interoperability and scalability. Esri Feature Services used across ArcGIS deployments and enterprise GIS infrastructures. Once connected, Fabric Maps discovers available feature layers and collections. Map builders can configure server-side queries to retrieve the data relevant to their scenario, including selecting output fields, applying filters and temporal constraints, and setting result limits supported by the source service. This helps reduce unnecessary data transfer while making large enterprise datasets easier to explore. External feature data integrates with familiar Fabric Maps capabilities. Depending on geometry type, data can be displayed using Bubble, Marker, Line, Polygon, or Heatmap visualizations. Builders can also use data-driven styling, legends, filters, and layer-management actions such as visibility controls, renaming, duplication, reordering, and deletion. These capabilities allow organizations to combine authoritative GIS information with Fabric analytics workflows and create consistent location-intelligence experiences across Lakehouse, Eventhouse, and external geospatial data sources. For configuration details and supported capabilities, refer to the Create Layers from External Feature Services documentation. Bring Fabric Maps into Real-Time Dashboards (Preview) Operational data often answers two connected questions: what is happening, and where is it happening? With the Fabric Maps integration, you can add rich geospatial context directly to your Real-Time Dashboards and view location-based insights alongside real-time metrics, trends, and events. You can add a Fabric Map to a Real-Time Dashboard through two convenient workflows. When editing a dashboard, select the Fabric Map visual and choose an existing map from the item picker. If you do not already have a suitable map, you can create one in a separate browser tab and return to the dashboard to add it. Alternatively, you can start directly from Fabric Maps and pin a configured map to a new or existing Real-Time Dashboard. Figure: Pin a Fabric Map to an existing or new Real-Time Dashboard. Once added, the map appears as a self-contained dashboard tile that you can position, resize, and arrange alongside charts, KPI visuals, and tables. Its data sources, queries, layers, filters, styling, and other authored configurations continue to be managed in the source Fabric Map item. This allows authors to maintain the Fabric Map as a single source of truth instead of rebuilding the same geospatial logic across multiple dashboards. Updates made to the source map are automatically reflected wherever the map is used, reducing duplicate work and helping teams maintain a consistent experience. Figure: A Fabric Map embedded alongside KPIs, charts, and operational data in a Real-Time Dashboard. Dashboard viewers can interact with the map without changing its authored configuration. They can pan and zoom, hover over and select features, change the basemap, show or hide layers, and use unlocked filters during their session. Authors can also lock filters to ensure viewers always see the intended baseline data scope. Whether you are monitoring transportation networks, field operations, infrastructure, public safety, retail activity, or live events, Fabric Maps can reveal geographic patterns that may be difficult to identify through charts alone. By combining reusable geospatial context with real-time operational insights, teams can better understand where conditions are changing and respond more effectively. To learn more, refer to the Create a Real-Time Dashboard and Pin a Map to a Real-Time Dashboard documentation. Set alerts directly from table visuals in Fabric Real-Time Dashboards Fabric Activator lets users create no-code alerts based on data conditions in Real-Time Dashboards (RTD). The Set Alert/Add Alert experience now supports table visuals, helping users act when data requires attention while continuing to support all existing visual types. Turning table rows into actionable signals The tables tile in the RTD provides a detailed view of operational data, with each row representing various event records. Users can now turn these records directly into alerts. The Add alert option appears on table tiles and uses the familiar alert-creation workflow, enabling users to move from analysis to action without learning a new process. Figure: Add alert entry point in RTD toolbar and the visual-selection menu, now with table support. Start from the table visual: Select a supported table tile and choose Add alert. The pane opens with controls for the condition, value, and timestamp. Figure: Add alert entry point shown when hovering over an RTD table tile. Use the timestamp that matches the scenario: The experience supports ISO 8601 UTC timestamps and lets users select a relevant timestamp column, such as ingestion time or event time. This aligns alert evaluation with when the underlying event occurred. Figure: Timestamp options in the Activator rule pane. Ingestion time reflects when data arrived in the system, while event time reflects when the business event occurred. For delayed data, those moments may differ. Selecting the appropriate timestamp gives users control over the rule’s time semantics, whether freshness or the timing of real-world activity matters most. A simpler path from observation to action Alert support for table visuals strengthens a core promise of real-time intelligence: enabling people to act while changes still matter. Integrating alert creation and timestamp selection directly into the table experience shortens the path from insight to action. To learn more, refer to the Create Activator alerts from Real-Time Dashboard documentation. Fabric IQ Conversational Analytics Fabric IQ MCP Server (Generally Available) Fabric IQ brings governed business context from Microsoft Fabric into AI experiences, helping people and agents’ reason over trusted business data. The Fabric IQ MCP server enables MCP-compatible AI clients, agents, and applications to access trusted business data in Microsoft Fabric through a standardized MCP endpoint. Starting with support for Power BI reports and semantic models, Fabric IQ MCP provides a foundation for bringing governed business context into AI experiences, making it easier to build AI-powered applications without creating custom integrations for every client or application. With the Fabric IQ MCP server, AI applications can discover Power BI reports and semantic models, inspect report and semantic model metadata, search for relevant business data, and execute DAX queries against authorized semantic models. These capabilities help developers build experiences that can answer business questions using organizational data already governed within Microsoft Fabric. Figure: Fabric IQ MCP tools enable AI applications to discover and query Power BI reports and semantic models using governed business data in Microsoft Fabric. As part of Microsoft’s IQ family, Fabric IQ exposes its MCP endpoint using the family’s standard domain naming convention: .svc.cloud.microsoft. This consistent endpoint model is backed by a shared, centrally managed security foundation that helps protect how AI applications and agents access business data. As threats evolve, shared protections can be strengthened centrally across participating IQ services. These protections complement Fabric’s authorization and data governance: existing user permissions, including row-level and object-level security, remain enforced by Fabric. This release also introduces support for versioned tool contracts, helping developers adopt new capabilities while maintaining compatibility with existing integrations. Applications can use the default tool contract version or pin to a specific released version when more predictable behavior is required. Fabric IQ MCP is designed to bring trusted business data and context into AI clients through a standardized MCP interface. Starting with support for Power BI reports and semantic models, Fabric IQ MCP provides a foundation for connecting AI applications to governed business data in Microsoft Fabric. Stay tuned for expansions to the breadth of content the Fabric IQ MCP can work with. As the name implies, we’ll be expanding from Power BI models to support Fabric ontologies, and the breadth of One Lake via Fabric data agents. To learn more and get started, refer to the Fabric IQ MCP server documentation. Expansion of Fabric IQ to include answers from data agents and ontologies (Preview) The public Skills for Fabric repo continues to be where we share early versions of feature development for Fabric IQ data answers. We are expanding from Power BI reports & semantic models to answer questions grounded in specific ontologies and data agents. This expansion enables Fabric Skills to help users uncover curated insights from across the full breadth of OneLake. Figure: Fabric IQ answers business questions using insights from semantic models, data agents, and ontologies across Microsoft Fabric. As we move forward, this foundation will support experiences where users can ask business questions naturally while Fabric determines whether a report, semantic model, data agent, or ontology is best suited to answer. To learn more, refer to the agent skills for Fabric documentation. Visualizations in the Fabric Data Agent (Generally Available) Fabric data agents can return interactive charts and graphs alongside text and table-based answers, helping users quickly identify trends, patterns, and outliers without leaving the conversation. Users can request a specific visual or ask a question that implies one. Supported visuals include line, bar, column, pie, scatter, and area charts, including multi-series and stacked variations, and they are available for all data source types supported by the data agent. The following GIF shows a Fabric data agent returning several types of interactive visuals in response to user questions. Figure: A Fabric data agent returns interactive line, column, and area charts, with additional details available on hover. To learn more, refer to the Get visual responses from a Fabric data agent documentation. Scale Business Context with Topics in Fabric Data Agents (Preview) Topics provide a scalable way to give Fabric data agents large, subject-specific guidance for generating accurate SQL—up to one million characters per supported data source. Authors can organize business definitions, tables, relationships, filters, and calculation rules into sections for areas such as sales, inventory, or customer retention. Unlike data source instructions, which are sent to the query-generation tool every time the source is used, the data agent searches Topics and sends only the sections relevant to the user’s question to NL2SQL. This retrieval-based approach reduces irrelevant context, supports much richer guidance, and makes complex instructions easier to organize and maintain, while data source instructions remain the right place for universal rules that must apply to every query. Figure: Data Agent creators can provide richer instructions under the new Topics experience. To learn more, refer to the configuring Fabric data agents documentation. Model Upgrades on the Data Agent Runtime (Preview) The Fabric data agent runtime (Preview), now runs on the newer 5.6 model, delivering improvements in response quality, accuracy, and latency across the end-to-end experience. The upgrade powers the agent’s orchestrator—including question rephrasing and planning—as well as source routing, Code Interpreter, natural-language querying for Power BI semantic models, and natural language to SQL. Applying the newer model across these components helps the agent interpret intent more effectively, select the right tools and data sources, generate more reliable queries, and return higher-quality answers faster. Switch your data agent to the preview runtime to evaluate these latest improvements before they become available in the standard runtime. Figure: Users can switch to the Preview runtime to use the newest 5.6 updates. To learn more, refer to the Fabric data agent runtimes documentation. Ontology as Context Source (Preview) Ontology as a Context Source in Data Agent uses an enterprise Ontology’s entities, relationships, definitions, mappings, synonyms, and source bindings to help Data Agent generate more accurate and verifiable queries against underlying engines such as SQL, KQL, and DAX. In this initial release, Ontology becomes a first-class, read-only context source in Data Agent, giving customers clearer visibility into associated data sources, run steps, and generated queries, along with support for synchronized context, diagnostics, evaluation, and additional Data Agent configuration for selected underlying sources. To learn more, refer to the Ontology as Context documentation. Fabric data agents now return up to 1000 rows (Preview) One of the most common requests we hear is about row limits. Previously, a Fabric data agent returned at most 25 rows with its answer, which is fine for a quick number but not enough when you want to see the whole result. Customers told us they want a full response so they can review it offline or run their own analysis on top of it. That limit is now lifted in the preview runtime. Switch your agent to the preview runtime and the response comes back as a summary followed by a tabular preview of up to 1000 rows. This is the first step, and more is coming. Next, we plan to let you download the full response as an Excel file, with sensitivity labels carried through to the file. We also want this experience to be consistent across all integrations and consumption channels, so you get the same behavior no matter where you use your data agent. These improvements are landing over the next few months, so stay tuned. Figure: Fabric data agent to return up to 1000 rows under preview runtime. To learn more, refer to the Data Agent File Support documentation. Monitor and improve data agents with user feedback in Microsoft 365 Copilot (Preview) A Fabric data agent starts with a creator. The creator builds and configures the agent, validates its answers, and publishes it for others to use across different consumption channels. One of the most common requests from customers has been a way for creators to hear directly from the people using their data agents. That’s now possible. The consumer-to-creator feedback loop for Fabric data agents is now in public preview and available through the SDK. When someone uses a published data agent in Microsoft 365 Copilot and gives a thumbs up or thumbs down, that feedback is sent back to the creator. Creators can see what’s working, identify where the agent needs improvement, and use that feedback to continuously make the data agent better. The feedback loop is available in the SDK first, and the same experience will come to the data agent UI later. Microsoft 365 Copilot is the first consumption channel we support, and we are working to bring this to the other consumption channels as well. If you have published a data agent to Microsoft 365 Copilot, encourage the people using it to leave a thumbs up or a thumbs down. The consumer to creator feedback loop only works if they use it. Figure: Leverage Fabric Data Agent SDK to review feedback from Data Agent in Microsoft 365 Copilot. To learn more, refer to the Data Agen Consumer Creator Feedback documentation. Microsoft Fabric data agent now supports Model Context Protocol tasks (Generally Available) When you publish a Fabric data agent, it can be consumed as an MCP server with a single tool. The data agent MCP server now also supports MCP Tasks and follows the latest MCP specification. MCP Tasks allow the data agent to start long-running work without keeping the connection open until the work is complete. The client receives a handle to check the status and resume the work as needed, helping prevent connection time-outs and allowing work to continue even if the client disconnects or restarts. The data agent can also pause to request additional input and then continue the work. To learn more, refer to the Data agent as Model Context Protocol server documentation. Ontology Bring Power BI DAX measures into the Ontology Ontology authors can now bind DAX measures from Power BI semantic models and make those governed calculations available through the ontology. This lets teams reuse existing business metrics instead of redefining them in a separate semantic layer and brings entity relationships, operational context, and analytical measures together. Figure: Seeing Power BI DAX Measures/Metrics on Entity Type Configure page. To learn more, refer to the Ontology Metrics documentation. Add richer business context with metadata Ontology authors can now add descriptions, synonyms, and custom key/value metadata to entity types, relationship types, and properties. This additional context helps people and AI agents understand what a concept means, how it should be used, and how it relates to the language used across different teams and systems. Figure: Viewing and editing Entity Type metadata on Entity Type Configure Page. To learn more, refer to the Ontology Semantic Enrichment documentation. Reuse common concepts with type hierarchies and inheritance Authors can now organize entity types into type hierarchies and create derived entity types that inherit properties and metadata from one or more base entity types. This reduces duplicated modeling and makes it easier to apply a consistent definition across related business concepts. Figure: Choose to inherit from an existing entity type when creating a new entity type. Figure: After creating entity type by inheriting from an existing entity type, check the Inheritance details on the entity type configure page. To learn more, refer to the Ontology Inheritance documentation. Capture business logic with natural-language rules Business logic often lives in documentation, application code, or the knowledge of a few domain experts. Ontology authors can now capture natural-language rules, policies, and constraints directly on entity types, relationship types, and properties. This keeps important operational meaning close to the concepts it governs and gives agents consistent context when interpreting data. Figure: Ontology Rules page showing list of rules created and capability to create new rules. For example, a retail operations team can define rules such as: “A store inventory position is at risk when projected on-hand inventory falls below safety stock before the next scheduled delivery.” “A frozen product has a cold-chain exception when its temperature remains above its maximum storage temperature for more than 20 minutes.” “A promotion must not extend beyond the product’s sell-by date.” These definitions give analytics and agent experiences a shared interpretation of terms such as at risk, cold-chain exception, and eligible for promotion, instead of requiring every user or agent to recreate that logic independently. To learn more, refer to the Ontology Rules documentation. Reuse existing standards with RDF/OWL import and export Organizations that already maintain industry or enterprise ontologies in RDF/OWL can reuse supported core concepts in Fabric IQ Ontology. Authors can import existing concepts to accelerate modeling and export ontology definitions for use in RDF-based tools and workflows. Figure: Entry point for Import. Figure: Results shown after imports are complete. Figure: Entry point for Export. To learn more, refer to the Ontology Import Export documentation. Build and query ontologies conversationally The built-in conversational experience now supports both ontology authoring and data querying. Authors can use natural language to create and manage ontology definitions, while business users can ask questions using familiar domain terminology. The ontology copilot is tuned for semantic and ontology scenarios, improving how questions are grounded in entity types, relationships, hierarchies, metadata, measures, and business rules. Figure: Querying Ontology Agent for actions on Entity Type. Figure: Query Ontology Agent for answers from the Ontology. For example, an author can ask to “Create FrozenProduct as a type of Product, add its required storage-temperature range, and relate it to store inventory and refrigeration units.” A retail operations manager can then ask, “Which high-priority stores in the West have frozen products below safety stock, a recent refrigeration-temperature excursion, and on-shelf availability below target?” Fabric IQ Ontology also provides new Model Context Protocol (MCP) tools for ontology definition management and data querying. Developers can use these tools to bring governed ontology context into external agent workflows, development environments, and evaluation harnesses. To learn more, refer to the Ontology Agent documentation. Organize enterprise concepts with namespaces Ontology authors can now organize related concepts into namespaces. A namespace provides a semantic boundary and qualified identity for ontology concepts, making large models easier to navigate, reducing naming conflicts, and clarifying which business domain owns each definition. Concepts can still reference and reuse definitions across namespaces, allowing teams to organize the ontology by domain without creating disconnected models. Figure: Namespaces entry points on Ontology landing page. To learn more, refer to the Ontology Namespaces documentation. Bind faster and query at source scale By default, Fabric IQ Ontology now generates the semantic graph from the ontology definition without copying bound data into the graph. The ontology becomes available much sooner after binding because it does not need to materialize every entity instance and relationship. Bound data remains in its source and is queried on demand, allowing the semantic layer to scale with the underlying data platform while avoiding data duplication and refresh delays. Figure: Entry point for binding data sources. Figure: Available data sources for binding to your Ontology. To learn more, refer to the Ontology Data Binding documentation. Configurable Ontology graph experiences Fabric IQ Ontology can be configured to create a labeled property graph using the ontology definition and bound data. Users can explore model structure, discover multi-hop connections, trace dependencies, and analyze impact. Note: Graph generation is optional and is not required for ontology querying or agentic experiences. To learn more, refer to the Ontology Graph documentation. Apply enterprise security and network controls Fabric IQ Ontology now integrates more deeply with Fabric security. Authoring and querying respect access to bound data, including OneLake security and source-enforced row-level security (RLS), object-level security (OLS), and column-level security (CLS). Ontology also supports private links, Outbound Access Protection (OAP), and customer-managed keys (CMK), helping organizations use ontology in environments with strict network, data-access, and encryption requirements. To learn more, refer to the Ontology Security documentation. Manage change with built-in versioning Fabric IQ Ontology now includes built-in versioning for ontology definitions without requiring teams to configure Git integration. Version history makes it easier to understand how a model has changed, coordinate updates, and recover from unintended edits while keeping ontology lifecycle management inside Fabric. Figure: Entry point for Ontology Versioning. Figure: Users can create new versions in the side pane. To learn more, refer to the Ontology Versions documentation. Simplified user experience and migration to new experience Fabric IQ Ontology introduces a new authoring experience that makes it easier to migrate existing ontologies and build connected models. A guided migration flow brings existing ontology definitions into the new experience. Authors can then view the complete ontology on a single canvas, making it easier to understand the model and edit concepts in context. The new experience also simplifies data binding and relationship modeling. Authors can bind ontology types and properties to a broader range of data sources in OneLake. They can also create relationships between entity types when the underlying sources do not have unique keys, using either direct relationships or bridge tables. Figure: Entry point for users to start creating a copy of the Ontology in the new experience. Figure: User can review What's better, what’s included, and what to setup before creating an Ontology copy in the new experience. To learn more, refer to the Ontology documentation. Fabric Graph Updates for Flexible, Relationship-Heavy Analysis Ontology makes graph-powered analysis more flexible, configurable, and efficient. Customers can focus the graph on the entities and relationships that matter for a specific business question, instead of treating graph creation as an all-or-nothing step. With incremental synchronization for supported additions, teams can keep graph data current while reducing unnecessary processing, cost, and data movement. This is especially valuable for questions where the answer depends on how things are connected. Fabric Graph adds richer GQL support for shortest paths, variable-length traversal, traversal control, path inspection, query composition, aggregation, and data handling. Customers can express the relationship pattern they want to follow and use unbounded variable-length paths when the graph structure should determine the path depth needed for the analysis. The result is a governed, efficient way to move from semantic modeling to system-wide insight. Organizations can analyze dependencies, multi-hop relationships, operational blast radius, and connected-entity discovery with more transparency and operational efficiency, while only materializing the graph data their scenario requires. To learn more, refer to the New in Fabric Graph documentation. Databases Database Hub (Preview) Database Hub is a new operational experience for managing database estates across Azure, on-premises, Microsoft Fabric, and multi-cloud environments. It provides a unified inventory of database resources, surfaces signals that require attention, and helps teams investigate and act from a single operational surface. As a first step, Database Hub brings together Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure Virtual Machines, Arc-enabled SQL Server, Azure Database for PostgreSQL, Azure Cosmos DB, and Fabric SQL Database capabilities into a unified experience. Customers can view supported resources across their estate in one place, understand what requires attention, and investigate findings across services and environments. Figure: A sample overview page of the Database Hub that allows users to monitor the overall health of their data estate. Database Hub is designed around a summary-to-investigation model. Overview surfaces findings across security, performance, and optimization, while Estate provides a detailed operational view for investigating resources, understanding issues, and determining next steps. The experience respects existing Microsoft Entra ID, Azure role-based access control (RBAC), and native execution boundaries while providing a consistent view across supported database platforms. Database Hub is a platform that brings together experiences, insights, and capabilities for managing Microsoft database estates from ground to cloud. This preview is the first step in that journey. Over time, Database Hub will continue to expand with new capabilities that help customers gain visibility into their operational database estate, improve performance and security posture, streamline operations, and manage database workloads consistently across Azure, Fabric, on-premises, and multi-cloud environments. To learn more, refer to the Database Hub documentation. Database agent (Preview) The new database agents in the Database Hub in Fabric help transform database operations from reactive monitoring to intelligent operations. By continuously analyzing performance, availability, workload health, and cost signals, agents surface prioritized recommendations, accelerate troubleshooting, and help teams resolve issues faster. Starting with SQL and PostgreSQL in Azure, database agents are built with governance in mind, they operate within existing role-based access controls, approvals, and auditing frameworks. Figure: Database Agent Settings Page used to enable agent and databases that it will monitor. Figure: Agent Policy Page used to configure which policies the agent will run against the selected databases. Figure: Issue Details explain the issue that was detected by the agent and provide recommendations details on how to mitigate the issue. Looking ahead, database agents will also help power AI experiences by exposing database expertise through MCP and skills, making trusted operational data more accessible to applications and intelligent agents. Azure Cosmos DB Mirroring in Microsoft Fabric Now Supports Virtual Network Data Gateways Fabric Mirroring now connects to Azure Cosmos DB accounts secured by private endpoints or virtual networks through a virtual network data gateway that runs inside your own virtual network. Public network access stays disabled throughout setup and replication, eliminating Fabric IP allowlist management while preserving your existing network security boundaries. To learn more, refer to the Cosmos DB Fabric Mirroring documentation. Change Event Streaming for SQL database in Microsoft Fabric (Preview) SQL database in Fabric already replicates data to OneLake automatically for analytics. Change Event Streaming (CES) adds a complementary, near-real-time path: it streams committed row-level changes - inserts, updates, and deletes from your Fabric SQL database directly to Fabric Eventstream. This offers a near-real-time data continuum inside Fabric: SQL database → CES → Eventstream → Real-Time Intelligence, without external data transport and messaging infrastructure to provision or manage. CES uses transaction log-based capture to publish changes as structured JSON events following the CloudEvents standard. There is no polling, no external connector to manage, and no CDC or change tracking to configure; SQL pushes changes directly to the configured destination. From Eventstream, downstream processes can consume the data independently: real-time dashboards in Eventhouse, stream processing with SQL operators, triggered actions with Activator, or data pipelines into a Lakehouse. This is especially valuable when business decisions depend on the freshest operational data such as fraud detection, inventory alerts, customer experience signals, or operational monitoring, all driven by data that originates in your Fabric SQL database, transformed in near real-time into the shape you need. Figure: SQL to Eventhouse in Fabric Eventstream 1. To learn more about configuring Change Event Streaming, refer to the Stream SQL change events to Eventstream for real-time processing documentation. Data Factory Pipelines Lakehouse maintenance activity (Generally Available) The new Lakehouse maintenance activity lets you run vacuum and optimize operations directly from a pipeline, so table maintenance becomes an orchestrated step in your data workflows. It automates Lakehouse upkeep to reduce manual effort, keeps storage optimized on a schedule to accelerate query performance and reduce storage overhead, and lets you manage maintenance alongside your other pipeline activities. Figure: Configuring a Lakehouse Maintenance activity with optimize, V-Order, and vacuum settings directly in a pipeline. To learn more, refer to the Lakehouse Maintenance Activity documentation. Support for activity retry back-off logic (Generally Available) Pipeline activities now support an increasing delay for the retry interval — backoff logic that progressively lengthens the wait between retry attempts instead of retrying at a fixed interval. This improves pipeline resilience by absorbing transient failures, reduces downstream disruptions by using exponential backoff to minimize throttling and cascading failures, and provides a consistent experience across any pipeline activity that supports retry policies. Figure: Configuring an increasing delay retry interval on a pipeline activity, with minimum and maximum backoff bounds. To learn more, refer to the Activity Retries in Microsoft Fabric Data Factory documentation. Support for pipeline-level dependencies with run conditions (Preview) Pipeline-level dependencies let you define dependencies directly between pipelines, so downstream pipelines run only after upstream pipelines succeed, eliminating brittle scheduling workarounds. It improves reliability and reduces operational overhead by avoiding unnecessary re-runs and provides end-to-end visibility through pipeline dependencies in the Monitoring Hub for faster impact analysis and troubleshooting. Figure: Defining a pipeline-level dependency using a run condition — Custom, Data availability, or Window Coverage. To learn more, refer to the pipeline runconditions documentation. Richer pipeline monitoring in workspace monitoring (Preview) Richer pipeline monitoring surfaces operational insights directly in the Monitoring Hub, so you can quickly identify, diagnose, and resolve pipeline issues. Run-time events, performance metrics, and intelligent error classifications are all available in one place, reducing troubleshooting time. Figure: Exploring pipeline run activity and health details in the Monitoring Hub. To learn more, refer to the Enable Workspace Monitoring (Preview) in Microsoft Fabric documentation. Fabric Actions activity (Preview) The new Fabric Actions activity gives pipelines native, authenticated access to Fabric REST APIs. Invoke Lakehouse operations, capacity management tasks, and other Fabric platform APIs directly from your pipelines, with built-in credential handling that manages authentication automatically. Standardized, discoverable request and response patterns reduce custom scripting and simplify maintenance. Figure: Configuring a Fabric Actions activity to call a Fabric REST API with a managed connection. To learn more, refer to the Fabric Actions documentation. Business Actions activity (Preview) We continue to expand Fabric Data Factory pipelines to support more business workflows. The Business Actions activity (Preview) makes it easy to call common business systems such as Stripe, Twilio, and Jira through API calls configured with pipeline connections. Select an API action from the menu to use your pipeline as an enterprise application integration service. Figure: Selecting a business connector — such as Jira, ServiceNow, or Stripe — in the Business Actions activity. To learn more, refer to the Business Actions documentation. Mirroring Mirroring for Google Big Query (Generally Available) Organizations can seamlessly replicate data from Google BigQuery into OneLake, enabling faster analytics, unified governance, and simplified access to data across cloud platforms. With General Availability, customers can confidently deploy the capability in production environments backed by Microsoft's standard support and reliability commitments. Figure: Selecting Google BigQuery tables to mirror into Microsoft Fabric and previewing the source data before connecting. To learn more, refer to the Google BigQuery documentation. Mirroring for SharePoint List (Generally Available) This capability enables organizations to continuously replicate data from SharePoint Lists into OneLake, making it easier to access operational business data for analytics, reporting, and AI-driven experiences. By bringing SharePoint List data together with the rest of an organization's data estate in Fabric, customers can reduce data silos and unlock richer cross-functional insights without building complex integration pipelines. Now, customers can confidently deploy the capability in production environments to drive more unified, data-driven decision making across their business. Figure: Selecting a new connection to a SharePoint List through the mirroring creation experience with SharePoint list. To learn more, refer to the Mirroring SharePoint List documentation. Extended capabilities for Mirroring (Generally Available) Extended capabilities for Mirroring in Microsoft Fabric deliver new options for organizations that require more advanced replication and analytics scenarios. These capabilities capture row-level inserts, updates, and deletes to enable efficient incremental processing and near real-time analytics. Mirroring Views allows customers to replicate source-system views and business logic directly into OneLake without building additional data engineering pipelines. In addition, Security Roles Replication for Snowflake (Preview) enables organizations to bring Snowflake security role definitions into Fabric, supporting more consistent governance and security management across their data estate. Together, these capabilities help customers accelerate insights, reduce integration complexity, and unlock greater value from their mirrored data. Figure: Selecting settings in the Mirrored item page allows enablement of Change Delta Feed as one of the extended capabilities in mirroring. To learn more, refer to the Mirroring Extended Capabilities documentation. Mirroring Security Roles for Snowflake (Preview) Security Roles Replication for Snowflake in Microsoft Fabric Mirroring, is a new Extended Capability designed to help organizations simplify governance across their data estate. Security Roles Replication automatically brings supported Snowflake security constructs, including role hierarchies, role assignments, and grants, into Fabric and OneLake to help maintain consistent access controls alongside mirrored data. By reducing manual permission management and minimizing security drift between Snowflake and Fabric, organizations can accelerate analytics while preserving governance standards. This new capability extends the value of Mirroring beyond data replication, enabling a more seamless and governed end-to-end experience. This feature will be available shortly after FabCon EU 2026. Figure: Selecting Manage OneLake security opens a new tab to see the roles and permissions mirrored from Snowflake. To learn more, refer to the Extended Capabilities in Mirroring documentation. Copy Job Change data capture in Copy job (Generally Available) Copy job can use change data capture (CDC) to replicate inserted, updated, and deleted records from supported sources. After the initial load, Copy job processes only the changes captured since the previous successful run, helping keep destination data current while reducing unnecessary processing and load on the source system. Figure: Copy job configured to replicate inserted, updated, and deleted records from a CDC-enabled source. Copy job automatically detects CDC-enabled tables and manages the replication state between runs. Customers can use the Merge write method to maintain the latest state of each record at the destination or choose another supported write method based on their downstream data requirements. To learn more, refer to the Change data capture in Copy job documentation. SCD Type 2 in Copy job (Generally Available) Copy job now provides built-in support for Slowly Changing Dimension Type 2, also known as SCD Type 2, for supported change data capture scenarios. SCD Type 2 preserves historical changes by creating a new version of a row when source data changes instead of overwriting the existing record. When customers select SCD Type 2 as the write method, Copy job automatically adds and manages the Valid_From, Valid_To, and Is_Current columns at the destination. History tracking and soft-delete handling are applied together across the selected tables, eliminating the need to build custom change-processing logic. Figure: SCD Type 2 configuration in Copy job preserves current and historical versions of destination records. To learn more, refer to the Change data capture in Copy job documentation. Audit columns in Copy job (Generally Available) Copy job now supports audit columns, making it easier to add operational metadata to the data written to a destination. Customers can add audit columns without custom code or expression authoring, and Copy job automatically includes the selected metadata with every row it writes. Audit columns can help data teams trace how and when data moved, support downstream data-quality and compliance processes, and provide additional context for troubleshooting. Customers can add multiple audit columns and apply them across the tables in a Copy job through consistent configuration experience. Figure: Audit columns add row-level data movement metadata to a Copy job destination. To learn more, refer to the Audit columns in Copy job documentation. Copy job integration with Eventstream as a source and destination (Preview) Copy job now integrates with Fabric Eventstream as both source and destination, helping customers connect batch and streaming data movement through a unified Fabric experience. Customers can configure these scenarios directly from Copy job by selecting an existing Eventstream as the source or destination. With Eventstream as a destination, customers can move data from supported Copy job sources into a real-time processing path. With Eventstream as a source, customers can use Copy job to move streaming data to supported destinations for storage, analytics, and other downstream scenarios. This bidirectional integration makes it easier to build hybrid data solutions that combine operational events, incremental data movement, and analytical processing. Figure: Copy job connects batch and streaming data movement by using Eventstream as a source or destination. To learn more, refer to the What is Copy Job documentation. Copy job supports SQL CDC custom capture instance names (Generally Available) Copy job now supports SQL CDC tables that use custom capture instance names instead of requiring the default CDC naming convention. Customers can connect Copy job to existing SQL Server CDC implementations without renaming or recreating capture instances to align with default system-generated names. This enhancement improves compatibility with established SQL Server environments and organizational database standards, making it easier to adopt Copy job for CDC replication while preserving existing source-system configurations. Customers can use CDC-enabled tables regardless of whether the capture instance follows the default naming pattern or a customer-defined convention. To learn more, refer to the Change data capture in Copy job documentation. Copy job integration with workspace monitoring (Generally Available) Copy job now integrates with Fabric workspace monitoring, giving customers a centralized view of Copy job health, execution status, throughput, and operational trends alongside other Fabric workloads. Customers can monitor Copy job activity across a workspace without opening individual Copy job items, making it easier to understand ingestion performance and identify issues at scale. Workspace monitoring helps data teams quickly detect failed or slow-running jobs, track execution patterns over time, and troubleshoot operational issues across large ingestion estates. By bringing Copy job telemetry into the broader Fabric monitoring experience, customers gain a more unified operational view of their data movement activities. Figure: Monitor Copy job execution and health through the Fabric workspace monitoring experience. To learn more, refer to the Monitor a Copy job in Data Factory documentation. Custom staging database and schema for CDC and SCD Type 2 in Copy job (Generally Available) Copy job now supports custom staging databases and schema configuration for CDC and SCD Type 2 scenarios. Customers can choose where staging tables are created instead of relying on the default staging location, providing greater control over how replication workloads are organized within their destination environment. This enhancement helps organizations align CDC and SCD Type 2 processing with existing database standards, security requirements, and operational practices. Customers can isolate staging objects in dedicated databases or schemas, supporting environments that require specific governance, access controls, or naming conventions for temporary and operational data assets. To learn more, refer to the Change data capture (CDC) in Copy Job documentation. CDC from read-only Snowflake databases in Copy job (Generally Available) Copy job now supports ingesting change data through CDC from read-only Snowflake databases. Customers can replicate inserted, updated, and deleted records from Snowflake environments where write access is restricted, helping them maintain governed and secure source systems while keeping downstream destinations synchronized. This enhancement enables organizations to use CDC with shared, managed, or read-only Snowflake environments without requiring elevated permissions or modifications to the source database. Customers can adopt CDC-based replication while preserving existing security and governance controls on their Snowflake deployments. To learn more, refer to the Change data capture using Copy job documentation. Oracle CDC initial-load improvements (Generally Available) Copy job improves the performance and scalability of Oracle CDC onboarding by optimizing the initial replication process across multiple source tables. Customers can establish CDC-based replication more efficiently, helping reduce the time required to load source data and begin processing ongoing changes. These improvements are especially beneficial for large Oracle environments with many tables. By streamlining the way CDC processing is performed during onboarding, Copy job helps customers accelerate migration, analytics, and operational replication scenarios while simplifying the management of enterprise-scale Oracle workloads. To learn more, refer to the Change data capture using Copy job documentation. Azure Database for PostgreSQL connector for Copy job (Generally Available) Copy job now supports Azure Database for PostgreSQL as a source for both full and watermark-based incremental copy. Customers can perform an initial full load and then efficiently move only new or updated records in subsequent runs, helping reduce data movement volumes and improve ingestion performance. This expands the set of cloud operational databases that can participate in managed data movement within Fabric. With built-in support for full and incremental copy patterns, customers can replicate data from Azure Database for PostgreSQL into Fabric and other supported destinations through simplified, low-code experience. Copy jobs automatically manage incremental processing state between runs, reducing the need for custom orchestration and change-tracking logic while helping ensure destination data remains current. To learn more, refer to the Connectors for Copy Job documentation. Multi-folder copy into separate destination tables (Generally Available) Copy job now supports loading data from multiple source folders into separate destination tables within a single Copy job. Customers can configure multiple folders, files, or wildcard-based source paths and automatically load each source into its corresponding destination table without creating and managing multiple Copy jobs. This enhancement simplifies ingestion of partitioned and hierarchical datasets organized by business unit, region, date, or other folder conventions. By managing multiple source-to-destination mappings within a single Copy job, customers can reduce operational overhead while maintaining independent destination tables for downstream analytics and reporting. To learn more, refer to the Connectors for Copy Job documentation. Audit columns for Snowflake destinations (Generally Available) Copy job now supports audit columns when writing data to Snowflake destinations. Customers can automatically add operational metadata to destination tables, providing visibility into when data was copied and helping support governance, lineage, compliance, and troubleshooting scenarios. Audit columns can be configured without custom code and are automatically populated as data is written to Snowflake. This gives customers a consistent auditing experience across supported destinations while making it easier to track and validate data movement processes. To learn more, refer to the Audit columns in Copy Job documentation. SharePoint folders as source and destination in Copy job (Generally Available) Copy job now supports SharePoint folders as both a source and destination. Customers can move files between SharePoint and supported data stores through the same low-code Copy job experience used for other file-based and database sources. This enhancement makes it easier to operate document-centric workflows and automate file movement between SharePoint, OneLake, cloud storage platforms, and other supported destinations. Customers can centrally manage file ingestion and distribution while reducing manual file-transfer processes. To learn more, refer to the Connectors for Copy Job documentation. Dataflow Gen2 Optimized copy to Lakehouse (Generally Available) Optimized copy to Lakehouse accelerates the final step of dataflows that stage and transforms data before loading it into a Fabric Lakehouse table. It reduces serialization and network hops between the SQL staging engine and the destination, helping shorten refresh times for staging-heavy workloads. Enable the setting under Options > Scale > Staged data. It applies only to queries with staging enabled and a Lakehouse data destination. This optimization is separate from Fast Copy, which accelerates ingestion from supported data sources. Figure: Options dialog with the Scale tab selected and the Staged Data section highlighted. To learn more, refer to the Staged data options for Dataflow Gen2 documentation. Control write settings with the new V-Order compression setting (Generally Available) V-Order can improve downstream read performance but adds processing work during writes. Dataflow Gen2 lets you control this trade-off separately for the staging Lakehouse and Lakehouse table destinations. Use Enable use of V-Order compression under Advanced options in the Lakehouse destination connection. Consider turning it off for intermediate tables or Spark-only consumption and keep it on for frequently read tables used by Direct Lake or the SQL analytics endpoint. Figure: Connect to data destination dialog for Lakehouse with the Enable use of V-Order compression advanced option highlighted. The separate Enable V-Order compression option under Options > Scale > Staged data controls intermediate staging writes, not the destination table. To learn more, refer to the Configure V-Order compression for Lakehouse destinations documentation. Offset transformation: offset a date, datetime or time column backwards or forward in time (Preview) Shifting a date column is among the most common data preparation steps, and one of the more error-prone to implement manually. Dates are offset to compare a period against the same period a year earlier, to align a transaction date with the fiscal calendar an organization reports on, to correct a source system that records timestamps in a different time zone, or to account for a known lag between when an event occurred and when it was captured. Each of these previously required a custom column and M expressions that correctly handled month lengths and type conversions. Figure: Of the Offset dropdown list open, showing the Previous day, Next day, Previous week, Next week, and Custom options. The new Offset transformation applies the shift directly. Select a date, datetime, or time column, choose the direction and the amount, and Power Query shifts the column in place. The column retains its type, and the resulting query remains readable for whoever maintains it next. Figure: Of the Days field in the Offset dialog box with its value-source menu open, showing Enter a value, use values in a column, select a parameter, and select a query. To learn more, refer to the Offset date and time values documentation. Custom sort dialog (Preview) Sorting by a single column is straightforward. Sorting by several columns, with defined precedence, has required stacking steps in a specific order that can be difficult to interpret later. The new Sort rows dialog consolidates this into a single guided experience. Columns, precedence, and direction are defined together, and the complete ordering is expressed as one readable step. This makes multi-column sorting more approachable for self-service users, and easier to review and edit when requirements change. The dialog is part of a broader effort to make Power Query transformations more discoverable and consistent across Microsoft products, while continuing to support advanced scenarios that depend on well-defined row ordering. Figure: Of the Sort dialog box with three sort levels: Subtraction ascending, Priority ascending, and Region ascending. To learn more, refer to the Sort columns - Power Query documentation. Now and today ribbon command Power Query, including its experience in Dataflow Gen2, now makes it easier to add current Coordinated Universal Time (UTC) date and time values to your data. Instead of writing a custom M expression, you can add refresh-aware UTC columns directly to any table, without first selecting an existing date or time column. In Power Query Editor, open Add column and choose Today (UTC) from Date, Now (UTC) from Time, or Now (UTC) and Now (UTC+Zone) from Date/Time. Figure: Shows the Date/Time menu Now (UTC) and Now (UTC+Zone) options. To learn more, refer to the Add current UTC date or time columns documentation. Data visuals in Dataflows (Preview) You've just spent twenty steps shaping a query, and you want one honest answer: does the data look right? Are there nulls where there shouldn't be? Does this quarter's revenue trend look like a trend, or like noise? Today, answering that means leaving Dataflow Gen2, publishing downstream, and opening a separate reporting tool just to sanity-check a table you were already looking at thirty seconds ago. Not anymore. Any query in Dataflow Gen2 can now return a small dashboard, headers, KPI cards, charts, and tables, rendered right in the authoring canvas next to your data preview. And because the whole thing is expressed in Power Query M, a dashboard is just another query: versioned with your dataflow, generated dynamically from your data, and as reviewable as any other step in your Advanced Editor. No separate visual designer, no report file to keep in sync. Two scenarios cover most of what we've seen so far. While you're still shaping a query, attach a lightweight profiling dashboard: null counts by column, column types briefly, and a summary with outlier counts for every numeric column, built once and reused unchanged against any table in your dataflow. Once a query returns the results you want, attach a handful of KPI cards and charts that surface the headline story the moment someone opens it, no scrolling through raw rows required. Figure: A rendered data visuals dashboard in the Dataflow Gen2 authoring canvas, showing a header, KPI cards, charts, and a detail table. Ten visual types ship in this preview, from containers and KPI cards to line, area, bar, stacked bar, donut, and pie charts. These options are sufficient to compose a complete dashboard with a header, KPI row, charts, and a detail table. There is nothing to enable: data visuals render automatically in Dataflow Gen2 and Mashup Editor Tester. Get started by exploring Create data visuals in Dataflow Gen2 (Preview) for the full visual document schema and a complete, copy-and-paste, four-step example. My Queries: your personal library of queries (Generally Available) Rebuilding the same lookup table or date dimension in every dataflow gets old fast. My queries fix that: save any query from a Dataflow Gen2 dataflow once, then import it into any other dataflow you own within your personal workspace. No rebuilding, no copying M code between windows. Right-click any query and save it to a personal library in your own workspace, then pull it back into any dataflow from the Recents & My Queries pane in Get data. It's the fastest way to standardize common transformations across every dataflow you build. Figure: My Queries experience within the Get Data dialog of Dataflow Gen2. To learn more, refer to the My Queries or Shared Queries documentation. Shared queries: discover, share and consume queries with colleagues (Preview) Built a useful transformation, a data quality check, or a visual summary your colleagues could use? Don’t let that work stay in a single dataflow. Shared queries are coming to preview this September, making it easier to put your Power Query work into other people’s hands—whether they want to build on your logic or explore your results. Shared queries bring two ways to collaborate: Start ahead, instead of starting over - The new Shared queries module in Get data lets authors browse accessible workspaces, folders, and dataflows to discover shared queries. Import the queries you need as independent copies, then adapt them to your project without changing the originals. Spend less time rebuilding common transformations and more time solving your next data challenge. Share the result, not just the recipe - Send a query’s share link so colleagues with the required access can open a focused consumption experience, inspect the output, and refresh the results—without opening the full Power Query editor or importing the query into another dataflow. Pair shared queries with data visuals to make your work even more useful. Share a reusable data profiling view that helps another analyst spot missing values, or a visual summary that makes operational trends easier to understand. My queries are about your personal library. Shared queries make your work reusable by others. Each has its own browsing entry point, so you can choose the experience that fits your goal. To get started, right-click a query and select Enable sharing (Preview). Then invite colleagues to discover it through Get data > Shared queries, or use Get share link (Preview) to share its consumption experience. To learn more, refer to the My Queries or Shared Queries documentation. New data destinations (Generally Available) Excel workbook output and the Snowflake destination extend where teams can deliver data prepared with Dataflow Gen2. Excel workbooks: Write transformed data to an .xlsx file in a supported file-based destination, such as SharePoint or Lakehouse Files. Use a single sheet, partition rows across multiple sheets, or use the Advanced format with navigation tables to create workbooks containing tables and charts. The workbook is generated during refresh, reducing manual exports. Snowflake: Load transformed data directly into Snowflake tables from Dataflow Gen2. Teams can keep their preparation logic in Fabric while delivering curated data to existing Snowflake analytics workflows. Figure: Configure Excel workbook output using the Advanced format in a file-based data destination. To learn more, refer to the Create Excel workbooks with navigation tables and Configure Dataflow Gen2 data destinations. Dynamic expression editor for data destinations (Preview) Destination names often need to change with a refresh date, a parameter, or the workspace where a dataflow runs. The dynamic expression editor brings these values into the destination setup experience, so you can build reusable table and file names without manually editing the destination M script. In a supported Table name or File name field, type / to combine text with UTC date and time values, dataflow parameters, and workspace variables, including values from Fabric Variable Library items. For example, add the run date to an export file name, or use an environment parameter as a table name prefix. Values appear as editable tokens and resolve when the dataflow runs. The editor is enabled by default and is available in preview for supported data destination fields. Normal naming rules and write behavior still apply: a refresh can overwrite a file if its resolved name matches an existing file. Figure: Combine text with dynamic date and time values, parameters, and workspace variables directly in a destination field. Combine text with dynamic date and time values, parameters, and workspace variables directly in a destination field. To learn more, refer to the Use the dynamic expression editor for Dataflow Gen2 data destinations documentation. Send email from Dataflow Gen2 (Preview) Sending a data-driven email from a dataflow usually means writing results to a destination, orchestrating the run with another workflow, and maintaining a separate email step. Send email from Dataflow Gen2 brings that work into the Power Query authoring experience. Select a query, open Actions, choose Send email, and create or select an Outlook connection. You can configure recipients, the subject, and body with static values, parameters, or query-derived values. You can also make the action conditional by using a Boolean query, so the message is sent only when the data meets the condition you define. The action runs during a Dataflow Gen2 refresh. This makes it easier to notify an owner when a validation query finds an issue, distributes a recurring summary, or sends results to recipients determined by the data. Because the action remains part of the parent dataflow, you do not need to create and manage a separate pipeline for the email step. Add the action to your selected query, validate the Outlook connection, configure the message, and publish the dataflow. The next refresh evaluates the action and sends the email when its condition is met. Figure: The send email dialog showing a sample email with a subject and body. To learn more, refer to the Configure an Outlook-backed email action directly in Dataflow Gen2 documentation. Dataflow diagnostics download (Generally Available) Troubleshooting a dataflow used to start with a guess. Diagnostics download replaced the guess with evidence, and after a preview run with the community it is now generally available: consistent, reliable, and supported for business-critical pipelines. Download a run-level diagnostics package for any refresh and you get the Mashup engine execution detail and runtime metadata behind it; in a standard archive you can analyze yourself or hand to Microsoft support without a back-and-forth. It turns out a vague report that the refresh was slow into a specific operation, a specific duration, and a specific error. That is also what makes it useful across teams: data engineers, workspace admins, and support all end up looking at the same artifact instead of three different descriptions of the same problem. Logs become available a few minutes after a refresh completes and stay available for 28 days. You need at least the Viewer role in the workspace to download them. To learn more, refer to the View Dataflow Gen2 refresh history and monitoring documentation. Introducing Preview only step in Navigator When working with large or slow data sources, data previews can take longer than expected. You may only be trying to inspect a table, choose the right data, or validate your next transformation, but waiting for previews to load can interrupt your train of thought and slow down the authoring flow. This is especially important in Dataflows, where building a query often depends on quick iteration: connect to data, select tables, shape columns, apply transformations, and validate each step. When preview evaluation takes too long, the experience can feel less interactive and harder to stay focused on. To help with this, we’re introducing Preview only step, available directly from the Navigator experience. When enabled in Navigator, Preview only step automatically adds a temporary row-limiting step to your query preview, starting with the first 1,000 rows. This helps previews load much faster from the beginning, so you can start shaping your data immediately and keep your authoring flow moving. The key distinction is that this step is used only for data preview. It does not affect query execution, refresh, or the final loaded results. After the query is created, you can customize or remove the preview-only step as needed while continuing to author your query or dataflow. Figure: The new Limit editor preview to 1000 rows checkbox in the Choose data or also known as navigator screen in Dataflow Gen2. To learn more, refer to the Preview only step in Dataflow Gen2 documentation. Expanded support for the modern evaluator in Dataflow Gen2 The modern evaluator in Dataflow Gen2 (CI/CD) now supports all Power Query transformations and almost all connectors. Enabled by default for new dataflows, the modern engine can significantly improve query evaluation performance, helping users build and run dataflows more efficiently. This milestone brings the modern evaluation experience to more workloads, from shaping data during authoring to executing queries during refresh. Users can benefit from the improved engine while continuing to work with their existing data sources and transformation logic. Performance improvements vary by data source and workload. Existing dataflows retain their current settings and can opt in through the Modern query evaluation engine option in Scale settings, giving users control over when to adopt the improved experience. Note: Three connectors temporarily continue to use the standard evaluation engine automatically, even when the modern evaluator is enabled. See the documentation for current limitations. To learn more, refer to the Modern Evaluator for Dataflow Gen2 with CI/CD documentation. Refresh details in the Fabric Monitoring hub (Preview) Dataflow Gen2 refreshes already appear in the Fabric Monitoring hub, but the hub shows run-level status only. Investigating a failure means leaving the hub and opening the dataflow's refresh history through Recent runs in the workspace. This release brings the detailed refresh experience into the hub, so users can move from a failed run to its root cause without changing context. Selecting a Dataflow Gen2 refresh entry now opens the detailed run view, with the same information available in Recent runs today: overall status, refresh type, duration, request and session identifiers, the tables loaded during the refresh, and the activities performed, including writes to output destinations. Users can drill into an individual table or activity to review errors and activity statistics such as rows and bytes written. Run entries also link directly to the dataflow and the workspace that produced them. This also completes the path that begins with a refresh failure notification. The link in a failure email lands on the run in the Monitoring hub, and from there the user can navigate straight to the failure details rather than locating the dataflow manually. Dataflow Gen2 monitoring is now consistent with the rest of Data Factory, giving data teams a single place to detect, diagnose, and resolve refresh issues alongside pipelines and other Fabric items. For deeper troubleshooting, use Download detailed logs or Analyze logs from the run details. Figure: Dataflow Gen2 refresh details, including activity status and options to download or analyze logs. Dataflow Gen2 refresh details, including activity status and options to download or analyze logs. To learn more, refer to the View Dataflow Gen2 refresh history and monitoring documentation. Dynamic schema support for the Fabric Data Warehouse destination (Preview) Dynamic schema support for the Fabric Warehouse destination lets the destination table evolve with changes to your query output. Use the Replace update method with Dynamic schema. After changing a query, update its destination column mapping and republish the dataflow. If a refresh detects a difference between the expected schema and the destination table, it drops and recreates the table to match. This reduces manual table maintenance as transformations evolve. Dynamic schema does not apply to Append, and recreating a table can affect objects that depend on it. Figure: Dataflow Gen2 destination settings with Replace and Dynamic schema selected. To learn more, refer to the Data destination schema options documentation. Backup query results to a Lakehouse (Preview) Dataflow Gen2 normally shows the latest result of a query. When a refresh produces an unexpected result, reconstructing an earlier state can mean building another flow or relying on a manual export. With the new Backup action, you can preserve selected query results in a Fabric Lakehouse after each Dataflow Gen2 refresh. Each backup includes the refresh request ID and refresh timestamp, so you can identify the run that produced it and compare results across refreshes. The history stays in the Lakehouse, where you can inspect it with the Fabric tools you already use and combine it with other operational data. This removes a common gap between producing data and understanding how it changed. You can compare a surprising result with an earlier run, pinpoint when values change and retain recurring outputs without maintaining a separate pipeline just to create copies. Because Backup is configured on the query, the history grows alongside the dataflow without another item to operate. To get started, select a query in Dataflow Gen2, open Actions, choose Back up, and select the Lakehouse destination. The dataflow then preserves the query results as part of future refreshes. Figure: The query to back up action summary in the data preview pane. To learn more, refer to the Configure Dataflow Gen2 query to back up results to a Lakehouse after each refresh documentation. Modern Get Data: browse Azure resources (Preview) Connecting to Azure data has meant switching to the Azure portal, copying a server name, endpoint, or URL, and pasting it into Power Query by hand. For some sources the copied URL must be edited before it works, which is easy to get wrong and hard to diagnose. Azure resources can now be browsed and connected directly from the modern Get data experience in Power Query. The Azure module lists the resources the user has access to across their subscriptions, by filtering by subscription, resource group, and resource type, and search across the list by name, type, and location. Selecting a resource creates or reuses a connection using the organizational account and goes straight to the data preview. Because the Azure module lists only resources the user already has access to, it also avoids a common failure: connecting to a resource that cannot be read. For customers coming from Azure Data Factory the browse-and-select pattern will feel familiar, and for everyone it turns a multi-step manual setup into a single selection. Figure: Showcasing the new Browse Azure button enabled throughout different Azure connectors. To learn more, refer to the Get data in Dataflow Gen2 documentation. New enhancements for upgrading Power BI Dataflows Gen1 to Dataflows Gen2 (CI/CD) (Preview) Following the August Preview release of the Dataflows Upgrade Wizard, this month's update adds new tools for tracking, automating, and assessing upgrades: Download the upgrade report: After an upgrade run finishes, download a CSV file with the outcome and details for each dataflow. The report makes it easier to track assessment results, partial successes and follow-up actions. Automate upgrades with Fabric REST APIs: Assess readiness, submit Dataflows Gen1 for in-place bulk upgrade, and monitor long-running operations. Workspace Admins can upgrade dataflows they do not own while preserving the original owner and supported data source connections, enabling a seamless upgrade without ownership transfers or connection reconfiguration. Catch more issues before upgrading: The expanded assessment now flags dataflow and query naming issues, dataflows with more than 50 enabled queries, and dataflows that participate in Deployment Pipelines. The wizard can adjust unsupported or duplicate dataflow names automatically; other findings explain what to fix before upgrading or deploying. Figure: Download the upgrade report from the Monitor page after an upgrade run completes. To learn more, refer to the Upgrade Dataflow Gen1 to Dataflow Gen2 (CI/CD) using the Upgrade Wizard documentation. New enhancements for Mapping Data Flow Transforms in Dataflow Gen2 (Preview) Building on the June preview of Mapping Data Flow (MDF) transforms into Dataflow Gen2, this month’s update introduces native Fabric connectivity, parameterization, expanded migration support, organizational account authentication, and enterprise network security enhancements: Connect natively to Fabric Lakehouse and Warehouse: Use native connections to read from and write to Fabric Lakehouse, including both schema-enabled and schema-less Lakehouse, and Fabric Warehouse. This enables customers to build end-to-end, Spark-scale transformation workflows using data stored in Fabric. Build flexible and reusable dataflows with parameters: Define parameters once and use them throughout dataflow settings and transformation expressions. Fabric pipelines can supply static or dynamic values at runtime, enabling the same dataflow to support different processing rules, data scopes, tables, and environments without duplicating transformation logic. Migrate Mapping Data Flows from Azure Synapse Analytics: At Preview launch (June 2026), we introduced support for migrating Azure Data Factory pipelines and their Mapping Data Flows to Fabric. This capability now extends to Azure Synapse Analytics, helping customers bring Synapse pipelines and their associated Mapping Data Flows to Fabric while retaining their existing visual transformation logic. Authenticate with an organizational account: MDF transforms now support organizational account authentication with OAuth 2.0 for supported connectors. Customers can securely access data sources and destinations using their Microsoft Entra organizational identity. Strengthen enterprise network security: MDF transforms now support Outbound Access Protection (OAP) and Workspace Private Link. Workspace Private Link provides private access to the Fabric workspace, while OAP restricts outbound connectivity to approved connections and endpoints. Together, these capabilities help customers run transformation workloads within controlled enterprise network boundaries. Figure: MDF Transforms in Fabric Dataflow Gen2 showing customer and sales data joined, transformed, and aggregated into revenue metrics, with the results displayed in Data preview. To learn more, refer to the Mapping Data Flow Transforms in Dataflow Gen2 (Preview) documentation. Upgrade to Fabric Data Factory with confidence We’ve streamlined the ADF & Synapse upgrade experience to easily bring your existing data factories into Microsoft Fabric, view your Azure Data Factory pipelines directly within Fabric, and continue using familiar management and monitoring experiences, all before making any migration decisions. Now you can experience Fabric immediately while preserving all your 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. Figure: A seamless three-step journey from Azure Data Factory to Fabric Data Factory: experience existing data factories in Fabric, assess upgrade readiness, and upgrade when ready. The journey begins directly from Azure Data Factory with a simple View in Fabric experience. Bring your ADF and Synapse environments into a Fabric workspace and immediately see the familiar data factory assets and pipelines within the Fabric experience. Existing Azure Data Factory assets remain the source of truth, while you gain access to Fabric as a natural extension of the current experience. This allows teams to become familiar with Fabric, explore the broader Fabric platform, and understand the value of a unified data estate without disrupting production workloads. Once inside Fabric, you can evaluate your readiness for Fabric Data Factory using built-in migration assessment capabilities. The assessment provides visibility into pipeline and activity compatibility, helping customers understand which workloads are ready to upgrade, which may require review, and which capabilities are planned for future support. By surfacing compatibility information upfront, you can make informed modernization decisions and prioritize migration efforts based on business needs. Connection mapping and migration guidance further simplify planning and reduce manual effort. This assessment-first approach is a direct response to your feedback. Trust is built through visibility, and customers consistently tell us they want a clear understanding of readiness before committing to change. After reviewing assessment results, organizations can choose when and how they upgrade to Fabric Data Factory. Supported pipelines can be upgraded incrementally, allowing teams to validate outcomes, gain operational confidence, and modernize at the pace that makes sense for their business. Existing Azure Data Factory workloads can continue operating while organizations evaluate and transition workloads over time. Technology is only one part of a successful modernization journey. Customers also want guidance, expertise, and support. Microsoft migration experts, and a growing ecosystem of specialized partners. Microsoft partners bring deep migration and industry expertise to help customers assess environments, prioritize workloads, address compatibility requirements, and accelerate deployment. Whether modernizing a departmental solution or an enterprise-scale data integration estate, customers can leverage proven expertise to move forward with confidence. To learn more, refer to the Upgrade your Azure Data Factory pipelines to Fabric Data Factory documentation. Connection Governance Data connection policies: Authentication allowlist (Generally Available) Governing how users authenticate data across a tenant has meant per-connector or per-endpoint controls, with no central way to restrict which authentication methods are allowed. Tenant admins can now define exactly which authentication methods cloud connections are allowed to use, such as Basic, Service principal, or OAuth 2.0 Entra ID, from a single tenant-wide policy in the Power BI Admin portal. When enforcement is on, any connection using a method that isn't allowlisted fails policy evaluation, for both new and existing cloud connections, so admins can retire risky credential types tenant-wide instead of auditing connections one at a time. Figure: Choose which authentication methods of cloud connections are permitted to use from the Authentication allowlist tab. To learn more, refer to the Authentication-Allowlist documentation. Data connection policies: Tenant allowlist (Generally Available) As organizations connect across partners and subsidiaries, admins have no central way to keep cloud connections pointed only at trusted Microsoft Entra ID tenants, or to stop inter-tenant data movement they never approved. Tenant admins can now define exactly which Microsoft Entra ID tenants cloud connections are allowed to reach, up to 100 tenant IDs, from a single tenant-wide allowlist in the Power BI Admin portal. When enforcement is on, any connection targeting a tenant that isn't allowlisted fails policy evaluation, for both new and existing cloud connections, giving admins direct control over inter-tenant data movement instead of reviewing connections one by one. Figure: Add the Microsoft Entra ID tenant IDs that cloud connections are allowed to reach, up to 100 tenants. To learn more, refer to the Fabric Tenant Allowlist documentation. Admin APIs for cloud connections (Generally Available) Auditing connections across a tenant has been difficult: admins couldn’t see connections they weren’t added to; orphaned connections piled up when employees left, and there was no inventory of which connector or authentication types were in use. Tenant admins can now inventory every cloud connection in the tenant through the admin APIs, filtering by connector type, authentication type, and owner, and reviewing details like endpoints and when a connection was last used. Admins can also take ownership of orphaned connections, reassign connections to keep workloads running, and clean up duplicate or stale connections, giving enterprises the visibility and control they need to govern data connectivity at scale. Figure: Turn on Tenant administration to see every cloud connection in the tenant, including its type, owner, and when credentials were last used. To learn more, refer to the Fabric Connection Admin APIs documentation. App Development Functions, Connectors and more with Fabric Apps (Preview) Fabric Apps (Preview) is upgrading your app building experience. We are adding new functionality, including support for functions, data connectors, and observability, plus security upgrades, new region support, and more. Functions Functions let you add server-side logic to a Fabric App without standing up or managing any infrastructure. Some logic simply cannot run safely in the browser: calling a partner API with a private key, enforcing a business rule a user must not be able to bypass, or running a multi-step operation that must complete reliably. You can now write the logic as a User-Defined Function (UDF) that runs alongside the rest of your app. Functions also ship with a secret store. You declare which secrets the app needs, and the values are supplied separately, so they never land in source code. Figure: Functions view in Fabric App, including functions and secrets. Data Connectors Data connectors let a Fabric App read from, and where supported write to, data that already lives in a customer’s Fabric workspace, with no copying and no moving. Fabric data source Read Write Fabric SQL Database Yes Yes Fabric Warehouse Yes Yes Lakehouse (SQL analytics endpoint) Yes No Semantic model Yes No Observability Every Fabric App now comes with built-in metrics, so you can see how your app is being used and performing from the moment it ships. The portal reports sign ins, app loads, and the number of data queries executed, alongside query error count, query error rate, and average query duration. Figure: Metrics view in Fabric App. Additional features Support for creating a PostgreSQL database. Share Fabric Apps and grant recipients the access they need to related items the app depends on. If someone can’t access the Fabric App itself, they can submit an access request, and the people who manage access to the app will be notified. A new security feature that requires authentication to access an app’s static content. New Supported Regions. New Plugin to Build Fabric Apps with GitHub Copilot App. Support embedding a Fabric App into a parent web app with Entra Auth. Coming Soon This section provides an early look at capabilities planned for a future release. Availability and timelines are subject to change. On-demand billing and Zero-provisioned (F0) Capacity (Preview) Microsoft Fabric is introducing on-demand billing and Zero-provisioned capacity SKU (F0) to help organizations better align compute usage with actual workload demand. These updates are designed to reduce upfront capacity commitments while improving cost control and workload flexibility across analytics scenarios. Instead of requiring fixed shared provisioning for all workloads, Fabric now enables teams to selectively apply on-demand billing to specific workload categories. This allows organizations to start with less upfront commitment, respond to usage spikes, and keep variable workloads from competing with predictable workloads for shared capacity, while maintaining predictable governance and spend controls. Flexible capacity models Fabric supports multiple capacity options to match different stages of adoption and workload patterns: Start with F0. F0 is a zero-provisioned capacity SKU with no upfront compute-capacity charge. Supported categories use on-demand billing by default, which can help with evaluation, development, early production, or workloads whose capacity needs are not yet predictable. Add on-demand billing to an F2 or higher capacity. Move a supported billing category outside the shared capacity CU limit and pay for that category separately. Your other workload continues using provisioned capacity, making this a practical option for a stable baseline with occasional bursts. This model allows teams to start small, scale gradually, and apply cost controls where needed. How on-demand billing works On-demand billing is applied at the billing category level, ensuring consistent behavior across all workspaces within a capacity. Each category is billed based on actual usage, allowing workloads to scale independently depending on demand. Capacity administrators can enable on-demand billing for a category from the On-demand billing section on the capacity’s Details tab. Feature: Enable On-demand billing for a category. On-demand consumption is measured in CU-hours without smoothing. Pricing uses a multiplier of the pay-as-you-go capacity price, which can vary by billing category. Storage charges remain separate from compute charges. Note: Autoscale billing for Apache Spark, now re-named to ‘On-demand billing for Apache Spark’, remains generally available and functions as before. Pricing remains unchanged. Example usage scenario An organization running Data Warehouse and Data Factory workloads on a Fabric capacity may choose to place the Data Warehouse category on on-demand billing during a seasonal promotion. Compute intensive Warehouse queries could scale independently while steady workloads continue using the provisioned capacity, without the need for capacity expansion. When demand settles, the administrator can return the category to the shared-capacity model, balancing performance needs with cost efficiency. Spend controls and governance To support cost predictability, administrators can configure spending limits using CU-hours over a rolling 24-hour window. When the limit is reached: New operations are temporarily paused In-flight operations continue until completion Billing resumes automatically once the window resets This provides a safety mechanism for preventing unexpected usage spikes while preserving system stability. Feature: Configure the spend limit for an on-demand billing category. Monitoring on-demand consumption On-demand billing consumption can be monitored using the Capacity Metrics App, in the new “On-demand compute” tab, on a per billing category basis. Feature: Inspect on-demand usage in Capacity metrics app. Why this matters These updates introduce a more flexible approach to capacity management in Fabric: Lower entry barriers without upfront commitment with F0. Improved cost efficiency by paying only for usage in burst-heavy workloads. Better workload isolation between steady and variable compute patterns. Stronger governance controls through category-level billing and spend limits. Together, these capabilities help organizations modernize infrastructure without over-provisioning capacity or sacrificing control. On-demand billing for Fabric Data Warehouse Warehouse workloads could be spiky. Month-end close, ad-hoc analytics, a surprise executive query. Demand rarely matches the capacity provisioned. Today that leaves customers with a hard trade-off: size your base Fabric capacity for the peak and pay for headroom rarely used, or size for the average and watch important queries get throttled when demand spikes. Neither protects both performance and budget. On-demand billing breaks that trade-off. Warehouse, SQL analytics endpoints, warehouse snapshots and notebook running T-SQL scale compute dynamically with actual demand, so peaks can access additional compute when demand increases, while per-workspace controls keep spend and concurrency predictable. This helps reduce the need to provide for infrequent peak demands. Figure: Illustrative comparison of shared capacity and on-demand billing for a warehouse workload. Benefits Elastic compute, per workspace: Each workspace bursts up to its configured compute ceiling to absorb spikes automatically. Customers pay for actual CU consumption, never for the ceiling. Smart defaults for every SKU: New and migrated workspaces start with a ceiling tuned to existing Fabric SKU, to get sensible performance out of the box with no tuning required. Budget controls that fit the way everyone expects: Pair per-workspace ceilings with the on-demand daily spend limit to cap runaway cost while still absorbing spikes gracefully. Better together with custom SQL pools: On-demand billing gives elastic bursting for unpredictable demand; custom SQL pools guarantee dedicated compute for most important workloads. Together they give fine-grained control over price and performance, so critical work always gets the compute it needs. Estimated graphical query plan Understanding how a query is expected to run before executing it can help identify potential performance issues earlier. Coming soon to Microsoft Fabric Data Warehouse, Estimated Graphical Query Plan brings an interactive visual plan directly into the Fabric query editor. In April 2025, we announced SHOWPLAN_XML support in Fabric Data Warehouse, making estimated plans available in XML format. Customers could save the XML as a .sqlplan file and open it in SQL Server Management Studio for a graphical view. Estimated Graphical Query Plan builds on that foundation. Instead of exporting XML and switching tools for an initial inspection, you can explore execution operators, estimated row counts, estimated costs, and data movement in Fabric. Select an operator to review its properties and identify opportunities to adjust joins, statistics, or query design before execution. Figure: Exploring an estimated graphical query plan in the Fabric Data Warehouse query editor. Estimated Graphical Query Plan builds on that foundation. Instead of exporting XML and switching tools for an initial inspection, you can explore execution operators, estimated row counts, estimated costs, and data movement in Fabric. Select an operator to review its properties and identify opportunities to adjust joins, statistics, or query design before execution. Data Warehouse in Workspace Monitoring Monitoring activity across multiple warehouses can be difficult when operational signals are spread across separate experiences. Data Warehouse integration with Workspace Monitoring brings warehouse activity into the same workspace-wide monitoring experience as other Fabric items. Figure: Analyzing Data Warehouse execution telemetry through Workspace Monitoring. Administrators and operators can query the WarehouseExecutions table through the monitoring Eventhouse and KQL database to compare execution trends, investigate failures, and understand workload behavior across warehouses. Teams can also build reusable KQL queries and dashboards for the signals they track most often. When an investigation requires deeper query-level detail, continue in Query Insights or Data Warehouse Monitor (DW Monitor). This creates a connected path from workspace-level visibility to warehouse and query diagnostics. AI Insights in DW Monitor Troubleshooting warehouse issues often require correlating metrics, query activity, and operational signals before deciding where to focus. AI Insights in DW Monitor will turn those monitoring signals into grounded explanations and recommended next steps. Condition-driven insight cards will highlight query failures, SQL pool pressure, top resource-consuming queries, and tables that need attention. Select an insight to open a Copilot sidecar grounded in the relevant warehouse metrics, query details, and time window. Review the supporting evidence, explore likely causes, and continue with focused follow-up questions without leaving DW Monitor. Figure: Using AI insight cards and the Copilot sidecar to investigate warehouse activity in DW Monitor. An Investigate action for individual query runs will provide additional context for failed queries or compare completed runs with their recent baseline. The experience recommends actions while keeping changes under your control. That’s a wrap! The European Microsoft Fabric + SQL Community Conference is just getting started, and there's never been a more exciting time to be part of the Fabric community. We hope these updates help you discover new capabilities, streamline operations, strengthen governance, and unlock more value from your data. Be sure to explore the links throughout this post for deeper technical guidance, and follow along with the latest announcements, demos, and sessions from Barcelona. We're excited to see what you build with Microsoft Fabric next.
Bringing governed analytics into the flow of work: Fabric Analytics at FabCon Europe 2026
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. An end-to-end look at what's new in Fabric Analytics and how governed enterprise data is moving closer to the people and tools that use it. Walking through Barcelona, it’s impossible not to be inspired by the Sagrada Familia. It is a reminder that ambitious systems are rarely built in one pass. Construction began in 1882. More than a century later, it remains a symbol of extraordinary vision, craftsmanship, and persistence. Every iteration has contributed to another piece of the structure. It continues to evolve as new capabilities are added to a foundation designed to endure. That is also how I think about this next set of Fabric Analytics updates. At Microsoft Build 2026, we introduced the agentic analytics stack in Microsoft Fabric: four layers — data foundation, serving, semantic, and conversational — engineered so that AI does not merely assist, but executes across your data estate. At FabCon Europe 2026, we are completing the next iteration. Three shifts define this release: Agents move from answering to acting — Fabric IQ reaches general availability inside Microsoft 365 Copilot Cowork and Copilot Chat, putting governed enterprise data into the flow of everyday work, while Project Osmos brings the same shift to the engineers who build that data. Compute keeps pace with agentic demand — GPU acceleration arrives on both sides of the stack: GPU-accelerated query execution in Fabric Data Warehouse enters public preview. Trust travels with the data — Sensitivity labels, DLP enforcement, and admin controls follow your data across product boundaries, so reach never comes at the cost of governance. That end-to-end approach is already helping enterprises scale how they work with data and AI. At Hilti, Microsoft Fabric provides a common foundation across data engineering, data science, and business intelligence, helping teams reuse data and analytics assets and expand self-service across the business. “Microsoft Fabric is helping Hilti create one trusted foundation for data, analytics, and AI. Today, 25,000 users work across 700 Fabric workspaces, with continuous adoption across teams in eight business domains, up from four. This foundation is expanding self-service analytics and helping us turn data into business value faster.” Patrik Raudaschl, Head of AI Platform and Services at Hilti Fabric IQ: Your semantic models in the tools everyone already uses For most organizations, the hardest problem in enterprise AI was never the model. It was the last mile — the gap between a governed data estate and the person who needs an answer during a meeting, in an email thread, or halfway through a document. Fabric IQ in Microsoft Copilot Cowork is now generally available, as is Fabric IQ in Microsoft Copilot Chat. Users can ask business questions in Copilot Chat and receive trusted answers grounded in governed Power BI reports and semantic models, with Copilot inferring which report or model is right for the question. In Cowork, Power BI content participates directly in long running and asynchronous tasks. These experiences are not grounded in a parallel, AI-specific copy of your data. They run on the same semantic models that already power your enterprise reports — the same measures, relationships, and certified definitions of “revenue,” “active customer,” and “margin” your finance and operations teams have curated for years. The result is consistency. When a frontline manager asks Copilot Chat a question and an executive opens the corresponding Power BI report, they see the same results. Because these experiences are grounded in the same semantic models, organizations can extend existing business definitions, governance investments, and reporting assets into AI experiences. Mohawk Industries, the world’s largest flooring company, is using Microsoft Copilot Chat to unlock more value from its established Power BI footprint. By connecting Chat to Power BI semantic models, Mohawk is enabling users to move from data to detailed, actionable insights through natural-language conversations, helping analysts spend less time interpreting reports and more time acting on what the data reveals. “We are strongly impressed by the very detailed and actionable insights Microsoft Copilot Chat provides on top of our Power BI semantic models. Excited to really start harvesting our Power BI footprint investments now!” Stijn Lioen, Global Architect Data & Analytics Mohawk Industries Microsoft 365 integration is also coming to Power BI in Fabric, advancing our goal of a consistent Copilot experience that reduces context switching and brings data insights into the flow of everyday work. And with Fabric IQ MCP reaching general availability, creators can extend these experiences to development environments and external MCP clients, while enhanced governance controls give organizations greater control over which semantic models are available through Copilot. Data agents are now more capable Alongside Fabric IQ, we're making data agents ready for more complex production scenarios. Fabric data agents are now generally available in Microsoft Copilot Studio, and improvements in ontologies, relationship awareness, and topic-aware guidance help agents better understand business context and answer complex questions. Soon, all these capabilities will integrate automatically in Fabric IQ, extending the Microsoft Copilot conversational capabilities to the full breadth of Fabric. Power BI: The next evolution of BI The agentic app era For more than a decade, Power BI has helped tens of millions of users turn data into insights. Copilot in Power BI has made analysis and report creation more conversational. Now, we’re introducing a new app building experience in Power BI Desktop, powered by apps in Fabric. Users can start from a trusted semantic model and use natural language to generate, preview, edit, and publish purpose-built data applications to Microsoft Fabric. These applications can accept inputs, write back data, preserve shared state, and support operational workflows—helping users move from insight to action. As applications grow, developers and IT teams can extend and operate them without rebuilding them from scratch. To make this new era of creation broadly accessible, Fabric Apps will be included with Power BI Pro, giving existing Power BI creators a natural path from reports to purpose-built data applications. peek. The semantic layer: Define once, reuse everywhere Everything above depends on the semantic layer. We are sharing an early look at semantic views, a new capability that allows customers to define governed business metrics and semantics directly where data lives in OneLake. We’re cementing our move toward a more open model where business definitions can be shared across workloads, tools, and AI experiences across Fabric. The goal is simple: the same governed business definitions can power reports, applications, and AI experiences alike. Making the semantic layer open and interoperable In collaboration with Snowflake, and as a member of the broader Apache Ossie community, we are committed to making Power BI’s semantic layer more open and interoperable. Our support and contributions to Apache Ossie (incubating), a community-led standard for exchanging semantic metadata across analytics, AI, and BI platforms, help customers reuse semantic context across ecosystems while advancing support for DAX and ontologies. Data Warehouse: Compute rebuilt for agentic load As analytics become more conversational, the warehouse has to answer more queries, more interactively, and at greater scale. To meet that demand, GPU-accelerated query execution powered by NVIDIA accelerated computing is now in public preview. Based on the award-winning CoddSpeed research, it accelerates many analytical workloads without requiring changes to data or SQL, with benefits that become increasingly important under the high-concurrency patterns AI experiences create. We're also evolving the economics of the platform. A new node-based billing model and cache cooldown settings help align cost with consumption, giving organizations more flexibility, predictability, and workload isolation. Beyond performance, we're continuing to expand the data warehouse platform with improvements in observability, troubleshooting, workload management, and the T-SQL surface area. Looking ahead, Fabric IQ integration for Data Warehouse, shortcuts for Data Warehouse, and warehouse clones will make it easier to reason over and access data wherever it lives, without introducing unnecessary copies or movement. Data Engineering and Data Science: The foundation that keeps everything fresh AI experiences are only as good as the data behind them. Across Data Engineering and Data Science, we're continuing to improve the performance, freshness, and accessibility of that foundation. Fabric Spark continues to advance with the Native Execution Engine, delivering significant performance gains while remaining compatible with existing Spark workloads. Runtime 2.0 brings Spark 4.0 and Delta Lake 4.0, while resource profiles and custom live pools make it easier to optimize and right-size compute for different workload patterns. We're also making data easier to prepare and maintain. Materialized Lake Views are generally available, helping teams build reliable and reusable data products, while shortcut transformations simplify bringing external business data into OneLake. Finally, we're bringing AI directly into the development experience. Fabric Skills and agentic Copilot in notebooks help developers and data engineers work more effectively with Fabric assets, translating intent into governed, Fabric-native operations. Agentic data engineering The first shift in this release puts AI to work for the people who consume data. The next does the same for the people who build it. Earlier this year, Microsoft acquired Osmos, an agentic AI data engineering platform, to accelerate our vision for agentic data engineering in Fabric. That technology is now coming to life as Fabric’s new data engineering agent. Now in preview, the data engineering agent in Fabric is designed to take on long-running projects, not just one-off tasks. Instead of guiding a chat assistant step by step, developers describe the outcome they want and grant access to the relevant Fabric assets. From there, it plans, executes, validates, and refines work over hours or days, creating notebooks, transforming data, updating schemas, and managing complex workflows along the way. What makes it different is how deeply it’s integrated with Fabric. It understands workspaces, lakehouses, notebooks, schemas, and lineage, executes natively on Fabric Spark, and continuously validates its work as it progresses. “For our teams, Fabric’s data engineering agent is about empowering our data teams to move faster without compromising quality or governance. By reducing repetitive engineering work and making complex projects more collaborative, it can help us focus our expertise on building trusted, reusable data solutions that lead to better outcomes for our clients.” Jennifer Ratten, VP, Application Engineering, Technology NFP, an Aon Company The goal is not simply to help engineers complete individual tasks faster. It's to help teams tackle larger efforts, such as migrations, schema harmonization, and data quality remediation, that are often important but difficult to prioritize and staff. New data engineering agent (Project Osmos) that can plan, execute, and validate a multi-step data engineering project across a Fabric workspace. Governed and flexible by design As Fabric reaches more users and supports a broader range of workloads, customers need flexibility not only in how they govern the platform, but also in how they adopt and consume it. Building on Autoscale Billing for Spark, on-demand billing expands consumption-based billing across Fabric workloads, allowing you to pay only for the compute you use, automatically scaling resources up and down based on your demand. Fabric zero-provisioned adds to on-demand billing by allowing you to get started with Fabric and OneLake without an upfront capacity commitment. Greater flexibility and broader access also make consistent governance more important. As analytics reaches more users and extends into more AI experiences, governance must extend with it. For many European organizations, requirements around data residency, sovereignty, and compliance are simply part of the baseline. To support this, we're extending governance controls across the Fabric analytics stack. Sensitivity labels, DLP policies, and information protection controls now flow into Microsoft Copilot experiences and Restrict from Copilot gives administrators control over which semantic models can participate in AI experiences. We're also strengthening the platform through improvements in OneLake Security, SQL auditing, data export controls, and upcoming support for customer managed keys across Data Engineering workloads. Most importantly, these AI experiences are built on the same semantic models, OneLake foundation, and security controls that organizations already rely on today. Customers can extend existing governance investments into AI experiences rather than managing a separate AI-specific data estate. The full picture The agentic analytics stack is no longer a concept to evaluate. It is running end to end in Microsoft Fabric — and as of this week, it reaches the people who never open a BI tool. Data Engineering and Data Science keep data fresh and scalable. Data Warehouse serves it fast and under governance. Power BI gives agents something worth reasoning over. Fabric IQ delivers it to every user, grounded in the models you already trust. Every layer runs on OneLake using open data formats. One security model. One governance framework. One definition of the truth, whether it surfaces in a report, a chat, or an agent acting on your behalf. Our goal is to make the data you’ve already invested in available wherever decisions get made. That’s the direction behind these announcements, and we’re excited to hear what you think. Come find us at FabCon Europe and share your feedback and scenarios in the Fabric Community to help shape what comes next!Build, deploy, and govern Microsoft Fabric at scale
If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings. Getting a data project working is only the beginning. As AI makes it easier for more people to build applications, explore information, and create agents, the harder questions arrive sooner: can the solution be deployed consistently, can a team explain what changed, and will someone notice when a dependency fails? Developers need room to experiment, but they also need a dependable route from an isolated feature branch to a production workload that others can operate. Manual setup, disconnected monitoring, and unclear data context make that route harder to repeat. Administrators face the other side of that growth. More workspaces, users, and workloads mean more decisions about access, compute, spending, and accountability. A capacity spike can affect an unrelated team; a broad security setting may not fit every project. Admins need controls that reflect organizational requirements without turning each development step into a permission request. Developers, in turn, need those boundaries to be understandable and built into their workflows, rather than discovered just before release. Today, we're announcing Microsoft Fabric platform updates to help you tackle both sides of that challenge. They connect operational signals with investigation, make delivery more repeatable, and bring governed discovery into the tools you use. We're also expanding your options for managing compute demand and applying controls across your estate. Introducing observability in Fabric (Preview) A failed job rarely tells the whole story. With the introduction of observability in Fabric, you can connect signals across jobs, workspaces, items, and capacities rather than investigate each in isolation. A Monitor item acts as a single management unit across capacities and your tenant, bringing early detection, contextual investigation, and central management into one operational experience. Unified workspace monitoring (Preview) We're introducing unified workspace monitoring so you can choose which Eventhouse receives your telemetry and consolidate multiple workspaces into that shared store. Instead of monitoring workspaces individually, you can bring related signals together and manage their storage centrally. You control retention and caching policies to suit your investigation and operational needs. When a failure crosses workspace boundaries, for example, you can correlate the telemetry in one place and follow the issue across those boundaries. Most Fabric items will be available at launch, with additional workloads becoming available over time. The new experience also simplifies how you connect monitoring to your own tools. A custom endpoint on the monitoring Event Stream lets you copy data to external or custom destinations, while public APIs support integration with your external observability tools. Simplified, API-backed onboarding makes setup repeatable for automation and agents. You can establish a shared monitoring approach, then extend it to additional workspaces without treating every setup as a separate manual exercise. Refreshed Monitor Hub (Preview) The refreshed Monitor Hub helps you see where attention is needed before opening individual investigations. We're adding ready-made, at-scale views across workloads, jobs, apps, agents, alerts, and capacities, with a centralized health overview and data health monitoring. That broader view helps you spot emerging issues and consider their downstream impact rather than starting with a single failed activity. Capacity consumption and available headroom sit alongside operational signals, so you can consider resource pressure as you assess an issue. Start with the health overview, narrow your focus to the affected area, and move into investigation with that context. The hub connects navigation and operational visibility; the capacity administration actions described later let you respond when the next step is a control change. Agentic investigation and alerting with operations agents and Activator We're also adding the ability to use operations agents to investigate end-to-end causes, develop evidence-backed hypotheses, assess impact, and recommend next steps. You can engage with the investigation, refine its direction, and choose your response. This brings the supporting evidence and relevant dependencies into the conversation instead of leaving you to assemble every clue yourself. Currently this capability can help you investigate pipeline failures, with further support planned. New Activator-powered job alerts notify you about successes as well as failures. You can automate alerts and configure responses, connecting investigation with the operational workflows your team uses. Together, these enhancements help you move from noticing an event to understanding its likely impact and deciding what to do next. Repeatable delivery and governed discovery for developers Operational confidence starts before deployment. The latest enhancements, designed with developers in mind, help you package a solution, review changes, move definitions between environments, and find reusable data worth reusing with fewer manual handoffs between those steps. Introducing deployment plans (Preview) With the deployment plans now in preview as first-class workspace items, you can define the exact deployment order on a visual canvas, with YAML as the source of truth. You can include pre- and post-deployment steps, such as hydrating a lakehouse with a notebook, running a pipeline before dependent items, or validating data after deployment. Your plan follows the solution through Git branch-out, initial sync, updates, deployment pipelines, and bulk import. Preparation and validation become part of the deployment sequence rather than a separate checklist. Bulk Item Definition APIs, quotas, and API limits (Generally Available and Preview) Bulk import and export item definition APIs are also now generally available. You can move multiple definitions in one call; imports automatically determine deployment order and update references for the destination workspace. This supports workspace-as-code, CI/CD, and migration. We're also enhancing the Fabric API platform with a unified quota model and increased limits for core APIs. These updates provide more consistent throttling and quota management while supporting higher-scale automation, CI/CD, and enterprise workloads, making it easier to build and operate Fabric solutions at scale. Git integration enhancements (Generally Available and Preview) The new branch workspace administration delegation capability, now in preview, gives developers a governed, self-service way to create branch workspaces without permission to create workspaces or assign capacity. Administrators define the branch workspace admin profile, including the role, admins, capacity, and delegated settings applied to each new branch workspace, helping teams move faster while maintaining consistent guardrails. We're also expanding the Git workflow with file-level commits for supported items (Preview) and contributor branch switching (Preview). You can commit only the files that are ready while leaving unfinished changes in the workspace, and contributors can switch the Git branch connected to a workspace when administrators enable the capability. Additionally, selective branching, change comparison and commits, and branched workspace relationships, now generally available, helping teams keep feature work focused, review changes before acting, and manage branching from a clearer source control experience. Discover data in OneLake catalog and your coding workflow The OneLake catalog gives you a richer, more granular way to explore and understand data across Fabric before you use it. With the latest updates, you can go beyond finding Fabric items to explore individual tables and columns, review descriptions, and preview the underlying data directly in the catalog. Quick actions, personalized views, and filters, including domains and tags, add business context so you can evaluate whether data is right for your needs before you start working with it (Generally Available). We've also expanded the OneLake catalog search API to return relevance-ranked Fabric items, OneLake tables from lakehouses, mirrored sources, and semantic model tables in one result set (Preview). This brings the same granular discovery to programmatic search, helping applications find relevant data across Fabric regardless of where it lives. OneLake catalog discovery in GitHub Copilot CLI is now generally available through Skills for Fabric. You can find Fabric items and tables from the CLI before writing code, bringing this richer, governed discovery experience directly into your coding workflow rather than requiring a separate search. Bring catalog discovery into Excel and Microsoft Foundry Finally, OneLake catalog in Excel is now in preview, enabling you to discover and analyze Fabric data in your workbooks without copying or moving the underlying source data. OneLake row- and column-level security and Microsoft Purview label-based protections apply, connecting familiar analysis with the protections associated with your source. New OneLake catalog additions in Microsoft Foundry bring enterprise data discovery into your AI development workflow (Preview). With an embedded catalog and a unified view across Fabric and Foundry, you can find trusted data and add it to knowledge, agents, and workflows. Effectively administer capacities and spending As your solutions reach production, capacity administrators need to optimize spend for steady demand while seamlessly managing bursts. With today’s announcements, we are adding new billing choices and capacity controls, as well as tools that help you investigate usage, automate responses, and act across capacities. Introducing on-demand compute and zero-provisioned capacity (Preview) As data and AI workloads grow, organizations need flexible ways to align costs with actual usage. Building on Autoscale Billing for Spark, we're introducing on-demand billing across Microsoft Fabric in preview soon, enabling workloads to scale elastically when needed, minimizing throttling during demand spikes, and allowing you to pay only for the compute you consume. We're also introducing Fabric zero-provisioned (F0), a new entry point to Fabric and OneLake that removes the need to provision compute before getting started. With on-demand billing enabled by default, organizations can immediately access Fabric services and pay only for the resources they use. Together, on-demand billing and Fabric zero-provisioned make it easier to start small, scale as demand grows, and combine consumption-based pricing with reserved or provisioned capacity to optimize both performance and cost. These capabilities will be available in the coming weeks. Whether you're running workloads that tend to spike, experimenting with new projects, or supporting production applications, on-demand billing gives you greater flexibility without requiring upfront capacity planning. Surge protection, overage, and larger capacities (Generally Available) Workspace-level surge protection will be generally available soon. You can set a workspace consumption limit, automatically isolating runaway or non-critical workloads so they don't impact mission-critical workloads or cause capacity-wide throttling. You can manage these controls in OneLake catalog or Monitor Hub, which also allows you to mark mission-critical workspaces exempt from the limit. Additionally, capacity overage is now generally available, letting you use additional paid compute with configured spending thresholds and notifications rather than sizing capacity solely for rare peaks. For sustained high demand, we've added the F4096 and F8192 capacity SKUs (also Generally Available), extending your options for larger workloads. Monitor, act, and automate your capacities Monitoring helps you understand who's consuming resources, identify demand spikes, and ensure critical workloads continue to perform as expected. New capacity metrics app enhancements help you investigate health-state duration, capacity units per second, daily and hourly heatmaps, and top item contributors (Generally Available). Clearer drilldowns support deeper analysis, while chargeback app integration helps you allocate usage. Capacity overview events in Real-Time Hub (Generally Available), with new operation events (Preview) adding workspace- and item-level visibility. These signals enable proactive capacity monitoring by helping administrators identify emerging hotspots, usage anomalies, and resource-intensive operations before they impact users. Connect them to Real-Time Intelligence, Eventhouse, and Activator to automate alerts and actions, retain history for capacity planning, or integrate insights into your existing monitoring systems. With the refreshed Monitor Hub, we're taking the first step toward bringing capacity insights and management actions together in a single experience. Capacity Insights & Actions (preview) lets administrators identify emerging issues and immediately respond by adjusting surge and overage settings, migrating workspaces, or resizing capacity. Use Monitor Hub for monitoring and operational decisions, and the capacity metrics app for deeper usage analysis. Unify governance, security, and control in the OneLake catalog As AI helps more people build with data, tenant admins are responsible for governing an estate that’s growing in both size and complexity. More workspaces, data items, and access requests mean more decisions about what people can share, which settings they can change, and how to protect sensitive data. Admins need to support new projects without turning every decision into a manual review, or losing visibility into how data is used. That balance between enabling teams and maintaining the right guardrails is critical. As Jayakumar Pankajatchan, Distinguished Engineer at KPMG, shared, “Client trust starts with security. Every engagement needs clear data boundaries and strong guardrails, so information flows only where intended. With Microsoft Fabric, we strengthen governance across engagements while enabling teams to deliver insights with confidence at scale.” We’re expanding governance and security in Fabric to help organizations put those guardrails into practice without slowing teams down. With more centralized management, AI-assisted governance guidance, granular policies, and broader network protection, you can give your teams room to innovate while maintaining controls that reflect your organization’s requirements. Introducing policies in Fabric (Preview) With policies in Fabric (Preview), we're introducing precise, attribute-based controls that help organizations enforce governance requirements based on user and data attributes, rather than relying solely on broad settings. Policies enable granular controls for key scenarios, with item creation and workspace security supported at launch and external data sharing coming soon. A centralized policy management experience, monitoring, APIs, and CI/CD integration support policy lifecycle management at scale, supporting more consistent and automated governance across your organization. Figure: Creating an item creation policy with attribute-based conditions and controls. "Fabric’s Item Creation Policies have strengthened our governance controls for Microsoft Fabric, allowing us to scale innovation across the organization by empowering users with the right capabilities while maintaining clear boundaries for platform management and compliance,” said Bernard Beeftink Lead Product Owner, BI, ABN AMRO. Centralizing governance in the OneLake catalog We're expanding the OneLake catalog Govern experience (Generally Available) with centralized governance capabilities that bring management of tenants, domains, capacities, workspaces, tags, and policies into a unified experience. Rich contextual signals, insights, and recommendations help administrators better understand their governance posture and take informed action across their data estate. We're also introducing Govern Skills as part of skills-for-fabric. Govern Skills provide AI-powered guidance across the health, security, and trustworthiness of your data. Govern Skills help administrators identify governance risks, monitor the health of their data estate, and take recommended actions to maintain a secure, trusted, and well-governed foundation for analytics and AI. Outbound access protection expansion (Generally Available and Preview) We've expanded outbound access protection to OneLake shortcuts (Generally Available), along with new coverage for maps in Fabric and operations agents (Preview). You can extend your outbound controls across these experiences while building on existing foundations such as Microsoft Entra, Private Link, customer-managed keys, and workspace IP firewall rules. FQDN allowlist for outbound protected workspaces (Preview) FQDN support for Spark simplifies secure connectivity for organizations using OAP-enforced Fabric workspaces, where Private Endpoints are often required to access dependent services. Instead of creating and managing Private Endpoints for every resource a Spark workload needs to reach, administrators can use domain-based network controls to securely enable connectivity through approved FQDNs. This reduces networking complexity, lowers operational overhead, and accelerates onboarding while maintaining enterprise security and compliance requirements. This capability will be available in the coming weeks. Fabric availability in Microsoft 365 Government Community Cloud High (GCC High) We are also expanding Microsoft Fabric to Microsoft 365 Government Community Cloud High (GCC High) customers. Support for GCC High extends Fabric to organizations that require U.S. sovereign cloud environments and compliance with frameworks such as DoD Impact Level 4, CJIS, DFARS, and NIST 800-171. Put the updates to work Start with the friction you encounter most: investigating failures, reproducing deployments, finding data, or managing demand and controls. Our updates connect those responsibilities without requiring every team to use the same workflow. Match adoption to your readiness requirements, then extend your approach as your data estate grows. In addition to the announcements above, we are also rolling out a broad set of innovation across Fabric. For a broad overview of all these announcements, read Arun Ulag’s hero blog “FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents.” If you want a more detailed look, visit the Fabric September 2026 feature summary blog, the Power BI September 2026 feature summary blog, and the latest posts on the Fabric Updates channel and the Azure Data Tech Community blog channel.Microsoft & Snowflake’s Commitment to Apache Ossie
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. Advancing an open, interoperable semantic foundation for AI-powered analytics Today, Microsoft is pleased to affirm our commitment to Apache Ossie (incubating), a community-led effort to establish a vendor-neutral standard for exchanging semantic metadata across analytics, AI, and BI platforms. This has been a close collaboration with Snowflake, who helped found Ossie. We have heard loud and clear that customers want to enable platform-agnostic agentic experiences. Shared semantic context must be defined once and reused across platforms, enabling agentic consumption at scale, maximizing the reach of AI-powered analytics, and empowering users to leverage the best agent for the job. Power BI semantic models are key enablers of AI-powered analysis, providing humans and AI agents with governed semantic context to answer data questions quickly and confidently. Power BI semantic models have more than 38 million monthly active users and are adopted by 94% of Fortune 500 companies. Microsoft was also recognized as a Leader and Outperformer in the GigaOm’s radar for semantic layers & metric stores in 2025. We’re now bringing this wealth of experience to Apache Ossie, and we are excited to work with Snowflake and other partners to help make the project successful. Why Apache Ossie matters Until now, semantic definitions were often recreated across platforms, introducing complexity, inconsistency, and management overhead. Apache Ossie addresses this with a common specification that tools can read and write. Its goal is straightforward but consequential: define a semantic layer once and make it portable across the data and AI ecosystem, while preserving semantic meaning and governance for agentic consumption. Collaboration with Snowflake Snowflake and Microsoft serve many of the same customers, but customers don't want to choose between ecosystems. They want their data and analytics investments to work together. That makes interoperability between, for example, Snowflake Semantic Views and Power BI semantic models a shared responsibility. This layers on top of the integration work we have already done with Snowflake for writing Iceberg tables from Snowflake to OneLake, Mirrored Databases from Snowflake, using Iceberg tables with OneLake, Catalog Integration for OneLake, Power Query Snowflake connector and much more. As discussed in the Snowflake blog post and the message below from Carl Perry, VP of Analytics at Snowflake, our collaboration is currently focused on using Apache Ossie as a vehicle for cross-platform semantic-layer conversion without moving or duplicating the underlying data. Looking ahead, we’re committed to advancing the open standard by building on our deep expertise in semantic modeling by, including helping establish DAX as an Ossie-recognized query language. We also plan to help advance Ossie support for ontologies so customers can extend the business logic in semantic models beyond agentic analysis and into platform-agnostic operational intelligence. Ultimately our goal is simple: enable customers to define once, and reuse anywhere. Today, we are highlighting the following new integration scenario: converting an Ossie document into both a Snowflake Semantic View and a Power BI semantic model. This enables customers to define shared semantic context once, then reuse it across Snowflake and Fabric while retaining the agentic experiences and capabilities of each platform. Refer to Apache Ossie Microsoft Converter for more information. Building together We look forward to working with the Apache community, Snowflake, and others across the industry to create a more open and connected future for AI-powered analytics, delivering more choice and flexibility for customers. Get involved: Visit the Apache Ossie project website and repository to explore the specification and community contribution channels. Share your thoughts and feedback with us. Apache Ossie is undergoing incubation at the Apache Software Foundation. Incubation indicates that the project is working toward the governance, infrastructure, and community practices expected of established Apache projects.
On-premises data gateway September 2026 release
The September 2026 release of the on-premises data gateway (version 3000.334) continues our commitment to delivering secure, reliable, and manageable connectivity between on-premises data sources and Microsoft Fabric services. This release includes improvements focused on gateway manageability, operational visibility, enterprise governance, and platform reliability, helping organizations manage their gateway environments with greater confidence. It also brings compatibility updates for the September 2026 release of Power BI Desktop, ensuring consistent query execution and a seamless experience between Power BI Desktop and cloud-based refresh scenarios. Additionally, this release includes enhancements across security, authentication, diagnostics, and overall platform quality. Feature updates and new capabilities in OPDG Soft Delete in OPDG: Accidental gateway deletions can be disruptive, often requiring administrators to recreate gateway configurations and restore connectivity. With Soft Delete, deleted gateways are retained for 30 days, providing administrators with the ability to recover them and reduce the impact of unintended deletions. Recover deleted gateways Reduce operational disruptions Improve gateway management and reliability Built with customer feedback in mind and another step toward a more resilient connectivity experience in Microsoft Fabric. Learn more about the soft delete in the gateway soft delete documentation. Security improvements and updates Customers are encouraged to upgrade to the September 2026 release to benefit from the latest security updates and dependency improvements. This update helps improve the security posture of on-premises data gateway deployments and addresses vulnerability findings that may be reported by security scanning tools. Upgraded the embedded Apache Log4j library to version 2.26.1. Addressed the security vulnerability documented in CVE-2026-18401. As part of our ongoing commitment to security and reliability, we continuously evaluate and update third-party dependencies. These updates are incorporated into gateway releases following comprehensive security reviews, compatibility validation, and product qualification testing to help ensure a secure, stable, and reliable experience for customers. General improvements and fixes The September 2026 Gateway release (3000.334) includes Power Query Engine 2.158.928 and introduces the following improvements: Fixed a sign-in issue impacting gateway installations on Windows Server 2016. Improved accessibility across the Gateway Configurator application to provide a more inclusive and user-friendly experience. Power BI Desktop compatibility This update brings the on-premises data gateway up to date with the September 2026 release of Power BI Desktop. Download on-premises data gateway (standard mode) Download on-premises data gateway (personal mode) This version of the gateway will ensure that the reports that you publish to the Power BI Service and refresh via the gateway will go through the same query execution logic/run-time as in the September version of Power BI Desktop. Next steps Upgrade to version 3000.334 to take advantage of the latest security, authentication, and diagnostics improvements. We encourage you to share feedback and feature requests through the Power BI Ideas forum to help shape future gateway investments. Thank you!
Modernize your Azure Data Estate with Microsoft Fabric: A guided path from Azure Data Factory and Azure Synapse
Authors: Faisal Mohamood and Bogdan Crivat 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. Most enterprise analytics estates were assembled rather than designed. A tool for ingestion, another for transformation, a warehouse for data processing, a lake for everything else, and a layer of glue holding it together. That architecture did its job for a decade, but it was built for a world where data moved on a schedule and insight could wait. AI changed the deadline. The organizations pulling ahead today are the ones consolidating on a single platform where data, analytics, and AI share one foundation instead of one integration backlog. For teams running Azure Synapse Analytics and Azure Data Factory, Microsoft Fabric is the next step in that investment—not a departure from it. Fabric unifies data integration, engineering, and warehousing in one SaaS experience, reducing the operational burden of disparate tools and creating a clearer path to AI-driven workloads. The question customers now ask are not whether to modernize, but how to do so without disrupting the pipelines their businesses rely on every day. Upgrade to Fabric Data Factory with confidence Azure Data Factory has earned the trust of customers worldwide by powering mission-critical data integration workloads. 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 on that trusted foundation while bringing customers into a unified data platform for AI transformation. 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 FabCon 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. The experience is built around three principles we consistently heard from customers: transparency, control, and confidence. Customers want to understand what will change, what will remain the same, and when they should modernize. We provide a guided path that allows organizations to explore, assess, validate, and upgrade on their own terms. The journey begins directly from Azure Data Factory with a simple view in Fabric experience. Customers can bring their Azure Data Factory environment into a Fabric workspace and immediately see their familiar data factory assets and pipelines within the Fabric experience. Existing Azure Data Factory assets remain the source of truth, while customers gain access to Fabric as a natural extension of their current experience. This allows teams to become familiar with Fabric, explore the broader Fabric platform, and understand the value of a unified data estate without disrupting production workloads. Once inside Fabric, customers can evaluate their readiness for Fabric Data Factory using built-in migration assessment capabilities. The assessment provides visibility into pipeline and activity compatibility, helping customers understand which workloads are ready to upgrade, which may require review, and which capabilities are planned for future support. By surfacing compatibility information upfront, customers can make informed modernization decisions and prioritize migration efforts based on business needs. Connection mapping and migration guidance further simplify planning and reduce manual effort. This assessment-first approach is a direct response to customer feedback. Trust is built through visibility, and customers consistently told us they want a clear understanding of readiness before committing to change. After reviewing assessment results, organizations can choose when and how they upgrade to Fabric Data Factory. Supported pipelines can be upgraded incrementally, allowing teams to validate outcomes, gain operational confidence, and modernize at the pace that makes sense for their business. Existing Azure Data Factory workloads can continue operating while organizations evaluate and transition workloads over time. This staged approach helps reduce risk while enabling customers to realize the benefits of Fabric Data Factory and the broader Microsoft Fabric platform. The upgrade journey from ADF to FDF allows customers to plan, explore Fabric, assess readiness, validate outcomes, and upgrade when ready. The journey from Azure Data Factory to Fabric Data Factory is designed to be transparent, low-risk, and customer-driven, helping every Azure Data Factory customer become a Fabric Data Factory customer on their own terms. Read more about the Fabric Data Factory announcements at FabCon Barcelona. Guided migration with Microsoft-approved partners Microsoft-approved partners can guide customers’ upgrade from start to finish, or customers can explore the upgrade independently with no effect on their existing Azure Data Factory pipelines. Customers can now request partner-guided upgrade support online and get connected with Microsoft partner expertise to help plan and execute their Fabric Data Factory upgrade. Partners can help assess the customer’s environment, prioritize workloads, address compatibility requirements, develop the upgrade plan, execute and validate upgrades, and accelerate deployment to production. Learn more about how partners can help guide migration. Modernizing Spark workloads with Fabric Data Engineering Fabric Data Engineering provides a unified foundation for building and scaling Apache Spark workloads alongside the rest of the analytics estate. With capabilities such as the Native Execution Engine, high concurrency, and starter pools, teams can improve performance, reduce operational overhead, and work more easily with shared data in OneLake. The Spark in Azure Synapse to Fabric Data Engineering migration assistant accelerates modernization by migrating Spark pools, notebooks, and Spark job definitions, while mapping lake databases through OneLake catalog shortcuts. Artifacts are copied while data remains in place, allowing existing pipelines to continue running without downtime. A guided experience tracks progress and provides a detailed report of what migrated successfully and what requires attention. OBOS, one of the Nordic region’s leading residential developers, used a phased approach to migrate more than 600 notebooks and pipelines and consolidate over 4,500 data objects into 87 lakehouses. By validating technical results and live business KPIs across both environments before cutover, OBOS reduced operational costs by 20% and accelerated data processing by 30%. “We deliberately ran the old and new environments in parallel, comparing row and column counts and validating business KPIs through live reports before we switched anything over. That rigorous validation mattered, because for a data platform like ours, trust is the product.” - Dag Erlend Berger, Product Lead for the Data Platform, OBOS Complementing the migration assistant, the Fabric data engineering agent (Project Osmos), now in preview, helps accelerate the engineering work that goes beyond moving artifacts. Teams can delegate complex migration and modernization tasks, such as adapting Spark notebooks, refactoring pipelines, and validating migrated workloads. Osmos inspects the relevant data and code, plans and executes the work in Fabric, and iteratively validates and refines the results against the task’s requirements. Authorized teammates can contribute context and steer the same persistent task, with Fabric permissions governing access. This helps reduce manual engineering effort while keeping quality, maintainability, and team oversight central to the transition. Accelerating query performance with Fabric Data Warehouse For organizations managing data volumes in terabytes or petabytes, Fabric Data Warehouse provides superior performance and cost efficiency compared to Synapse dedicated SQL pools. The migration assistant for data warehouse simplifies and automates this transition for existing Synapse customers. The assistant, built directly into the Fabric experience, provides a guided path to convert artifacts from Synapse dedicated SQL pools into Fabric Data Warehouse, helping with schema conversion and data movement alike. It delivers a clear, actionable snapshot of migration results alongside a detailed summary of items that need attention, and Copilot is available to help resolve issues on the spot. To further reduce migration effort, the migration assistant gives customers the flexibility to migrate only what they need. Customers can select specific schemas or individual objects instead of migrating an entire environment, with visibility into object dependencies and guidance on related artifacts that should be migrated together. This allows organizations to break large modernization projects into manageable phases while maintaining confidence that dependent objects are accounted for. Large-scale modernization programs are inherently iterative. Source systems continue to evolve while migration projects are underway, creating a challenge for organizations that need to keep target environments synchronized without repeatedly restarting migration efforts. To address this, we introduced incremental migration support in Migration Assistant. Customers can return to an existing migrated warehouse at any time and apply new changes from their source system, whether they are using a live connection or uploaded SQL files. The experience intelligently identifies differences, helps resolve conflicts, and updates only what has changed, transforming migration from a disruptive, start-over exercise into a repeatable, low-friction process. This significantly reduces the operational burden on migration teams and makes it easier for organizations to move to Fabric with greater confidence. Dentsu, a global advertising and public relations company, was dealing with data growing faster than what its teams could keep up. In partnership with OneLake GmbH, Dentsu accelerated its migration to Fabric, applying deep technical expertise to design a scalable, enterprise-grade analytics platform. “Fabric has evolved beyond self-service analytics to a full enterprise-class platform. By combining data warehousing, lake storage, and Power BI, we’ve unlocked a foundation that sparks curiosity and innovation. People naturally ask, ‘What can I build on top of this?” —Patrick Sura, Global Reporting Architect, Dentsu Nebraska Furniture Mart, a Berkshire Hathaway company managing a large BI estate under significant performance and resource pressure, migrated to Fabric Data Warehouse using the migration assistant. “The tool facilitated every step of the process, automatically addressed column type conflicts, and effectively handled data migration right after the metadata transfer.” — Siri Kakumanu, Senior Manager, Data Analytics and Business Intelligence, Nebraska Furniture Mart Read more about Analytics announcements at FabCon Barcelona. The future of your data estate starts now Whether you are modernizing data pipelines, scaling analytics workloads, or simplifying Spark operations, these tools are designed to help you move forward with confidence and at your own pace. If you want to learn about the migration paths available to Fabric, start with Azure to Fabric Migration site. If you’ve scoped your migration, use cases and are ready to get started, check out our migration documentation for guidance and actionable steps. If you’re looking for hands-on support, connect with your Microsoft account team or visit the Microsoft Fabric Community to learn from customers who have already made the move.Trusted AI starts with Microsoft Fabric, Real-Time Intelligence, and IQ
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. Microsoft IQ: One enterprise, acting on one live picture Organizations generate vast amounts of information every day across business systems, operational data, enterprise knowledge, communications, and the web. Yet the context needed to understand what is happening, what it means, and what should happen next often remains fragmented across teams, applications, and data sources. Microsoft IQ brings that context together. It provides the intelligence layer that helps people and agents understand the world, the organization, and the business they serve by connecting knowledge, relationships, history, policies, and actions into a shared understanding. Consider a global manufacturing operation days before a major product launch. Across factories, suppliers, warehouses, and transportation networks, thousands of decisions are being coordinated to meet customer commitments and keep the launch on track. Suddenly, a critical production line goes down, putting delivery timelines, customer commitments, and business outcomes at risk. What happens next depends on far more than the failed equipment. The right response requires a complete understanding of the business, including maintenance history, production schedules, inventory, available capacity to supplier commitments, transportation options, launch milestones, policies, customer expectations, and changing external conditions. No single team, application, or data source holds that picture. Instead, the enterprise must bring together all relevant signals, understand how they relate to one another, and coordinate the best response in real time. It must evaluate alternatives across factories, warehouses, suppliers, and transportation networks, balancing timing, cost, quality, risk, and customer commitments to determine the best path forward. Microsoft IQ provides the intelligence layer for this type of challenge. What AI changes and what intelligence it requires AI is changing the economics, scale, and speed of decision-making. Choices that were once too small, too time-sensitive, too numerous, or too costly to evaluate can now be considered continuously, as agents monitor conditions, reason through alternatives, coordinate with people and other agents, and act within delegated authority. At the same time, expectations are rising. Organizations are increasingly expected to anticipate disruption, adapt in real time, and meet commitments without exposing customers to the operational complexity behind the scenes. That becomes difficult when data, business context, policies, and actions remain fragmented across systems. Agents can optimize individual functions, but they struggle to reason across the full business, often operating from different versions of reality. As a result, people are left stitching together context, reconciling conflicting answers, and coordinating decisions manually. AI needs more than access to isolated applications or the latest rows of data. It needs one live, enterprise-wide model that combines current state, history, relationships, policies, governed decisions, live web data, and available actions. The defining question is simple: What does your AI run on? Microsoft IQ expands the context available to people and agents by bringing together four complementary sources of intelligence: Web IQ grounds AI in current knowledge from the public web. Work IQ brings context from organizational knowledge and the flow of work. Foundry IQ connects AI to curated knowledge across structured and unstructured enterprise sources. Fabric IQ adds governed business meaning across data, analytical models, operational signals, entities, relationships, history, and available actions. Together, the four IQs give AI a more complete understanding of the world, the organization, and the business it serves. Fabric IQ contributes the governed business context that connects this broader intelligence to the live state of the enterprise. From Microsoft IQ to the Fabric operational nervous system Within Microsoft IQ, Microsoft Fabric provides the live data foundation and operational loop that turns shared intelligence into action. Only Fabric brings real-time state, governed business context, and action together in one live picture, so people and agents can understand what is happening, decide what to do, and act from the same trusted foundation. As the unified platform for building an operational nervous system, Fabric enables the enterprise to sense, understand, reason, decide, act, and learn: Observe: OneLake unifies operational, analytical, and business data, while Real-Time Intelligence continuously detects emerging conditions and maintains a live picture of operations based on signals it’s connected to. Analyze: Fabric IQ adds business meaning through entities, relationships, history, rules, and available actions, helping transform signals into operational understanding. Decide: AI evaluates alternatives using business data and context, while governance policies, permissions, thresholds, and delegated authority remain embedded in every recommendation. Act: People and agents coordinate around the recommended response, with approved actions flowing into business systems and outcomes becoming part of the enterprise’s memory to inform future decisions. The result is not another dashboard. It is a continuous operating loop that connects signals to understanding, decisions, and action. Fabric provides the operational foundation within Microsoft IQ, contributing the live business context, enterprise data, relationships, history, and actions that help people and agents reason over the current state of the business. Together, Fabric IQ, Web IQ, Work IQ, and Foundry IQ help create a more complete picture of the world, the organization, and the business they serve. What Fabric makes possible The value of an operational nervous system becomes clear when conditions change. A single operational signal can quickly ripple across manufacturing, supply chain, logistics, and customer commitments, requiring the enterprise to understand, decide, and respond as one. When a critical production line goes down days before a product launch, Real-Time Intelligence detects the issue as it happens. Fabric immediately connect that signal to the broader context, including production plans, inventory, supplier commitments, transportation options, business communications, and external events. Fabric IQ then helps AI understand not only what happened, but what it may mean for the business. With that context in place, AI can evaluate alternative responses, weighing timing, cost, quality, risk, and customer commitments. Leaders and agents are able to operate from the same shared understanding, with routine actions proceeding automatically where policy allows and higher-impact decisions are surfaced with explanations of clear tradeoffs and recommendations. In this scenario, AI recommends reserving capacity at a second plant while production, materials, and transportation plans are rebalanced. Once approved, teams and agents execute against a coordinated response, with every recommendation, decision, and action remaining governed and traceable. And the process does not end with a single decision. As conditions change because of supply disruptions, weather events, or shifts in demand, the same operational loop continues running, helping the enterprise sense change, reason across business context, govern decisions, and coordinate action. H&M is building its operational nervous system with Fabric The shift is already beginning to take shape across industries. For a global retailer like H&M, lost and stolen clothing is not simply an inventory challenge. It represents millions of euros in potential losses and underscores the need for greater real-time visibility into what is happening across the business. H&M is connecting real-time signals across its operations to better track clothing and identify where items may be lost or stolen. This scenario demonstrates how bringing real-time data with business context can help teams move from fragmented signals to a clearer understanding of what is happening, why it matters, and where action may be needed. This is a powerful example of how organizations can use real-time intelligence to address high-value business challenges and turn operational signals into measurable impact. " Across our 4,000+ stores, some have ceiling readers that update every few minutes, others count with handheld scanners once a day, so the data was hard to compare. With Fabric Real-Time Intelligence we bring it all together into a fuller picture of where every garment is and what state it's in. We're using it for operational analytics and exploring how AI agents can make shopping easier." – Jan Barrish, Head of Retail Tech, H&M. At FabCon, we are advancing the Fabric capabilities that help organizations connect signals, maintain operational understanding, and turn insight into governed action. What's new in Fabric: Advancing the operational nervous system The latest Fabric capabilities strengthen every stage of the operational nervous system, from connecting live signals and maintaining business context to enabling intelligence, analytics, and action. Fabric Observability Insights (Preview) Fabric Observability Insights enters public preview, using an AI-powered, domain-specific operations agent to investigate issues such as pipeline failures with Fabric-native context. The Fabric monitoring hub continues to provide a centralized view of job health, progress, history, and outcomes, while workspace monitoring adds log-level visibility in a secure, read-only Eventhouse database for analysis with Kusto Query Language (KQL) or SQL. To learn more, check out the workspace monitoring overview. Connect and stream Bring more operational data into Fabric with custom streaming connectors and enterprise-ready CDC support through the Mirrored Database Change Feed Connector. Schema-aware Eventstreams make it easier to process structured and evolving event data, while Reference Data Join, Copy job integration, and connector security extend real-time pipelines to richer operational scenarios. Understand and analyze Move from raw event data to useful answers faster with Copilot Data Exploration, which supports natural-language investigation in Real-Time Dashboards. Eventhouse MCP Server and Eventhouse Onboarding Agent extend that experience to AI-assisted access and guided solution creation, while shortcuts and update policies reduce duplication and maintenance. Visualize and monitor See operational conditions in context by bringing Fabric Maps into Real-Time Dashboards and connecting maps to external geospatial services through Feature Service Support. Copilot dashboard creation reduces the effort needed to create queries and visuals from a business question, while embedding and richer KPI and live-update experiences help bring operational insight into business workflows. Act and automate Turn important business moments into coordinated action with Business Events, giving applications, workflows, and agents a shared signal they can consume. Activator detects conditions and publishes or manages rule-driven responses, while Operations Agent extends the story into investigation and root-cause analysis. What’s new in Fabric IQ Investigate (Preview) When the operations agent detects an anomaly in your business data and your Fabric observability data, it automatically runs Investigator to provide more context about what happened. Investigator analyzes telemetry data and detects correlated or explanatory patterns around the time of the anomaly, helping you understand the potential causes without manually investigating the data. The agent uses Fabric-native context to deliver evidence-backed hypotheses, impact assessment, and recommended next steps, simplifying and automating troubleshooting for data engineers. To learn more, check out the Operations Agent Actions document page. Operations agent performance view (Preview) Keep track of your operations agent’s behavior with observability information about the monitoring and reasoning steps it takes. Track the LLM usage as the agent spots issues in your business, wakes up, reasons over the data, and recommends next steps. To learn more, check out the Create and configure operations agents page. Unified Semantic Understanding Build a shared business model with Ontology AI generation and query, letting teams create ontology definitions and ask questions using business terminology. Semantic Models as a data source, Ontology Metrics, and mirrored database and SQL DB bindings connect governed measures and source data without duplicating definitions. Namespaces, relationships without joins, keyless entity bindings, complex relationship modeling, reuse and inheritance, and the full canvas experience make large, cross-domain models easier to organize and evolve. RDF import and export, versioning, resource links and enrichment, and the new Overview and Instances views help teams reuse existing knowledge, understand model changes, and work with ontology data at scale. By working with Snowflake, we are helping customers reuse semantic context across platforms while advancing interoperability for semantic models and ontologies. By affirming our commitment to Apache Ossie (incubating), a community-led standard for exchanging semantic metadata, we are helping extend business meaning across analytics, AI, and BI ecosystems. This gives organizations a more open foundation for carrying consistent business meaning across the tools, platforms, and AI experiences they choose. Shared context for operations and AI Extend the semantic model into the experiences where decisions are made. Ontology-aware Real-Time Dashboards let teams build operational views from entities and relationships rather than raw tables, while Ontology Rules capture business logic and policies that can be interpreted consistently by people and agents. Ontology MCP tools make ontology definitions and queries available to external agents and developer tools, and Data Agents using Ontology as a context source can use mappings, synonyms, relationships, and bindings to produce more accurate and explainable queries. The planned integrations with Foundry IQ, CPS, and Operations Agent extend that shared context across Microsoft AI and operational workflows. Trusted, governed platform Apply enterprise controls as the ontology becomes a shared foundation for analytics and AI. OneLake Security and RLS ensure that ontology authoring and querying respect the permissions applied to the underlying data, while management APIs, CI/CD support, and the Ontology Management SDK are intended to support repeatable administration and deployment. Graph data materialization can be enabled selectively for exploration and multi-hop analysis, keeping graph generation an intentional choice rather than a requirement for every workload. Together, these advancements strengthen the foundation for enterprise intelligence: a shared, continuously updated understanding of the business that connects signals, context, decisions, and actions. As AI becomes embedded in every workflow, the defining question is no longer whether you have AI. It's whether your AI operates from a live, trusted understanding of the business. What does your AI run on? AI creates a new competitive boundary. The question is no longer how many agents an organization can deploy. It is whether those agents can reason and act from the same live, trusted understanding of the business. Can your data platform connect everything the business knows, preserve how entities change over time, operate with real-time freshness, support continuous intelligence at machine scale, govern every decision, and take action across the enterprise without forcing teams to assemble disconnected products? ise intelligence requires more than isolated AI capabilities. It depends on a platform that can connect data, preserve context, reason in real time, govern decisions, and drive action across the business. Fabric provides that foundation. It brings data, business context, intelligence, governance, decisions, and actions into one shared platform. As knowledge and outcomes accumulate, every new agent and application can inherit a richer operational understanding. The race is not simply to deploy AI. It is to build the foundation that makes AI effective. Trusted AI runs on Fabric. Learn more To learn more about the capabilities announced at FabCon and explore how Microsoft Fabric is helping organizations build the foundation for enterprise intelligence, visit the resources below. Complete the tutorial: Real-Time Intelligence | Ontology Ask questions on the forum: Real-Time Intelligence | IQ Submit ideas and vote: Real-Time Intelligence | IQ Use the docs: Real-Time Intelligence | IQ Complete the learning path: Real-Time Intelligence Get certified: Real-Time Intelligence Read the blog: Real-Time Intelligence | IQ Check the release plan: Real-Time Intelligence | IQ Explore the Microsoft Fabric documentation. Watch Fabric YouTube.
Planning in Microsoft Fabric: From insight to action
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. Planning in Microsoft Fabric IQ is redefining what modern enterprise performance management looks like. Organizations can build budgets, forecasts, targets, and scenario models directly on top of governed Fabric data and shared semantics — on the Power BI semantic models they already trust. Planning is no longer a separate system that data is copied into, and results copied back out of. That shift matters most in the era of AI. As organizations move from traditional applications to AI-powered, multi-agent systems, the advantage is shifting beyond the model you deploy. It now lies in the context an agent can reason over: how the business runs, the state it is in today, and where it is trying to get to. The first two are well served. The third, intent, usually lived somewhere else. Planning in Microsoft Fabric is different. The plan and the business intent behind it become a natural extension of how the business already measures performance and drives action. This ability to plan where the data lives has clearly resonated with customers — the growth and adoption of Fabric Planning since launch has been very humbling. When Planning in Microsoft Fabric became generally available in July 2026, we said we would extend it toward an agentic future: because plans, forecasts, targets, and actuals live together on Fabric's shared semantic foundation, Fabric IQ's ontology and data agents can reason over the goals your teams are working toward, not only the results they have delivered. That is the difference between explaining variance after the quarter closes and course-correcting while it is still open. Today we are taking the next step towards that future. We are announcing new capabilities that make planning more streamlined, more scalable, simpler to set up, easier to manage, and most importantly, more deeply integrated with Fabric IQ. From semantic model to plan in a few clicks We’ve made it simpler to get started with planning — instead of configuring shared cloud connections to the semantic model; planners can now connect to a semantic model directly by using their signed-in identity. Create a Plan artifact, choose a semantic model, connect, and start planning. Existing permissions and data access controls continue to apply, so nothing new has to be secured. For a finance team opening a new forecast cycle, that means less setup before they can start shaping the numbers — and for the organization, a faster path from trusted data to a working plan. Native integration with Fabric IQ Fabric IQ gives an organization a single, shared understanding of its business. OneLake and semantic models capture what happened. Real-Time Intelligence captures what is happening. Planning captures what should happen — the forward-looking layer of Fabric IQ. We are introducing a new capability which streamlines the integration with Fabric IQ so that the plan can more easily become part of that layer. Copilot, data agents and operations agents then have the ability to reason over historical performance, current operations, and future intent. The new writeback configuration experience makes it easier for planners to add budgets, forecasts, and scenarios back into the same semantic model the plan is already built on. Analytics and AI can then reason over more than just operational signals and historical KPIs — the foundation for intelligent action based on both actual performance and business intent. . Incorporating the plan into an ontology lets the organization represent planning concepts as business entities, properties and relationships, giving targets, forecasts and assumptions richer organizational context. This enables a new class of data-aware and intent-aware agents—capable of analyzing variance, evaluating scenarios, and surfacing recommendations that align with business priorities. Together, they close the loop between what has happened, what the business expects to happen, and what it is trying to achieve. "For us, the biggest benefit of Fabric Planning is speed: it lets us turn the semantic models and trusted business logic we have already invested in into planning applications, rather than rebuilding that foundation in a separate planning platform. And because plans sit in the same Fabric context as actuals, they can also give Copilot and agents the forward-looking business context to reason not only about what happened, but about what we expect and plan to happen next," said Patrick Sura, Director Business Intelligence EMEA, Dentsu. Plan at enterprise scale with the new Native Planning Engine The new Native Planning Engine, now in preview, is built on Rust and Apache Arrow with tight OneLake integration and delivers up to 10x improvements in performance and scale. Teams can work across tens of millions of cells, with dependent calculations updating as inputs change. That responsiveness is what changes the work. Planners can input and allocate across large, detailed business models, connect price and quantity through to revenue, cost, margin and profit, and keep complex plans connected across the enterprise — without splitting the model into smaller pieces to keep it workable. . "At Bosch Mobility, strategic planning starts with trusted data. Microsoft Fabric IQ Plan provides the scale and integration we need to connect complex market data across our business, creating the foundation for better decisions and future AI-driven insights," said Robert Finger, VP of Business Digitization, Bosch Mobility. Plan driven automation – From planning decision to business action A plan rarely stops when a value is submitted. Often a dependent downstream process needs to run, or a notification needs to be sent. Event triggers in Fabric Planning let planners configure what happens when a writeback event occurs. Event triggers turn every planning update into action, automatically kicking off downstream processes when writeback starts, succeeds or fails. Orchestrate business processes with Fabric pipelines, from consolidation to allocation. Transform and distribute planning data with Dataflow Gen2. Refresh semantic models to bring updated plans into analytics. Run notebooks for forecasting, optimization and machine learning. Keep teams informed through automated Teams notifications and Outlook email. This feature goes beyond simply starting a downstream process. Writeback details and execution metadata can be passed directly as parameters, giving downstream actions in the context of the planning event that triggered them. And with multiple triggers per planning sheet, teams can create different automation paths for different events, connecting planning changes to the right response across Fabric. Planning becomes more than capturing a decision. It becomes the trigger that puts the wider Fabric ecosystem in motion. Planning in organizational apps — One app for the business workflow A plan is rarely reviewed on its own. The people approving a forecast also want the reports and analysis that explain it, and that usually means sending them to several different places. Planning and Intelligence Sheets can now be embedded in an organizational app alongside Power BI reports and related analytics. A department manager opens one application link, reviews performance, reaches the plan, and continues the workflow — with navigation curated around the business activity rather than the workspace it happens to live in. Existing app audiences and access rules govern distribution, so leadership, managers and finance each see the content curated for them, wherever they open the app, including in Teams and SharePoint. Advanced driver modelling — See the full impact of a decision New multi-driver, multi-measure simulations help teams evaluate a decision as a connected set of trade-offs. A sales plan might assume higher volume and a lower selling price; operations can then test the material, labor and overtime implications and see how the combination changes profit. In Matrix or Tree View, changes flow through the configured driver relationships and relevant hierarchy detail, making the downstream impact visible. Teams can create scenarios such as Best Case and compare alternatives before committing a forecast. The result is a more informed decision: leaders see both the proposed action and its financial consequences in the same planning model. More ways to model and deliver planning The latest experience also expands how teams build and consume plans: Custom fiscal year planning supports calendars whose periods do not begin in January. Stepped, Outline and Tree layouts let teams shape the planning grid around the way their business works. Advanced lookups bring XLookup into the grid and enable PowerTable lookups into Fabric SQL. The goal is flexibility without fragmentation — different planning methods, one connected Fabric foundation. "Fabric Planning lets us tailor forecasting to each area of the business — top down, bottom up, driver-based, or assumption-based — without forcing everyone into the same methodology. By building on validated semantic models and capturing assumptions, commentary, and the story with the numbers, we shorten the development cycle, bring multiple perspectives together quickly, and gain deeper insight without the inefficiency of emails, meetings, and reconciliation," said Andrew Gundrum, Executive Director, Finance Data and Analytics, Merck. Billing and Governance Improvements Recently, we announced a change to the billing for non-planning editors, which means for PowerTable-only data management, editors are billed as Stakeholders and consumers as Viewers, so you get full data-management value without paying for a Planner session. Now also in preview are enhancements that provide administrators with new tenant-level settings to ensure you can put the right planning experience in the right hands. Administrators can control who can upgrade to Planner or Stakeholder sessions and can warn users before an action is likely to oversubscribe capacity. This ensures greater control over the amount of capacity consumption which can be incurred by planning sessions. What comes next The ambition is an AI-native planning experience — one where agents do not only read the plan, but take part in it. The next step is an API surface for the planning lifecycle, so an agent can work inside a plan the way a planner does: draft a forecast from what the model already knows, run a simulation across drivers, compare scenarios before a commitment is made, write the result back, and start the downstream work it sets in motion. Get started With Planning in Microsoft Fabric IQ, organizations bring planning, analytics, reporting and AI together on a single governed platform. From one input to enterprise-wide action, Planning connects the decision, the data, and the work that follows. Intent no longer has to live somewhere else. It sits in the model the business already trusts, beside the results it will be measured against — where the people running the business, and the agents working alongside them, can act on it together. Learn more about Planning in Fabric IQ: Read the documentation Learn more about Fabric IQFrom prompt to production: What's new in Fabric Apps
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. Fabric Apps is the application layer built on Microsoft Fabric. At FabCon Europe, it gains backend functions, storage, a family of data connectors, PostgreSQL, built-in app metrics, and a clearer enterprise access model. Our industry has gotten really good at helping people visualize data. With semantic models and reports, we can deliver trusted insights that create shared understanding. But how do those insights become something people can act on? How do they become part of the products and workflows where decisions happen? That last mile needs an application: a place to turn an insight into a recommendation, make a decision, take action, and keep a durable record of it. Traditionally, building that application has meant a lot of work: setting up databases and authentication, copying data, and going through lengthy security reviews. As a result, insights often get stuck in the report. Agents have solved part of this problem. They’ve made front-end applications dramatically easier to create. But the backend (data, auth, security, and sharing) remains difficult. We want to change that. That’s why my team built Fabric Apps: an application layer on Microsoft Fabric that lets you build secure, data-rich applications directly on the data, semantic models, and services you already trust. Since launching in June 2026, more than 15,000 developers have built a Fabric App. Check out the gallery. The number is encouraging. But what I find even more exciting is who has been building. We have seen a new group of “builders” creating Fabric Apps. Designers are shipping experiences they used to hand off. Product managers are testing ideas in a working application rather than a slide. Finance teams are building tools for the workflows they know better than anyone. And today at FabCon Europe, we’re thrilled to announce that we are expanding Fabric Apps with backend functions, built-in storage, and direct connections to even more of your Fabric data, so these new builders can go even further. Rayfin: The development framework behind Fabric Apps Rayfin is the code-first framework that powers Fabric Apps. You or your coding agent describe an application in TypeScript. Rayfin's SDK and CLI generate typed APIs and clients, run the whole application locally, and deploy it as a Fabric App, where database, storage, connectors, functions, and authentication are running and governed for you. No infrastructure tickets, and no credentials scattered across environments. Your data stays where it is. Build on the data you already have Fabric data connectors Fabric Apps now connects directly to Fabric SQL Databases, Warehouses, Lakehouse SQL analytics endpoints, and semantic models. Users don’t want to copy data into an application. Copies add cost, complicate lineage, and make every governance review harder. SQL Database and Warehouse support read and write; Lakehouse SQL analytics endpoints and semantic models are read-only. Schemas are discovered automatically and exposed through the same typed programming model you use for app-owned data. Declare the source in rayfin.yml: connectors: - name: inventory type: fabric-warehouse config: { workspaceId: ${WS_ID}, itemId: ${ID} } auth: { type: delegated } - name: salesModel type: fabric-semanticmodel config: { workspaceId: ${WS_ID}, itemId: ${ID} } auth: { type: delegated } Then use it from application code: TS // Tables: query entities through a typed, fluent API. const products = await client.connectors .inventory.Product .select(['name', 'sku']) .execute(); // Semantic models: query the model directly with DAX. const revenue = await client.connectors .salesModel.executeQuery({ query: 'EVALUATE TOPN(10, Sales)', }); The second example is worth a closer look. Your revenue, target, and margin definitions already exist as measures that the business has debated, corrected, and agreed on. Rather than reimplementing that logic in JavaScript, an application can query the model and get the same answer everyone else gets. Identity travels with the query. With auth: { type: delegated }, the connector runs as the signed-in user and the source enforces its own authorization, including row-level security. Application identity is available when an app legitimately needs its own permissions, but it does not inherit a user's permission boundary. Choose deliberately. Give your application a place to write PostgreSQL support, alongside SQL Server A dashboard is read-only. An application needs somewhere to store the note someone captured, the decision made, and the plan that was approved. Fabric Apps now supports PostgreSQL alongside SQL Server, using the same data-modeling experience, generated GraphQL APIs, typed clients, CLI, and local development workflow. Define entities in rayfin/data and register them in the schema; rayfin up provisions the service and applies the schema. YAML services: data: enabled: true dialect: mssql # or postgresql TS const record = await client.data .CustomerFeedback.create(formValues); const saved = await client.data .CustomerFeedback.findById(record.id); The schema ships with the application as code, so there are no connection strings to manage and no migration scripts living on someone's desktop. Keep documents next to the data Storage Records are structured, but the work around them usually arrives as attachments: a transcript, a signed PDF, an image someone needs to review before approving anything. Storage is defined in code exactly like your database: folders, accepted file types, size limits, and permissions in TypeScript. The record goes in the database, the document goes in storage, and the record keeps a reference to it. YAML services: data: enabled: true storage: enabled: true TS const { path } = await client.storage .documents.upload(file); await client.data.CustomerFeedback.create({ ...formValues, documentName: file.name, documentPath: path, }); Write backend logic Functions and Secret Store Most applications eventually reach the edge of the standard building blocks, whether that's a business rule, a third-party integration, a multi-step workflow, or an AI call that has to run outside the browser. Functions let you write server-side logic in TypeScript alongside your application code, while Fabric handles hosting, authentication, deployment, security, and scaling. Code lives in rayfin/functions and ships with the app on rayfin up. YAML services: functions: enabled: true TS const result = await client.functions .generateProductIdeas.invoke({ brief: 'Opportunities for the next quarter', context, // measures from a connector + records from app data }); Behind a single typed call, a function can query a semantic model through a connector, read application data, apply your business rules, and call a Microsoft Foundry model deployment through an AzureAI connection. Functions run under the app identity and can forward signed-in user context, so downstream calls can use either application or delegated authentication. Secret Store keeps the API key out of your application entirely. It encrypts credentials and provides them to functions only at runtime, so they don't need to live in application code, source control, or a build pipeline. Understand how your application performs Built-in app metrics Every Fabric App now includes usage and performance metrics out of the box: sign-ins, app loads, data-query volume, query errors, error rates, and average query duration. Developers and application owners shouldn't have to stand up a separate telemetry service to understand adoption or to notice that a query slowed down after last week's change. Start with a template Universal App template and GitHub Copilot plugin Install the Rayfin plugin and your coding agent gets guidance matched to the SDK version it is actually building against, instead of an API shape it half-remembers. With the new Universal App template, an agent can turn a prompt into a Fabric-authenticated, deployable project with very little setup. Generated code is a starting point, not a production specification. Review it, check the permissions it requests, test the workflow, and put it through the same scrutiny as anything else you ship. Your entire application, in code Your screens, data schema, authentication configuration, functions, and data connectors are all defined in source code, in a single project. That property is what makes a coding agent useful rather than risky. Typed entities make field names and call shapes explicit instead of inferred, so mismatches surface while you are still developing. The agent works from the application's actual model rather than a guess at it. Type safety is not a substitute for runtime validation, authorization, or code review. All three still matter. Built to be governed Applications built with Fabric Apps are private by default. Microsoft Entra authentication happens before any application content is delivered, rather than as a redirect inside a page that has already loaded. Builders then choose private or embedded-only access, or public access for approved anonymous scenarios. Tenant-level controls let administrators govern how applications can be exposed at all. We've also made sharing across supported Fabric items clearer. One distinction matters more than any other: Authentication determines who can open the application. Fabric permissions determine which data they can reach inside it. When a connector uses delegated identity, that second answer is the signed-in user's own permissions, enforced at the source. Fabric Apps keeps the two questions separate by design. What's coming next Our plans for later in 2026 include an admin and security portal, integration into Microsoft Copilot, app insights with every application, a Kusto data connector, app sharing with provenance, support for custom claims, OneLake-integrated application storage, embedding, and deployment pipelines. We're early in this work, and there is a lot more to come. Getting started You can begin from wherever you work today: GitHub Copilot, install the Rayfin plugin and scaffold from the Universal App template. The Fabric portal, create a new App item in your workspace. Replit, our featured partner, directly in the browser. I'd suggest starting with a single workflow that currently begins in a dashboard and ends in a spreadsheet and then building the ending. In my experience that workflow is usually a decision someone makes every week, records informally, and then reconstructs from scratch the following month. It is also usually a small application, and usually best built by the person who runs the workflow rather than by whoever has room on an engineering roadmap. Please tell us how it goes. What worked, and what got in your way? What do you need next? You can file issues in the Rayfin GitHub repository, and my team will read them. If you're joining us in Barcelona, Ben Zulauf and I are presenting From Prompt to Production: Building Governed Apps on Fabric with Rayfin. Our team will also be at the Ask the Experts booths in the expo hall throughout the conference. Share your apps and feel free to bring a workflow you'd like to improve. We'd be glad to look at it with you.
