Manage Fabric connections at scale with connection recency in Fabric REST APIs
Understand Connection Recency Connections are shared infrastructure in Microsoft Fabric. Pipelines, dataflows, semantic models, and other Fabric items use them to reach data sources without storing connection details and credentials in every item. Connection Recency adds the context administrators need to understand how each connection is being used. If you go to “Manage Connections and Gateways” in Fabric settings and open the settings of any connection, the following information card will populate: The card provides three insights: Created on shows when the connection was created. Last Bound to items shows when an item was most recently associated with the connection. By any user reflects activity across the tenant, and By me is specific to the viewer. Last credentials used shows when a workload most recently used the connection credentials. It also separates activity By any user from activity By me, which is the current user. Linking and usage are different events. A connection can be linked but never used, or it could have been linked a long time ago to an item that still runs every day. Credential-use information can also be up to 30 minutes behind real time, so use it for governance and investigation rather than immediate usage monitoring. Learn more in the Data source management documentation. Why enterprise connection management becomes difficult Connections can grow exponentially across a large organization. Every team, project, environment, gateway, and data source can introduce more connections. Over time, names become inconsistent, employees move on, and multiple connections can point to the same endpoint. The Fabric interface is useful for inspecting one connection, but reviewing recency and ownership one connection at a time does not scale to an enterprise inventory. This creates three common problems: Stale connections: A connection may no longer support an active workload, but its name, creation date, and Last Bound Date do not prove that it is unused. Administrators need both Last Bound Date and Last Credential Use signals before deciding what to review or retire. Duplicate connections: Different display names can hide equivalent connection definitions. Duplicates increase credential maintenance, complicate troubleshooting, and make it harder to establish a preferred connection which dilutes the advantage of connection sharing and reuse across a tenant. Ownership risk: A connection with only one person as an owner can become orphaned when that person leaves the organization. The connection might then be unavailable for administration or no longer usable by dependent workloads. The REST APIs make it possible to evaluate these risks across every connection the caller can access. In the case of cloud connections, you can only see connections where you are the owner, but the admin for a gateway can see all connections on the gateway. This provides better scalability than the UI. Using the APIs to manage connections You can use the APIs to identify stale and duplicate connections for removal and to help mitigate the issue of single user ownership. Gateways in Fabric have a limit of 1,000 connections, so managing and governing your connections will help you stay under that limit. Now that we understand each of the three scenarios, let’s see what the API can provide to help us handle each scenario: Stale connections: LastBoundDateTime is the first of two signals we can use. If this is NULL, then it is currently not being used by a Fabric item and would be a candidate for removal. The one catch is that connections bound prior to recency being introduced will also show NULL, so we must filter out anything with a CreatedDateTime earlier than the introduction of the recency feature. Recency came out in preview at the end of March 2026, so my example code will filter anything created prior to May 1, 2026, to play it safe. The second signal we have is the LastCredentialUsedDateTime, which indicates the last time the connection was used by any item. You can change this in the example code, but I’m going to use 90 days. You might have connections that legitimately get used less frequently, such as year-end runs or only during the holiday season, so keep that in mind when reviewing and adjust accordingly. Duplicate connections: It is possible for two connections to have identical configurations except for the DisplayName. This defeats the purpose of having shareable connections, so we’ll need to use the LastCredentialUsedDateTime to determine which one was most recently used and flag any others to be considered for removal or consolidation. We’ll use ConnectionType, ConnectionPath, ConnectivityType, and GatewayID to identify duplicates. There are other columns you may want to add, such as CredentialType or ConnectionEncryption, depending on what you consider duplicate in your specific environment. Ownership risk: For ownership continuity, you want to identify connections whose only Owner role assignment is a User, then add another approved owner. This helps avoid having an orphaned connection if an owner gets deleted. Adding a Microsoft Entra group is preferred because group membership can be maintained as people join, leave, or change responsibilities. A second individual owner is better than a single owner, but it does not provide the same durable operating model as group ownership. MYTH: A common misconception is that a connection fails when its owner account is deleted. In reality, what matters is the credential being used for authentication. When you create a connection that uses OAuth, you become the owner and your OAuth credential is typically used. If your account is later deleted, the connection fails because it can no longer authenticate with that credential, not because ownership changed. If the connection instead uses an SPN and is shared with another user, it will continue to work. Explore the List Connections, List Connection Role Assignments, and Add Connection Role Assignment documentation for the complete request, pagination, identity, and permission details. Next steps Run the companion notebook first. The notebook is designed as a Python notebook to be run in the Fabric Python runtime and not the PySpark Python runtime. There will be a section for each of the previous scenarios. Stale and duplicate connections will be shown so you can review before deciding what to remove, but that part will be up to you. You can use the data frame and pass the connection ID values to the Delete Connection API. If you don’t know how to write that part, then it’s a great opportunity to use Copilot. The ownership section will show you all connections with a single owner where you will want to add another owner. As a best practice, we’ll assume you are adding a group, but that part will be commented out as you very likely do not want to blatantly add the same group to every connection across the board. You can use the Add Connection Role Assignment API to make those additions as you need. Connection recency data gives you the signals you need to manage connections at scale, but it should be the starting point for review rather than the basis for automatic removal. Use the companion notebook to identify potentially stale or duplicate connections and connections with a single owner, then apply your organization’s requirements before taking action. Regularly reviewing these signals can help you reduce unnecessary connections, improve ownership continuity, and establish a more manageable connection inventory.Fabric Data Warehouse best practices for medallion architectures
Part three of a series on medallion architecture with Fabric Data Warehouse. Good medallion architecture is mostly operational discipline. In part one of this series, we chose the pattern, and in part two, we filled in the Bronze, Silver, and Gold layers. Now comes the part that usually determines whether the architecture holds up in production: the operating rules. Many medallion architectures look great on paper but become difficult to maintain as data volumes, business requirements, and consumers grow. A medallion pipeline is easy to explain and easy to demo. It is more challenging to keep clean over time. The challenges usually start small: row-by-row loads, report-specific logic in the wrong place, transformations that cannot be safely rerun, or Gold tables that slowly become another staging layer. Why this matters Most medallion problems are not caused by the names Bronze, Silver, and Gold. They happen because the pipeline stops behaving like a pipeline. Bronze starts cleaning. Silver starts serving dashboards. Gold starts compensating for upstream data quality. Before long, nobody knows where a rule belongs, and every change feels risky. The goal of best practices is not to add ceremony. The goal is to make the pipeline predictable: predictable loads, repeatable transformations, trusted outputs, and clear places to look when something breaks. Best practice 1: Batch the writes Fabric DW is built for set-based work. Treat ingestion and transformations as batches, not as a stream of tiny row-by-row operations. In Bronze, that usually means using COPY INTO, Fabric Pipelines, or other bulk-loading patterns to land data in raw tables. If you are loading from files, aim for fewer well-sized files instead of many tiny ones. When practical, files in the 100 MB to 1 GB range are a healthier starting point than a long tail of small files. In Silver and Gold, the same idea applies: prefer set-based T-SQL transformations, CTAS, INSERT...SELECT, and MERGE patterns over procedural row-at-a-time logic. Do this well Load Bronze in batches, and avoid trickle inserts when the source can be staged first. Add ingestion metadata, such as source file name and load timestamp, so every batch is traceable. Keep operational logging lightweight. If you need very high-write audit events, do not turn the warehouse into a single-row logging engine. Let Bronze preserve the batch; let Silver decide what is valid. Rule of thumb: if a load pattern creates a large number of tiny writes, fix the load pattern before tuning the query. Best practice 2: Make Silver rerunnable Silver is where the pipeline earns trust. That means Silver transformations need to be repeatable, testable, and safe to rerun. If an upstream source reloads, or a cleansing rule changes, you should know how to rebuild the affected Silver tables without guessing which reports need to be patched. This is where idempotent design matters: a transformation should produce the same result when run again against the same inputs. In Fabric DW, use CTAS when you want to materialize a clean table from a query, INSERT...SELECT for controlled incremental loads, and MERGE when late-arriving or changed data needs to update existing Silver rows. Do this well Design transformations so they can run again without duplicating or corrupting data. Use staging tables when the logic is complex. A few clear steps are easier to operate than one unreadable query. Put quality gates in Silver: required fields, valid formats, duplicate handling, and reason codes for rejected records. Choose precise data types and lengths. Silver is the right place to turn loose source data into reliable analytical data. Rule of thumb: if a report needs to clean the data again, Silver did not finish its job. Best practice 3: Shape Gold for consumption Gold is not just “the final table.” Gold is the business-facing serving layer. It should be modeled around how people ask questions, not around how the source systems store data. For some workloads, that means a star schema with fact and dimension tables. For others, it means a data mart, a wide reporting table, or a pre-aggregated summary. The pattern matters less than the principle: Gold should make the common analytical path simple, fast, and trustworthy. This is also where you should be careful not to let Gold become a junk drawer. If Gold is full of one-off fixes, report-specific exceptions, and raw technical fields, the layer is doing too much. Do this well Model the grain explicitly. A fact table without a clear grain becomes hard to explain and harder to debug. Pre-aggregate where the business repeatedly asks the same question. Hide technical fields that helped the pipeline but do not help the consumer. Keep Gold dependent on Silver by default. Direct Gold-to-Bronze dependencies should be rare and deliberate. Rule of thumb: Gold should answer the business question quickly without making the report author rediscover the pipeline. Best practice 4: Use Fabric DW defaults, but do not fight the engine Fabric DW gives you a SQL warehouse over Delta data in OneLake. That means you get transactional behavior, optimized storage patterns, and a managed engine that handles many physical decisions for you. The practical advice: do not bring every habit from traditional data warehousing with you. You do not need to micromanage distribution or indexing the same way you would in older platforms. Focus first on healthy data layout, set-based transformations, good table design, and predictable query patterns. At the same time, do not ignore the basics. Query performance still benefits from clean data types, useful statistics, well-shaped Gold tables, and avoiding unnecessary scans. Do this well Keep V-Order and platform optimizations on unless you have a measured reason to change them. Use the performance guidance for Fabric Data Warehouse before inventing custom tuning patterns. Check query behavior when a Gold table becomes critical to many reports. Treat advanced exceptions as exceptions. Most teams should start with the defaults and tune only when evidence says to tune. Rule of thumb: tune from evidence, not from habit. Best practice 5: Monitor by layer A medallion pipeline should be observable at each layer. If a dashboard is wrong or slow, you should be able to tell whether the issue started in Bronze ingestion, Silver transformation, or Gold serving. In Fabric DW, use Query Insights and the warehouse monitoring views to understand query behavior, expensive operations, and refresh patterns. Pair that with pipeline-level monitoring so you can see not only whether a job failed, but where the failure happened. Measure the pipeline in terms the team can act on: Bronze load duration, Silver transformation duration, rejected-record counts, Gold refresh duration, and Gold query performance. Do this well Track load and refresh duration by layer. Log the number of records received, accepted, rejected, and published. Watch critical Gold queries after refresh, especially the ones that feed executive dashboards or widely used semantic models. Keep operational alerts tied to business impact. A failed Gold refresh matters differently from a delayed Bronze load. Rule of thumb: if you cannot tell which layer failed, your monitoring is not layer-aware enough. Before moving a medallion pipeline into production, use the following checklist to verify that each layer is operating as intended. The best-practice checklist Area Bronze Silver Gold Write pattern Batch ingest with metadata Set-based transformations Scheduled refreshes Quality rule Preserve what arrived Validate, conform, and flag Expose trusted fields only Performance focus Avoid tiny writes Keep logic rerunnable Shape for common queries Takeaway Part two of this series was about one job per layer. Part three is about operating each job like it matters. Batch the writes. Make Silver rerunnable. Shape Gold for consumption. Use Fabric DW’s managed engine instead of fighting it. Monitor the pipeline by layer so failures are easy to locate and fixes happen in the right place. If you follow those rules, your medallion architecture becomes less fragile over time, not more. This post is part of our Medallion Architecture on Fabric Data Warehouse series: Choosing your medallion pattern in Fabric Data Warehouse Building the Bronze → Silver → Gold layers Fabric DW best practices for medallion architectures Securing and governing your layers Performance tuning your medallion pipeline Ready to go deeper? Explore the Microsoft Fabric Data Warehouse performance guidelines and ingestion guidance, then stay tuned for Part four of this series, where we’ll cover securing and governing your layers.Connect securely to Snowflake in Fabric Pipelines and Copy Jobs
Snowflake is a common source and sink for enterprise data movement, and Microsoft Fabric Data Factory supports it in both pipelines and Copy Jobs. For organizations that restrict public network access, some additional considerations are needed to meet that requirement. You can have private inbound and outbound access to Fabric, a private staging storage account, and a private Snowflake instance. By combining Workspace-level Private Link, a private Azure Storage account, and Snowflake's storage integration with USE_PRIVATELINK_ENDPOINT, you can keep the path entirely private. This post explains how those controls fit together for Fabric Data Factory pipelines and Copy Jobs. When this might apply Your organization might require private networking, where every hop needs to be inspectable and privately routed. Regulated workloads in financial services, healthcare, and public sector regularly require that analytics platforms have no public endpoints, that inbound and outbound traffic to storage stays inside a VNet, and that any third-party SaaS integration uses private links where supported. Snowflake supports Azure Private Link for storage endpoints and Fabric supports Workspace-level Private Link for inbound workspace access which can be combined to achieve a private path. Using each control for its intended direction avoids public exposure. The challenge The Snowflake connector in Fabric Data Factory uses Snowflake's native COPY command under the hood and requires an interim storage account for data staging. Currently, staging is not supported by Onelake when using Workspace-level Private Link, so an external Azure Storage account can be used instead. Staged copy supports source or destination shapes that aren't natively compatible with Snowflake's COPY command and can improve throughput. The catch is the Azure Storage account sits between two systems that each have their own network story: Fabric on one side and Snowflake on the other. Locking down the copy path end-to-end means securing all three surfaces — the Fabric workspace, Azure Storage staging account, and Snowflake. The core model Think of the topology as two independent network paths that meet at the staging account. Figure: Private Path for Snowflake in Fabric Pipelines and Copy Jobs. Inbound Access to the Fabric Workspace — Workspace-level Private Link maps the workspace to an approved VNet and lets you deny public inbound access. It doesn't place the Fabric workspace inside your VNet or govern outbound data-source traffic. Azure Blob Staging — Trusted Workspace Access provides a private connection from the Fabric Workspace to your storage account. Not only is it private, but it uses a Workspace Identity to authenticate and a Resource Instance rule to only allow specific workspaces. Snowflake to Staging Storage — Snowflake provisions a private endpoint into your Azure tenant against the same staging account. The Snowflake storage integration is created with USE_PRIVATELINK_ENDPOINT = TRUE so Snowflake's own copy operations honor the private path. Public Internet Access — Public network access on the storage account and Fabric Workspace is blocked. Network access and authorization are separate. Snowflake's storage integration provisions a service principal in Azure. This SPN will need Storage Blob Data Contributor permission on the staging storage account. The Fabric Azure Blob connection uses the authentication configured for that connection, such as workspace identity. That identity will need Storage Blob Data Reader on the staging storage account. Setup The full configuration breaks into five phases: Build the Network Foundation. Create a workspace, Azure private link service, virtual network, virtual machine, private endpoint from the workspace to the private link service and finally turn off public networking to the workspace. Complete instructions for all these items can be found in the Set up and use Workspace-level Private Links documentation. Create Staging Storage Account. Use these instructions to create an Azure storage account. Once you have an account you need to configure Trusted Workspace Access for private networking between your Fabric Workspace and the staging storage account. Configure the Snowflake side. In Snowflake, create a private connectivity endpoint that points at the external staging container and set USE_PRIVATELINK_ENDPOINT = TRUE. Snowflake provisions a service principal in your Azure tenant on your behalf. Grant that service principal the Storage Blob Data Contributor role on the staging account. This lets Snowflake read from and write to staging over the private endpoint using its own identity. Close the public paths. You should have already denied public inbound access to the Fabric workspace as the last part of the instructions provided in step 1. You also need to disable public network access to the staging account by setting the default public network access rule to disabled. Create Copy Activity or Copy Job. Create your pipeline with Copy Activity or, even better, create a Copy Job. Then select Snowflake as the source or destination, enable external staging, select the staging storage account, enter the required storage path, choose a destination, and run the item. Boundaries and things to check A few constraints are worth calling out before you plan a rollout: Workspace-level Private Link prerequisites. Confirm that your Fabric capacity SKU and region support Workspace-level Private Link, and that your tenant admin has enabled the required tenant settings. Staging is Azure Blob. External staging for Snowflake in the Copy Activity uses an Azure Blob container. You don't need to enable hierarchical namespace on the account for staging to function. Snowflake USE_PRIVATELINK_ENDPOINT requires a supported Snowflake account. Snowflake-managed outbound private connectivity endpoints require Business Critical edition or higher. Confirm that the feature is enabled for your Snowflake account before provisioning the endpoint. Private Endpoint Approval. The private endpoint from Snowflake into your storage account will be in a pending state and must be approved on the storage account. Next steps If you're evaluating Snowflake as a source or sink in Fabric today, deploy this topology end-to-end in a non-production workspace before you promote it. The moving parts are simple individually, but each one must be in place for the private path to hold. Learn more from the following documentation: Set up and use Workspace-level Private Links in Microsoft Fabric Configure Snowflake in a copy activity in Fabric Data Factory Use workspace identity in Fabric Data Factory Configure trusted workspace access in Microsoft Fabric Snowflake: Configuring an Azure container for loading data Snowflake: Managing Azure Private Link endpointsChoosing your medallion pattern in Fabric Data Warehouse
Coauthor: Artur Vieira Part one of a series on medallion architecture with Fabric Data Warehouse. Medallion architecture is one of the most common patterns for organizing data in Microsoft Fabric, but successful implementations require a series of design decisions — from choosing the right architecture pattern to securing, governing, and optimizing your workloads. In this five-part series, we'll walk through the practical choices that shape a modern medallion implementation in Fabric Data Warehouse (DW), sharing recommendations, tradeoffs, and real-world guidance along the way. In this installment, we'll focus on the first and most important decision: choosing the right medallion pattern for your workload. Why this matters Most teams designing a medallion architecture in Microsoft Fabric start with the wrong question: "Should I use a Lakehouse or a Warehouse?" The better question is, "How much Spark do I actually need?" Your answer will shape everything from development workflows to security and long-term maintenance. Quick level-set: medallion organizes data into three layers — Bronze (raw), Silver (enriched), and Gold (curated) — to progressively improve data quality and structure. That’s the whole definition you need. The interesting part is how you map those layers onto Fabric. The key decision: Data Warehouse, Lakehouse, or both? Fabric gives you two major analytics storage options on OneLake: Lakehouse and Data Warehouse. Because Fabric DW is an enterprise-scale SQL warehouse built on the open Delta Lake format in OneLake — combining a relational SQL engine with lake storage, so data is stored as Delta Parquet with ACID transactions and time travel — you don’t have to choose between “warehouse” and “lake.” You’re really choosing how much of the pipeline you run in T-SQL versus Spark. That leads to two patterns worth recommending: an all-in-one or hybrid approach. Pattern A: All-in-One Data Warehouse Use Fabric DW for Bronze, Silver, and Gold, separated by schemas (for example Bronze.*, Silver.*, Gold.*) or by separate warehouses, with data flowing raw → curated entirely within the warehouse using T-SQL or Data Factory pipelines. Best when: most of your data is structured (or can be structured on load) and your team prefers SQL-centric development. Why it’s nice: one engine, one skill set, transactions and views for every hop. Pattern B: Lakehouse + Warehouse Hybrid Land raw data in a Lakehouse for Bronze (and optionally Silver), where you can use Spark for complex prep, then implement Gold in the Warehouse as the SQL serving layer for BI. This works seamlessly because OneLake underpins both — Silver or Gold data can be materialized to Delta tables and queried by the Warehouse’s SQL endpoint without copying. Best when: You have unstructured or semi-structured data, or need heavy data engineering in Python or Scala. Why it’s nice: The right engine for each layer — Spark for heavy prep, T-SQL for serving — with no data copying, since OneLake underpins both Which should you pick? Here’s the rule I’d give a customer: Rule of thumb: For most SQL-focused analytics teams, an all-in-one Fabric Data Warehouse is the pattern I’d recommend starting with. If you have a mix of unstructured data or need heavy data engineering, land and refine raw data in a Lakehouse, then serve the final Gold layer from the Warehouse. Fabric’s architecture lets you evolve, so you’re not locked in: start all-in-warehouse and add a Lakehouse later when a new source needs Spark, or vice versa. All-in-One DW Lakehouse + DW Hybrid Primary skill T-SQL Spark / Python + T-SQL Best for data Structured / relational Unstructured, semi-structured, streaming Bronze lives in Warehouse staging tables Lakehouse (raw files, delta tables or both) Gold lives in Warehouse Warehouse Pick it for Simplicity, one engine Flexibility, heavy engineering One layout rule, whichever pattern you choose Keep layer separation clear. Microsoft recommends isolating layers into different workspaces, or at least different Fabric items, for better control and governance. The payoff is real: separate items give you finer security control — only data engineers touch Bronze while analysts see only Gold — and clearer isolation, so an accidental change in Gold can’t affect Bronze. Takeaway Don’t frame this as “Warehouse vs. Lakehouse.” Frame it as “How much Spark do I need?” If your workloads are structured and SQL-first, choose an all-in-one DW. If they’re unstructured or engineering-heavy, choose a hybrid approach, with Gold always served from the Warehouse. As your implementation grows, consider separating Bronze, Silver, and Gold into distinct Fabric items or workspaces to simplify governance and security. Ready to go deeper? Explore the Microsoft Fabric documentation for Data Warehouse and OneLake, then stay tuned for Part 2 of this series, where we'll walk through howBronze, Silver, and Gold layers are implemented in practice. This post is part of our Medallion Architecture on Fabric Data Warehouse series: Choosing your medallion pattern in Fabric Data Warehouse Building the Bronze → Silver → Gold layers Fabric DW best practices for medallion architectures Securing and governing your layers Performance tuning your medallion pipeline In the next post, we'll explore what Bronze, Silver, and Gold layers actually look like in Fabric Data Warehouse and how data moves between them.
Fabric Data Agents in Microsoft Copilot Studio (Generally Available)
Organizations can now bring governed business data from Microsoft Fabric into Copilot Studio agents, enabling agents to answer questions, generate insights, and support business processes using trusted enterprise data. Fabric data agents make it easier to ground experiences in the data your organization already relies on. Since we announced this integration in preview, both Fabric and Copilot Studio have evolved significantly. General availability provides a more integrated experience, broader publishing options, and a stronger foundation for deploying data-powered agents across the Microsoft ecosystem. Fabric Data Agents are now integrated as tools Previously, you added a Fabric data agent from the Agents category as a connected agent. Now, Fabric data agents integrate through the new tool-based experience in Copilot Studio. Simply select Add a tool, search for Fabric, and select Fabric IQ Data MCP. Your Copilot Studio agent can then invoke the Fabric data agent the same way it calls any other tool. The orchestrator decides when to reach for enterprise data and when to rely on its other knowledge sources and tools. The Fabric data agent continues to execute in Fabric, respect permissions on underlying data sources, and return answers grounded in governed enterprise data. The benefit is a more composable architecture. A Fabric data agent becomes one capability among the connectors, workflows, and other tools available to your Copilot Studio agent. You can combine multiple Fabric data agents with other business systems to create richer, more capable solutions. Built on the new Copilot Studio experience and runtime Copilot Studio introduced a redesigned authoring surface and runtime powered by the GitHub Copilot harness. You can build, test, evaluate, publish, and monitor agents from a unified environment while using natural language to describe agent behavior and capabilities. For Fabric customers, the biggest benefit is improved orchestration. The harness uses an improved reasoning model that is better at deciding which tool to call and how to combine what comes back, which matters when a Fabric data agent sits next to SharePoint knowledge, connectors, and other tools in the same agent. You choose the harness when you create the agent. Agents built with the standard harness remain fully supported. Instead of building isolated data experiences, organizations can create agents that reason across multiple sources of enterprise knowledge while using Fabric as their trusted data foundation. Publish to Microsoft Teams and Microsoft 365 Copilot Another improvement since preview is broader reach. You can now publish your Copilot Studio agent to Microsoft Teams and Microsoft 365 Copilot, bringing governed, data-grounded experiences directly into the tools people use every day. For example, a business user can ask about last quarter's regional performance in Microsoft 365 Copilot and get an answer from governed Fabric data without leaving the conversation they are already in. As always, permissions continue to apply. Users must have access to the Fabric data agent and its underlying data sources. d GIF - Add Fabric data agent as a tool to your Copilot Studio Agent. Why this matters The rise of AI agents is creating a new challenge for organizations: how to ensure agents are grounded in trusted business data rather than disconnected information sources. Fabric and Copilot Studio solve different parts of that challenge. Fabric provides the intelligence layer. It is where organizations bring together, govern, and publish data expertise through data agents. Copilot Studio provides the orchestration layer. It is where organizations build agents, workflows, and business processes that put that expertise to work inside a broader business process. Adding a Fabric data agent means everything you compose there can reason over governed enterprise data. Now, Fabric data agents and Copilot Studio (Generally Available) makes it easier than ever to bring governed data, business context, and intelligent action together in a single agent experience. Together, they enable organizations to: Build multi-agent solutions. Fabric data agent supplies the analysis while other agents and tools carry the rest of the process, such as drafting the document, updating the system of record, or routing an approval. Bring data together with everything else your agent knows. A Copilot Studio agent can pull a number from Fabric and a policy from SharePoint in the same answer. Meet users where they work. Publish to Teams and Microsoft 365 Copilot so business users get data-grounded answers in the flow of their work. Keep one definition of your data. Fabric data agent stays the single source of truth for every Copilot Studio agent that consumes it, so answers do not drift between teams. Build it once in Fabric and reuse it across departments. Getting started Getting started with Fabric data agent integration with Copilot Studio (Generally Available) is easy: Build and publish a Fabric data agent with a clear, detailed description. Create or open an agent in Copilot Studio. Under Tools, select Add a tool, search for Fabric, and add Fabric IQ Data MCP. Test your agent in Preview. Publish to Microsoft Teams or Microsoft 365 Copilot. To learn more, refer to the Add a Fabric data agent as a tool in Microsoft Copilot Studio documentation for the full setup, and join the community discussion to share feedback and report issues.New CI/CD resources for Microsoft Fabric: from concepts to end-to-end automation
Introducing a new set of resources that make it easier to build continuous integration and continuous deployment (CI/CD) into your Microsoft Fabric data projects. A Fabric solution is rarely a single artifact. It is a composition of workspace items, and with more than 70 item types available today (and the number continuing to grow), moving a solution from development to production takes a deliberate plan. These new resources connect the platform capabilities into one coherent workflow and form a path you can follow end to end: understand the platform, plan your approach, get hands-on with guided tutorials, and reach for advanced options when your scenario calls for them. Get started: Introduction to CI/CD in Microsoft Fabric The new Introduction to CI/CD in Microsoft Fabric is the main landing page for these resources. It explains the platform layer by layer, from the Fabric REST API foundation through Git integration, deployment pipelines, the Variable library, the Fabric CLI, infrastructure as code with Terraform, and the fabric-cicd library. It also includes an enterprise reference architecture that shows how source control, CI automation, capacities, and workspaces fit together. If you are new to Fabric CI/CD, or want to understand how the pieces relate, start here. Plan with confidence: Concepts and best practices guide The Fabric CI/CD concepts and best practices guide moves from foundational concepts to platform capabilities, automation tooling, and a practical checklist you can apply to your projects. It explains what constitutes a Fabric solution, how a CI/CD project moves that solution across isolated dev, test, and prod environments, and which design decisions make promotion safe and repeatable. Use the best practices checklist when planning your next project. Get hands-on: New step-by-step tutorials For teams that learn by doing, new guided tutorials cover the full journey, from an automated end-to-end pipeline to focused walkthroughs of each approach: Automate an end-to-end CI/CD workflow A full walkthrough that uses Terraform to provision the dev, test, and prod workspaces and the fabric-cicd library to deploy content between them, tying the pieces into one automated flow from source control to production. To learn more, refer to the Automate an end-to-end CI/CD workflow tutorial. Deploy locally with the fabric-cicd library or the Fabric CLI Set up a basic development environment and deploy a lakehouse and notebook from your local workstation to a Fabric workspace by using either the fabric-cicd Python SDK or the fab deploy command. This is the fastest way to see the deployment process in action. To learn more, refer to the Deploy locally with the fabric-cicd library or the Fabric CLI tutorial. Build a CI/CD pipeline with Azure DevOps and the fabric-cicd library Promote changed items from dev to test to prod with approval gates, automatic replacement of environment-specific GUIDs through parameter files, and secure credentials in Azure Key Vault and a service principal. To learn more, refer to the Build a CI/CD pipeline with Azure DevOps and the fabric-cicd library tutorial. Deploy from Git with the Bulk Import and Export API A build-environment pattern in which an Azure DevOps pipeline reads Fabric item definitions from a Git folder and deploys them to a target workspace that is not connected to Git. The Bulk Import API creates new items and updates existing ones in place, relying on Fabric's built-in dependency handling to deploy items in the correct order. This approach is a strong fit when you want to treat item definitions as code and promote them through a structured release flow. To learn more, refer to the Deploy from Git with the Bulk Import and Export API tutorial. Go deeper: Dependency binding across workspaces When you promote a solution, the references between items can break. The new Understand dependency binding in cross-workspace deployment article explains why: some items reference their dependencies with portable logical IDs that bind automatically to the matching item in the target workspace, while others use workspace-specific object IDs that break unless you parameterize them. It maps which item types bind automatically and which need manual handling. For now, this guidance covers deployment through Git integration and the Bulk Import API. Bring your own Git provider: open-source generic Git sample Some teams promote content through a Git provider that Fabric integration does not natively support or run their environments in different Microsoft Entra tenants. The open-source fabric-cicd-generic-git sample addresses exactly these cases. It uses the Bulk Export and Import APIs, with portable Bash scripts that work the same across providers such as GitLab, Bitbucket, GitHub Enterprise Server, and Azure DevOps Server, and includes first-class support for service principals and multi-tenant deployments. If your setup falls outside native Git integration, start with this sample. Next steps Start with the Introduction to CI/CD in Microsoft Fabric to build a mental model. Use the concepts and best practices guide to plan your approach, then choose the tutorial that best matches your environment and build your first CI/CD process. Share your feedback through the Fabric Community.Five Business Event scenarios and the pattern they share
Welcome to the sixth post in our Business Events, Fabric Events, and Azure Events series for Microsoft Fabric. This series takes you from foundational event-driven concepts to practical implementation patterns that help teams turn meaningful business moments into trusted signals, decisions, and actions across Fabric.
On-premises data gateway July 2026 release
The July 2026 release of the on-premises data gateway is version 3000.326. This new version (3000.326) continues our focus on improving gateway manageability, operational visibility, and enterprise governance while maintaining secure and reliable connectivity between on-premises data sources and Microsoft Fabric services. Power BI Desktop compatibility This update brings the on-premises data gateway up to date with the July 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 July version of Power BI Desktop. Thank you! Upgrade to version 3000.326 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.Fabric August 2026 Feature Summary
Welcome to the August 2026 Fabric update! Microsoft Fabric continues to evolve with new capabilities that help organizations build, manage, and scale their data and AI solutions more efficiently. This month's updates introduce enhancements across Fabric Platform, OneLake, Data Engineering, Conversational Analytics, Data Warehouse, Real-Time Intelligence, and Data Factory. Whether you're strengthening governance, improving performance, streamlining development workflows, or expanding AI-powered experiences, these updates are designed to help you get more value from your data while simplifying day-to-day operations. Explore the following highlights to see what's new in Microsoft Fabric this month. Events and Announcements Join us for FABCON and SQLCON in Barcelona, September 28 – October 1, 2026 Explore what’s possible with Microsoft Fabric and get up to speed on the latest in SQL, analytics, and AI. From 130 sessions and 4 keynotes to workshops, the expo, community spaces, and the Power BI DataViz World Championships, this is where the data community comes together. Learn directly from Microsoft and community experts shaping the future of Fabric and SQL. Register now and save €200 with code FABCMTY200. Fabric Platform KQL-Dashboard Embed in Fabric (Preview) A new capability that lets you add interactive KQL-Dashboard content directly into your own browser-based web applications is available. Now, you can bring Fabric analytics into the apps, portals, and workflows your users already use. Analytics are most useful when they are available where decisions happen. With Fabric Embed, you can place Fabric content inside a custom application or internal portal instead of requiring users to switch to the Fabric portal. Fabric Embed can help you: Bring interactive analytics into an existing business workflow. Explore Fabric analytics without switching between your application and the Fabric portal. Keep Fabric workspace permissions and Microsoft Entra ID identities at the center of access control. Build user-based embedded experiences for people who already have access to the underlying Fabric item. The embedded experience complements the Fabric portal. Content owners can continue to create and manage analytics in Fabric while application developers present that content in the context most useful to their users. To learn more, refer to the Microsoft Fabric Embed documentation. Git Integration – Workspace Relation API (Preview) Following our recent announcement of branch workspaces and the relationship that’s automatically created when a user performs a branch-out operation, we’re introducing the new Workspace Relations API. These endpoints let you create, query, update, and delete relationships between Fabric workspaces programmatically — and for anyone building automation around Git integration, branched workspaces, and CI/CD, it’s a big deal! The workflow is straightforward. A developer creates a feature branch. An ADO pipeline or GitHub Action then provisions a new feature workspace, configures Git, applies the right settings and permissions, and synchronizes the workspace. Finally, the Workspace Relations API links that feature workspace back to its parent — closing the loop and giving your automation a first-class, queryable connection between parent and branched workspaces. Figure: Branch workspace relation. To learn more, refer to Development process using Branch-Out experience. Git Integration and Deployment Pipeline – Item level permission restriction Starting December 1, 2026, users without read-write permissions on workspace items can't use Git integration and won’t be able to deploy a workspace or assign workspace to a stage via Deployment Pipeline. This restriction can result in loss of access to certain items because of sensitivity labels and protection policies applied to those items. To learn more, refer to Information Protection in Microsoft Fabric. OneLake Resource instance rules for OneLake (Generally Available) Resource instance rules for OneLake are ready for production workloads across enterprise analytics environments. They give workspace admins a precise way to allow access from trusted Azure resource instances while continuing to enforce network and data-level protections. Use resource instance rules when you need to enable secure service-to-service access to OneLake without relying solely on IP allowlists or requiring private networking for every integration. Combined with Private Link, IP firewall rules, and identity-based permissions, they help organizations apply layered security based on the needs of each workspace and workload. Resource instance rules support a broad set of Azure services that can present a verifiable Azure resource identity, including Azure Databricks, Azure SQL Server, Azure Data Factory, Azure Event Grid, Azure Machine Learning, and more. Configuration requires only the Azure resource ID, simplifying setup while maintaining control over which Azure resources can access OneLake. To learn more, refer to Manage inbound access to OneLake with Resource Instance Rules. Data Engineering Native Execution Engine performance improvements This month, we continued to improve the Native Execution Engine (NEE) with a new set of query execution optimizations designed to accelerate Spark workloads while reducing compute consumption. Key enhancements include broadcast joining reuse across queries, native acceleration for ranking window functions such as RANK and DENSE_RANK, and automatic materialization of reused Common Table Expressions (CTEs). Together, these optimizations eliminate redundant computation, keep more processing within the engine's vectorized execution path, and improve performance for common data engineering patterns including large joins, analytical reporting, ranking workloads, and complex transformation pipelines. Because these improvements are enabled automatically when NEE is available, customers benefit from faster execution times, lower Fabric capacity consumption, and improved price-performance without requiring code changes to existing notebooks, Spark Job Definitions, or pipelines. These optimizations are enabled by default once the Native Execution Engine is turned on, allowing customers to realize performance gains immediately without additional configuration or tuning. Customers can enable NEE at the workspace environment level by navigating to Environment > Acceleration and turning on Native Execution Engine, ensuring it is available for all Spark sessions using that environment. It can also be enabled at the session level by setting spark.native.enabled=true in Spark configuration. With NEE enabled, customers can seamlessly take advantage of the latest runtime innovations to process data faster, improve resource efficiency, and maximize the value of their Fabric capacity investments. To learn more about Native Execution Engine explore our documentation Native execution engine for Fabric Data Engineering. Fabric Runtime 2.0 (Generally Available) As the execution foundation for Microsoft Fabric's Data Engineering and Data Science experiences, Runtime 2.0 delivers a modern, high-performance platform built on Apache Spark and deeply integrated across the Fabric ecosystem. Purpose-built for large-scale data processing and analytics workloads, Runtime 2.0 represents a major advancement in performance, reliability, security, and future readiness. Built on the latest open-source innovations, it enables customers to accelerate data processing, simplify operations, and take advantage of the newest capabilities across Microsoft Fabric. This release includes significant platform upgrades, including Apache Spark 4.1, Delta Lake 4.2, Python 3.13, Java 21, Scala 2.13, and Azure Linux 3.0, providing a modern and enterprise-ready foundation for the next generation of data engineering, data science, and analytics workloads. These enhancements enable customers to take advantage of the latest open-source innovations while continuing to benefit from a fully managed, enterprise-grade experience in Microsoft Fabric. Whether you're building data pipelines, developing AI and machine learning solutions, processing streaming workloads, or powering enterprise analytics, Runtime 2.0 provides a more capable, scalable, and performant platform for your workloads. With improved performance, updated open-source foundations, and continued investment in capabilities such as the Native Execution Engine, Runtime 2.0 provides a modern platform for data engineering, data science, and analytics workloads in Microsoft Fabric. Explore the full documentation and start using Runtime 2.0 in production Runtime 2.0 in Fabric. Enhanced Spark Properties Support in Notebook and Spark Job Definition Notebook and Spark Job Definition (SJD) activities now enable users to specify Spark properties directly within the data integration pipeline. This enhancement allows Spark properties to be set inside the activity panel, ensuring that the values provided are used for activity execution. If an Environment item is linked to the Notebook or SJD and both the activity panel and Environment item define the same property, the value specified in the activity panel will take precedence and overwrite the Environment value. In the case of Notebooks, if the %%configure command is used within the notebook code to set a Spark property, the value set using %%configure will be applied for execution. This update offers users maximum flexibility, allowing Spark properties to be defined at different layers based on their specific use cases. By supporting property configuration in the activity panel, Environment item, and notebook code, users can tailor property values to meet the unique requirements of each execution of Notebook/SJD. To learn more on Transform data by running notebook and Transform data by running a Spark Job Definition activity. Conversational Analytics Enhanced Data Agent Visualizations with Fabric Visuals The data agent now uses Fabric visuals to render the charts it returns, bringing higher-quality, more consistent visualizations into your conversations with your data. When you ask a question like "Generate a bar chart of revenue by region" or "Show me my top 10 customers by sales," the data agent responds with an interactive, polished visual alongside its text and table answers, so you can spot trends, comparisons, and outliers. Because the data agent now shares the same visual foundation as Fabric Apps, charts look and behave consistently with AI-generated visuals in Fabric, with refinements to formatting, legends, tooltips, and axis scaling. Supported chart types include line, bar, stacked bar, pie, scatter, and area charts. To learn more, refer to the Get visual responses from a Fabric data agent documentation. Advanced DAX Generation for Semantic Models in Data Agents Advanced DAX generation for Power BI semantic models is now available in Fabric data agents when you use the Preview runtime. Instead of generating a DAX query in a single pass, the new system works iteratively as a specialized sub-agent that can use tools, inspect results, and refine its approach across multiple steps, providing significant improvements in response accuracy. It also uses instance value indexing to resolve values from the semantic model before generating a query, resulting in more accurate and reliable filters. This update is built on the same semantic-model query engine used across Fabric Skills, Power BI, and M365 Copilot, providing more consistent answers across Microsoft experiences. To use the new experience, open the Runtime dropdown in the data agent ribbon and switch from Standard to Preview. More improvements for semantic models in data agents are coming soon, including data source description and instructions, granular schema selection, and example queries. In the Preview runtime, the data agent uses advanced DAX generation to answer a question over a connected semantic model, enabling more accurate DAX generation and responses. To learn more, refer to the Semantic model best practices for data agent documentation. Data Agent orchestrator upgraded to GPT 5.1 The data agent orchestrator now runs on GPT-5.1, across both the standard and preview runtimes. The orchestrator handles how questions are rephrased, how work is planned across your data sources, and how the final answer is composed — so this upgrade changes behavior in all three. Most of what you see should be an improvement in answer quality and planning, but the change is not behavior-neutral: prompts tuned against the previous model may produce different results. We recommend re-running your evaluations, reviewing the results against your saved baselines, and updating your agent instructions and prompts where the new behavior doesn't match what your scripts expect. To learn more, refer to the data agent runtimes documentation. Example Query Usability Improvements in Data Agent We've made several usability improvements, for example queries. Errors now surface inline, directly alongside the query, so you can identify and correct issues without leaving the editor. The editor also resizes automatically based on the length of your query, removing the need to adjust the pane manually as you write. To learn more, refer to the example queries in data agent documentation. Add Schema Descriptions for SQL Sources in Data Agent Users can now provide tailored schema descriptions through the new schema description editor, available for SQL sources on the Preview runtime. Schema descriptions improve query generation and accuracy by giving the agent more context about what everything in your data means — use them to resolve ambiguous columns, or to give a table or field a more precise meaning than its name conveys. Instead of inferring intent from column names alone, the agent works from what your data team documented, so it selects the right tables and interprets fields the way you intended. To learn more, refer to the schema descriptions documentation. Data Agent is migrating from Assistants API to Responses API The OpenAI Assistants API that powers the orchestration layer for the Microsoft Fabric data agent, is currently scheduled to be shut down by OpenAI on August 26, 2026. After that date, direct calls to the Assistants API will stop working. If you connect to a Fabric data agent programmatically through the Assistants API, you need to migrate to the data agent Model Context Protocol (MCP) endpoint. SDK and Fabric portal users require little or no action because Microsoft will migrate those experiences internally, although conversation history may reset once. Existing agent data sources, instructions, and tools remain unchanged. To learn more, refer to Prepare your Fabric Data Agent integrations for Assistants API retirement. Fabric Data Agents in Microsoft Copilot Studio (Generally Available) Now, you can bring governed business data from Microsoft Fabric into Copilot Studio agents, so those agents can answer questions and support business processes using trusted enterprise data. Since preview, the integration has moved to the new tool-based experience: select Add a tool, search for Fabric, and add Fabric IQ Data MCP, and your agent can call the Fabric data agent like any other tool. The Fabric data agent still runs in Fabric and respects permissions on the underlying data sources. You can also publish your agent to Microsoft Teams and Microsoft 365 Copilot, so business users get data-grounded answers where they already work. To learn more, refer to the Fabric Data Agent MCS GitHub documentation for setup steps and join the community discussion to share feedback. Fabric data agents in Microsoft Foundry: Easier to connect, easier to trust Fabric data agents in Microsoft Foundry are now easier to connect and easier to monitor. The integration moves to Model Context Protocol, so your Fabric data agents appear as tools that Foundry agents can invoke when they need enterprise data in OneLake. Connecting them no longer means hunting for workspace and artifact IDs. You add the Fabric IQ (OneLake Catalog) tool, filter for data agents, and pick the ones you want by name. You can also connect more than one Fabric data agent to a single Foundry agent, so an agent can draw on a sales agent, a supply chain agent, and a customer support agent and choose the right one for the question. On the operations side, you can now view logs and traces for Fabric data agents through Foundry Observability. Traces show which tools were invoked, how long each step took, and what came back, which makes it much easier to troubleshoot an answer that looks wrong or a workflow that runs slow. This is the visibility teams need to move agents from experiments to production. The update is rolling out to all regions over the coming days. Add Fabric data agent as part of Fabric IQ to your Foundry agent. To learn more, refer to the Observability for Fabric data agents in Microsoft Foundry documentation. Add co-publishers for data agents in Microsoft 365 Copilot When you publish a Fabric data agent to Microsoft 365 Copilot, the Microsoft 365 agent platform registers the agent and records you as its only owner. That created a problem for teams. Your co-creators could still edit the data agent in Fabric, but when they tried to republish it, the operation failed, because Microsoft 365 only lets registered owners publish. Fabric access and Microsoft 365 ownership are two separate lists, so giving someone edit rights in Fabric was never enough. Now, you can avoid this with co-publishers. After you publish the data agent, open Settings, go to the Publishing pane, and add your Fabric co-creators under Microsoft 365 Copilot co-publishers. Each person you add is registered as a co-owner on the Microsoft 365 agent platform, so anyone on that list can republish the agent. Add co-publishers right after your first publish so no one hits a failure in the meantime. Publishing pane in the Fabric data agent settings, showing where you add Microsoft 365 co-publishers. To learn more, refer to the Consume a data agent from Microsoft 365 Copilot (preview) documentation. Data Warehouse Identity columns with identity insert (Generally Available) Since preview, thousands of customers have adopted IDENTITY to auto-generate surrogate keys and streamline migrations from SQL Server, Azure SQL Database, and Azure Synapse. Now we're introducing support for IDENTITY_INSERT and reseed operations - two highly needed additions - so you can insert explicit key values, migrate data in bulk with COPY INTO, and safely realign identity ranges with DBCC CHECKIDENT. Figure: Using identity insert on Fabric Data Warehouse. IDENTITY columns are available now in every Fabric Data Warehouse. To learn more, check our updated tutorial and documentation. CI/CD 2.0 with DacFx (Preview) Microsoft Fabric Data Warehouse is introducing a major update to the DacFx engine that powers schema comparison, Git integration, and deployment pipelines. DacFx builds a declarative model of your warehouse and determines the schema changes required to move safely between development, test, and production environments. Git-integrated CI/CD workflow for Microsoft Fabric, showing feature workspace synchronization, branch merging, and deployment pipeline promotion across development, test, and production workspaces. With this update, Git integration uses DacFx-based incremental extraction to produce cleaner, more focused commits. Deployment pipelines also use the updated model to generate more accurate comparisons and smarter deployment plans, with settings tuned for schema evolution. The new warehouse item definition version 2.0 updates the SQL project SDK, moves shared queries into a .sharedqueries folder, adds project-level Git configuration, and re-extracts object definitions to support constraints, identity columns, clustering, and consistent formatting. These changes make future commits easier to review and reduce noisy diffs. For more information, refer to the Upgrade Fabric Data Warehouse System File Version in a Git Integrated Fabric workspace documentation. Microsoft Fabric source control notification prompting users to apply the latest Warehouse system update, with a warning that the update will introduce differences between the workspace and its connected Git repository. The update also improves comparison accuracy. Git-connected workspaces can adopt the update when ready through the System update available experience, giving teams control over upgrade timing. Review and commit the generated changes before continuing normal development and deployment workflows. To learn more, refer to the Development and Deployment Overview documentation. Simplify Fabric Warehouse deployments with Schema Compare in VS Code Database deployments should not feel like a guessing game. With Schema Compare in Visual Studio Code, developers can see exactly what changed before those changes reach a Fabric Warehouse—bringing clarity and control to every release. Compare a Fabric Warehouse with another warehouse or a SQL database project, then review differences across tables, views, stored procedures, functions, and other database objects in a clear, object-by-object view. Choose the changes you want, update the project from the warehouse, or deploy selected changes to the target—without manually assembling and reviewing every deployment script. By keeping database projects synchronized in Git, teams gain a reliable source of truth and can bring schema changes into familiar pull-request and CI/CD workflows. The result is a safer, more intentional path from development to production, with fewer surprises at deployment time. Before applying changes, review the generated script for unsupported operations and potential data loss. To learn more, refer to the Develop warehouse projects in Visual Studio Code and Schema Compare in the MSSQL extension documentation. GPU Query Acceleration (Preview) Query Acceleration brings GPU-powered performance directly to Fabric Data Warehouse, enabling eligible analytical queries to run faster without query rewrites, special syntax, or additional systems to manage. Query Acceleration in Fabric Data Warehouse uses GPUs to accelerate the most compute-intensive portions of analytical queries, helping overcome the limits of CPU-only execution. It works transparently with existing T-SQL, Direct Query reports, applications, and tools, automatically offloading eligible operations such as scans, filters, joins, and aggregations to GPUs while the CPU continues to manage the rest of the execution pipeline. Customers can use Query Insights, Data Warehouse Monitoring, and SQL Server Management Studio (SSMS) for query execution plans to identify accelerated queries and understand how Query Acceleration is applied during query execution. Designed for analytical and high-concurrency workloads, Query Acceleration can improve throughput, reduce query latency, and deliver more consistent performance for dashboards and interactive analytics. Acceleration is applied selectively, enabling performance gains even when only part of a query is eligible for GPU execution. The capability is built with reliability in mind. Unsupported operations or runtime constraints can seamlessly fall back to CPU execution without affecting query correctness. Performance improvements depend on workload characteristics, but Microsoft benchmarks have demonstrated gains of up to 7× across reporting, application, and AI-driven analytics scenarios. Query Acceleration builds on Microsoft's Tensor Query Processor research, described in CoddSpeed: Hardware Accelerated Query Processing in Microsoft Fabric, which was selected as the SIGMOD Companion 2026 Best Industry Paper. To sign up for the Preview, please fill out the form. Metadata Sync supports Delta Checkpoint V2 (Generally Available) Metadata Sync (MD Sync) now supports Delta Checkpoint V2, enabling synchronization of modern Delta tables across both MD Sync (Legacy) and MD Sync (New). Delta Checkpoint V2 is a Delta Lake enhancement designed to improve scalability for large tables through a more efficient checkpoint structure. Previously, tables using Checkpoint V2 couldn't be synchronized and were reported as unsupported. With this release, MD Sync can discover and synchronize Delta tables that use the Checkpoint V2 format. This enhancement helps customers: Synchronize Delta tables that use Checkpoint V2. Improve interoperability with Spark, Databricks, and other Delta-based platforms. Support metadata synchronization for large-scale Delta tables more efficiently. Continue using existing checkpoint formats without any changes. MD Sync support for Delta Checkpoint V2 is available in both MD Sync (Legacy) and MD Sync (New), helping ensure consistent access to Delta tables across Fabric experiences. Secure data ingestion with COPY INTO and Workspace Identity (Generally Available) COPY INTO in Fabric Data Warehouse now supports Workspace Identity, enabling users to load approved data from OneLake or ADLS Gen2 without requiring direct access to the source files. Previously, ingestion users often needed permissions to both the target warehouse and the source storage location, or teams relied on SAS tokens, account keys, or service principals. With this release, source access can be centrally assigned to the workspace identity, while users retain only the SQL permissions required to load data into the target table. Key Capabilities: Load approved data without granting users direct access to raw storage. Use managed identity-based authentication for OneLake and ADLS Gen2 sources. Reduce reliance on SAS tokens, shared keys, and service principal secrets. Maintain separate authorization boundaries for source access and target-table permissions. Support least-privilege ingestion and separation of duties between storage and warehouse administrators. Workspace Identity support for COPY INTO is generally available in Fabric Data Warehouse, providing a simpler and more governed approach to secure data ingestion. To learn more, refer to the Ingest Data into Your Warehouse Using the COPY Statement and COPY INTO (Transact-SQL) documentation. SQL Audit Logs: More Signal, Less Noise with Predicate Filtering (Generally Available) SQL Audit Logs in Fabric Data Warehouse and SQL Analytics Endpoint now support identity-based predicate exclusion filtering, enabling administrators to reduce repetitive audit events generated by selected users and service principals. Previously, expected activity from automation identities, scheduled processes, metadata synchronization jobs, and other operational actors could create significant audit noise. With this release, administrators can configure exclusions through the API or SQL Audit Logs user experience, while activity from identities that do not match the exclusion predicate continues to be audited normally. Key Capabilities: Reduce repetitive audit events from known users and service principals. Focus investigations on higher-value and unexpected activity. Lower the storage, processing, export, and query burden associated with low-value events. Manage identity exclusions through either automated APIs or the user experience. Apply a governed audit policy aligned with organizational monitoring and compliance requirements. Identity-based predicate exclusion filtering is generally available for SQL Audit Logs in Fabric Data Warehouse and SQL Analytics Endpoint, providing a cleaner audit stream, less operational overhead, and more focused investigations. To learn more, refer to the SQL Audit Logs in Fabric Data Warehouse documentation. OneLake security improvements for SQL analytics endpoints (Generally Available) OneLake Security for SQL analytics endpoints now includes improvements for nested groups, shortcut-backed tables, column-level security, and service principals, enabling more consistent enforcement of OneLake security policies across enterprise Fabric environments. Previously, limitations with group expansion, shortcut scenarios, and service principal ownership could make centralized security difficult to apply at scale. With these improvements, customers can define security at the source lakehouse and rely on the SQL analytics endpoint to honor those policies across producer and consumer workspaces. Key Capabilities: Manage access through nested Microsoft Entra group hierarchies. Honor source-side OneLake Security policies for shortcut-backed tables in hub-and-spoke architectures. Apply column-level security consistently when users receive access through groups. Use service principals for automated deployments, pipelines, and application-owned data products, including service principal-owned lakehouses. Define security once in OneLake and reduce the need to duplicate permissions across consumer workspaces and Fabric engines. These OneLake Security improvements help make security synchronization more practical for enterprise architectures while providing consistent access control across lakehouses and SQL analytics endpoints. Microsoft is also continuing to improve security sync notifications, error handling, and permission propagation across Fabric experiences. To learn more, refer to the OneLake Security for SQL analytics endpoints documentation. Real-Time Intelligence Set Alerts Directly from Anomaly Detector (Generally Available) Detecting anomalies becomes more valuable if you can act on them. Previously, after publishing an anomaly detector configuration, you had to leave Anomaly Detector and navigate to Real-Time Hub to create an alert. This added extra steps and interrupted your workflow right after completing your configuration. With this update, you can now create alerts directly from Anomaly Detector. Once you publish a configuration, use the Set alert button in the ribbon to launch the alert creation pane without leaving Anomaly detector. If your configuration hasn't been published yet, you'll be guided through publishing first and then taken directly to the alert setup experience. This helps you move seamlessly from configuring anomaly detection to monitoring it in production. The integrated experience allows you to monitor your anomalies on each event, helping you get notified as soon as anomalies are detected. If you have more complex business logic, select on each event when to add in additional logic to your conditions. Whether you're monitoring operational metrics, business KPIs, or real-time telemetry, you can now complete the entire workflow in one place and start acting on detected anomalies faster with fewer clicks. Create alerts directly from your anomaly detector configuration and continue your workflow without navigating to another experience. Configure notifications for anomaly detector events directly within Anomaly Detector and start monitoring your published configuration immediately. Anomaly detector supports Eventhouse shortcut tables Anomaly Detector now supports Eventhouse shortcut tables, making it possible to analyze data without first copying or moving it into a dedicated Eventhouse table. You can create anomaly detectors directly on supported shortcut tables and use the same analysis, model recommendations, and continuous monitoring experiences available for native Eventhouse data sources. This expands anomaly detection to a broader range of data already connected through Eventhouse shortcuts, helping teams monitor external and federated data sources with less setup and duplication. By enabling anomaly detection directly on shortcut tables, you can move more quickly from connecting data to detecting issues, while continuing to work within a unified Real-Time Intelligence experience. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Operations Agent Activity Log Understanding what your agent is doing and why is key to building trust and improving outcomes. The activity log is designed to provide that transparency. It gives you a clear view into the agent’s behavior, including the conditions it evaluated, the recommendations it generated, and how those recommendations were handled. Whether you are validating results, troubleshooting unexpected behavior, or refining your configuration, the activity log helps you better understand how decisions are being made. You can access the activity log from the Activity log section in the side navigation. It presents a chronological timeline of events with timestamps and relevant context for each entry. Selecting any event allows you to explore additional details and understand what happened at each step. In the Operation details page, you can view the operation details and status. To learn more, refer to the Create and Configure Operations Agents documentation. Eventstream MQTT connector (Generally Available) It is now easier than ever to ingest real-time data from MQTT brokers directly into Microsoft Fabric Real-Time Intelligence. MQTT is one of the most widely adopted messaging protocols for lightweight, low-bandwidth event driven messaging scenarios. Eventstream MQTT connector simplifies the ingestion of operational and IoT data into Microsoft Fabric, helping organizations turn real-time device events into actionable insights. Key Benefits: Connect to any MQTT broker and ingest messages directly into Fabric Eventstream. Production-ready reliability and support with General Availability readiness. Enterprise-grade security with support for TLS, mutual TLS (mTLS), and custom certificate authorities managed through Azure Key Vault. Private network connectivity through Eventstream's streaming connector virtual network capabilities, enabling secure access to brokers hosted in private and on-premises environments. To learn more, refer to the Add MQTT source to an eventstream documentation. Reference data enrichment in Eventstream (Preview) Eventstream now enables you to enrich real-time event streams with contextual business data using Reference Data Join. Simply add a Reference Data node to your Eventstream, select a Delta table from a Fabric Lakehouse, and use it to enrich streaming events with lookup, metadata, or reference information. You can also leverage Lakehouse shortcuts to access Delta tables across OneLake, making it easy to bring contextual data from anywhere in your Fabric environment into your real-time processing pipelines. Reference Data Join supports both no-code and SQL-based enrichment experiences. Use the built-in Join operator to visually configure INNER and LEFT OUTER joins or use the SQL operator for advanced scenarios. Select only the columns you need from the reference dataset and configure optional refresh intervals to keep slowly changing reference data up to date. This enables Eventstream to continuously use the latest lookup information for real-time enrichment, without requiring additional data movement or downstream processing pipelines. You can easily add multiple reference data sources to a single Eventstream and combine them with streaming data to create richer, more contextual event pipelines. Developers and data engineers can test and validate join conditions, preview join results, and verify SQL-based enrichment queries before deploying them into production, helping ensure accuracy and confidence in real-time data processing workflows. Reference Data Join unlocks powerful real-time enrichment scenarios in Eventstream. Users can enrich IoT telemetry with device metadata, correlate operational events with customer and product information, perform lookups against business reference datasets, and add contextual information to streaming data in flight. By bringing reference data and event processing together in a single experience, Eventstream enables customers to transform raw events into actionable business insights in real time. To learn more, refer to the Reference data join in Eventstream using Lakehouse documentation. Eventstream observability in Workspace Monitoring re-enabled with per-Eventstream control (Preview) Eventstream observability in Workspace Monitoring is back — now with granular control over which Eventstreams emit monitoring data. A new ‘Log Eventstream activity’ toggle in Eventstream Settings lets you enable or disable observability per Eventstream, so you can balance monitoring coverage with capacity consumption. When enabled, your Eventstream emits performance metrics, error counts, and health status to three tables in your Workspace Monitoring Eventhouse: EventStreamMetrics: throughput, backlog, and watermark delay EventStreamErrorMetrics: deserialization, conversion, and runtime error counts EventStreamNodeStatus: node health (Running / Failed) The toggle defaults to OFF for all Eventstreams. To get started, open any Eventstream, go to Settings, and turn on Log Eventstream activity. Your monitoring data will appear in the Workspace Monitoring database within minutes. Eventstream activity" within Monitoring. The panel highlights an active toggle switch, a description explaining that enabling this feature emits performance and error metrics to a monitoring database. To learn more, refer to the Monitor Eventstream data flows in Workspace Monitoring documentation. Eventstream UI editor improvements (Preview) We've redesigned key parts of the Eventstream editor to make building and troubleshooting faster and more intuitive. Always Publish: No more blocked publish buttons. Publish your work at any stage, the editor gives you clear, contextual guidance on what still needs attention instead of preventing you from moving forward. Inline error indicators: Errors now appear directly on the node that needs fixing, with actionable guidance on click. No more hunting through a detached error list to find what's broken. Operator and destination descriptions: Each option now includes an inline description explaining what it does, so you can build confidently without switching to docs. These changes reduce friction during authoring and make it easier to go from idea to running your pipelines. Secure Azure Event Hubs Connections in Eventstream with Workspace Identity (Preview) Bringing real time event data into Microsoft Fabric is now simpler and more secure with Azure Event Hubs integration for Eventstream. Organizations can connect Event Hubs directly to Eventstream and start routing event data to destinations such as Eventhouse for analytics and operational insights. A key capability is Workspace Identity, which removes the need to manage shared access keys. Instead, Eventstream can authenticate to Azure Event Hubs using the Fabric workspace identity. Administrators simply grant the workspace the Azure Event Hubs Data Receiver role, enabling secure access through Microsoft Entra based permissions. This approach improves security, simplifies credential management, and aligns with enterprise governance requirements. The integration supports both public and private network deployments. For Event Hubs hosted in private networks, organizations can connect through a streaming virtual network gateway while continuing to use Workspace Identity for authentication. For advanced event processing scenarios, users can enable schema support, associate schemas from the event schema registry, and route structured events to destinations such as Eventhouse. Combined with Workspace Identity, this provides a secure and scalable foundation for building real time data pipelines without the operational overhead of managing secrets or credentials. Schema Registry and Event SchemaSet Region Availability Previously, Schema Registry feature and the Event SchemaSet artifact was available for preview in 31 regions. Expanded to 10 additional regions: Geography Region Americas Central US Americas Mexico Central Americas West US 3 Europe Italy North Europe Poland Central Europe Spain Central Europe West Europe Asia Pacific Australia Southeast Asia Pacific Israel Central Asia Pacific Japan West If you were previously blocked from trying SchemaSets and schema-based Eventstream data ingestion, you can now do so in these regions. For more information on Event SchemaSets and how you can create and manage them, visit Schema Registry Overview. To learn more about configuring Eventstreams with schema-based sources, visit Use schemas in Eventstreams. Data-driven styling and UX improvements for Maps (Generally Available) Maps become most valuable when they help users understand not just where things are, but what the data means. Now, Data-Driven Styling, along with Markers Rotate by Data, Traffic Flow visualization, additional Map View options, and an improved Layer Settings experience. Together, these enhancements help organizations transform raw geospatial data into intuitive, actionable business insights. Let Your Data Tell the Story Understanding patterns hidden within geographic data can be challenging when every feature on a map looks the same. With Data-Driven Styling, Fabric Maps enables map builders to visually represent business data directly on the map, helping viewers quickly identify trends, hotspots, and outliers without inspecting individual records. The new Color by Value Range capability allows authors to style map layers using numeric measures such as revenue, utilization, sensor readings, environmental measurements, or operational KPIs. Instead of applying a single color to an entire layer, Fabric Maps visualizes value distributions chromatically, making important differences immediately visible. Organizations can choose between two visualization approaches: Gradient Styling uses continuous color transitions to reveal magnitude, trends, and geographic variation across a dataset. Step-Based Styling allows users to define custom value ranges with distinct colors, making it easy to visualize business thresholds, risk levels, performance bands, or service categories. To make these visualizations easier to interpret, Fabric Maps automatically generates corresponding data legends that explain how colors map to underlying values. This helps viewers understand the meaning behind the visualization and make decisions with greater confidence. Fabric Maps also includes thoughtfully designed color palettes, including options that support colorblind-friendly visualization scenarios, helping more users accurately interpret map-based insights. Combined with clear, automatically generated legends, these capabilities improve accessibility and make data-driven maps easier to understand across a wider range of audiences. per street and road and high-value exposure in flood-prone areas. Visualize Direction and Movement with Markers Rotate by Data Many operational scenarios involve not only location but also direction. Fabric Maps now supports Markers Rotate by Data, allowing marker symbols to automatically rotate based on values stored in a data column. This capability is available for Marker layers, enabling builders to visualize directional information directly on the map. Whether visualizing aircraft headings, vehicle movements, equipment orientation, or other operational workflows, map authors can represent direction without requiring custom visualization development. By transforming static points into directional indicators, organizations can add valuable operational context and communicate movement patterns more effectively. Add Real-World Context with Traffic Flow Visualization Location data alone doesn't always tell the full story. Fabric Maps now supports Traffic Flow overlays, allowing map builders to bring current traffic conditions into their existing map experiences. By combining business data with real-world traffic information, organizations can gain additional situational awareness for logistics operations, field service planning, transportation monitoring, and operational decision-making. The added context helps users better understand the environment surrounding their assets and activities without leaving the map experience. Configure the Right Map View for Your Audience Organizations often create maps for users across different regions and business contexts. Fabric Maps introduces additional Map View settings that allow map builders to configure how geographic information is presented, helping ensure maps are displayed in a way that aligns with organizational needs and audience expectations. This flexibility gives authors greater control over creating a consistent and intuitive viewing experience across a variety of business scenarios. A More Discoverable Authoring Experience UX research and user feedback showed that some key layer settings were difficult to discover. We updated the experience by moving geometry and visualization options—including visual type, Data-Driven Styling, and marker rotation—higher in the configuration pane. We also renamed General to Visibility, making the settings clearer and map authoring more intuitive. Turn Location Data into Business Insight Data-Driven Styling, built-in data legends, Markers Rotate by Data, Traffic Flow overlays, enhanced Map View options, and the improved Layer Settings experience help organizations transform location data into meaningful business insight. Together, these capabilities make it easier to uncover patterns, understand operational context, and communicate geospatial insights across teams. Start building with these capabilities today: explore the customization options, apply them to your own geospatial data, and create map experiences that turn location into action. To learn more, refer to the Customize a map in Microsoft Fabric documentation. Workspace Outbound Access Protection (OAP) for Operations Agent (Preview) Workspace Outbound Access Protection (OAP) in Microsoft Fabric helps admins secure outbound connections from workspace items to external resources. Admins can control outbound access by blocking unwanted connections by default and allowing only approved connections through configured rules. As organizations adopt AI-powered operations at scale, governance and security remain critical requirements. With this preview release, Microsoft Fabric introduces Outbound Access Protection (OAP) for Operations Agent, enabling workspace administrators to control the outbound actions an agent can perform. OAP applies workspace-level policies to actions such as Teams notifications, workflow triggers, and cross-workspace operations, helping organizations enforce security and compliance requirements while continuing to benefit from AI-driven automation. When OAP is enabled, Operations Agent continues to perform core functions including reasoning, recommendation generation, rule evaluation, and telemetry collection. However, outbound actions are governed by the workspace's configured access policies. Administrators gain greater visibility through in-product notifications, Teams messaging experiences, and the Operations Agent Activity Log, making it easier to identify and troubleshoot blocked actions What's new with Operations Agent and OAP? Govern outbound agent actions through workspace-level OAP policies. Control whether Operations Agent can send Teams notifications based on allowed connections. Prevent unauthorized cross-workspace actions when OAP policies restrict outbound access. Receive clear visibility when actions are blocked through in-product notifications and Teams messaging experiences. Monitor agent activity and OAP-related outcomes through the Operations Agent Activity Log. During the preview, some limitations apply. Cross-workspace actions are blocked when OAP is enabled. For example, Power Automate actions are not yet supported when OAP is applied, and only connectors that explicitly support OAP policies can be permitted. By extending Fabric's outbound governance framework to Operations Agent, organizations can adopt AI-powered operational automation with greater confidence while maintaining control over how and where agent-initiated actions are executed. Resources Workspace outbound access protection for operations agent (preview) Workspace Outbound Access Protection (OAP) Workspace Outbound Access Protection for Operations Agents Configure and manage Activator rules directly in Eventstream (Generally Available) You can now create and manage rules directly in Eventstream. Previously, setting up an alert required switching from Eventstream to Activator. While powerful, this meant moving between experiences to complete a single workflow. Now, alert creation is embedded directly into Eventstream. Capabilities for building or editing your Eventstream: Select the stream you want to monitor. Choose Set Alert. Define your condition (thresholds, aggregations, patterns). Configure the action. Create the rule. Capabilities for Activator destination created on Eventstream: Select Activator node Select Rule icon Create the rule Once you have the rule(s) created on your Eventstream, you can manage them by editing, deleting or opening in Activator. To learn more, refer to the Add a Fabric activator destination to an eventstream documentation. Data Factory Introducing Hierarchical Navigation in Monitoring Hub for Fabric Pipelines Modern data estates rarely consist of a single job running in isolation. Pipelines trigger notebooks, notebooks invoke other workloads, and business processes span multiple interconnected executions. When troubleshooting a failure or understanding lineage, customers often need visibility into how these executions relate to one another. Hierarchical Navigation in Monitoring Hub, is a new capability that helps you understand the relationships between runs and quickly navigate across upstream and downstream executions. With Hierarchical Navigation enabled, Monitoring Hub can display: Upstream runs that initiated a workload Downstream runs triggered by a workload Execution relationships across supported Fabric artifacts This provides a richer observability experience by helping you move beyond individual run monitoring and understand how your workloads operate together. This enhancement is another step toward a richer observability experience in Fabric, helping customers gain deeper insight into workload execution and dependencies at scale. To learn more, refer to the Hierarchical Navigation for Pipelines in Monitoring Hub documentation. Explore the modern Fabric Pipeline canvas (Preview) The new Fabric Pipeline canvas experience is designed to make pipeline authoring easier than ever. Key capabilities with modern canvas: Better visibility when navigating large pipeline graphs Cleaner, more structured layouts for complex orchestration logic Improved responsiveness when working with enterprise-scale workflows A more intuitive experience for pipelines with many activities and branches The modern Fabric Pipeline canvas, showing the updated node experience and option to disable the preview if needed. If you haven't tried it yet, now's the perfect time. The new experience is rolled out automatically and can be disabled at any time. Whether you're building your first pipeline or managing hundreds of activities across complex workflows, the new canvas is designed to help you stay productive and focused on what matters most. To learn more, refer to the Modern Pipeline Node Experience documentation. Upgrade Dataflow Gen1 to Dataflow Gen2 (CI/CD) using the Upgrade Wizard (Preview) The Dataflows Upgrade Wizard is a guided, end-to-end experience that upgrades your existing Power BI Dataflow Gen1 items to Dataflow Gen2 (CI/CD) in Microsoft Fabric with minimal effort. You can upgrade a single dataflow, or several dataflows from a workspace in a single flow. Previously, bringing a Gen1 dataflow into Fabric meant recreating it and repointing everything that depended on it. The Upgrade Wizard upgrades in place instead. Each dataflow keeps its ID, name, schedule, and connections, so the reports and semantic models that connect to it keep working without any changes. Before anything changes, the wizard assesses every dataflow in the workspace and tells you which ones need attention and why, such as incremental refresh settings to reconfigure or a linked entity to update, so you know what to expect before you upgrade. Why this matters Upgrade in place, with nothing to rebuild and nothing to repoint. Upgrade a whole workspace at once instead of one dataflow at a time. See what needs attention before you upgrade. Unlock Dataflow Gen2 innovations: improved performance, deeper Fabric integration, CI/CD and Git support, data destinations of your choice, richer diagnostics, Copilot-assisted authoring, and a modern data transformation foundation. The wizard is available for Dataflow Gen1 items in Premium or Fabric workspaces and requires Fabric to be enabled. To learn more, refer to the Upgrade Dataflow Gen1 to Dataflow Gen2 (CI/CD) using the Upgrade Wizard documentation. Extended watermark support in Copy job Watermark-based incremental load support enables Copy Job to efficiently ingest only new or changed data from key enterprise and SaaS data sources, avoiding costly full reloads. This reduces source-system impact, network traffic, and runtime while improving scalability for production analytics workloads. Customers can now use incremental loading across more of their critical data sources, including Salesforce, Informix, Cassandra, Greenplum, Presto, and Databricks, by leveraging Copy job’s built-in watermark mechanism and without building custom ingestion logic. To learn more, refer to the Incremental copy in Copy job documentation. Enable Change data feed during Lakehouse table creation in Copy job Copy job can now create Lakehouse tables with Change Data Feed (CDF) enabled automatically. There’s no longer a need to pre-create destination tables or manually configure Delta table properties. Simply select Enable CDF on destination and Copy job takes care of the setup for you. This ensures the table is immediately ready for incremental processing and downstream CDC scenarios, helping reduce data movement and improve replication efficiency. By eliminating manual configuration steps, it makes advanced data integration patterns much easier to adopt and operate at scale. To learn more, refer to the Automatic table creation and truncation on destination documentation. Amazon Redshift as new source in Copy job As part of our mission to enable multi-cloud data movement at petabyte scale with Copy job, we are bringing Amazon Redshift support as a source. This enables customers to seamlessly ingest data from one of AWS's most widely adopted data warehouse platforms directly into Fabric. Redshift support further strengthens Fabric's vision of delivering an open, connected, and multi-cloud data platform. To learn more, refer to the Connectors for Copy Job documentation. Copy job supports timestamps without time zone in Lakehouse Support for timestamps without time zones (timestamp_ntz) allows Fabric Lakehouse tables to preserve date and time values exactly as stored, without applying time zone conversions. Copy job can now automatically map timezone-independent datetime values to Delta Lake timestamp_ntz, ensuring greater compatibility with source systems that allow storing date and time values without time zone information. Migration Assistant for SQL database in Fabric (Generally Available) The guided, Fabric-native wizard takes you from a source SQL Server schema to a running SQL database in Fabric: upload a DACPAC, review compatibility results, deploy the schema with Copilot-assisted fix suggestions, and copy your data using built-in Fabric Copy Jobs. We've added the capability preview customers asked for most: Validate. You can now check out a DACPAC for compatibility before creating a SQL database in Fabric. Upload the file and the assistant reports which schema objects will deploy cleanly, which ones use features that aren't supported, the reason behind each failure, and the dependencies between objects — with nothing provisioned and no capacity consumed. That means you can scope migration effort, plan remediation, and get change-approval sign-off before you commit to a target database. To get started, select Migrate in your Fabric workspace and choose Migrate to SQL database in Fabric. To learn more, refer to the Fabric Migration Assistant documentation. Until next month That's a wrap for the August 2026 Microsoft Fabric Monthly Update. As always, we'll continue sharing new capabilities, enhancements, and improvements across Microsoft Fabric in future monthly updates. Thank you for being part of the Fabric community!Reacting to Business Events with Activator and Eventhouse
Welcome to the fifth post in our Business Events, Fabric Events, and Azure Events series for Microsoft Fabric. This series takes you from foundational event-driven concepts to practical implementation patterns that help teams turn meaningful business moments into trusted signals, decisions, and actions across Fabric.
