On-premises data gateway October 2026 release
The October 2026 release of the on-premises data gateway (version 3000.338) continues our commitment to secure, reliable and accessible connectivity between on-premises data sources and Microsoft Fabric services. This release focuses on accessibility, configuration reliability, and troubleshooting. It makes the installer and configurator more inclusive, keeps your Power Query settings intact during connection tests, and makes service-start failures easier to diagnose. It also brings compatibility updates for the October 2026 release of Power BI Desktop, so queries run the same way in Power BI Desktop and in cloud refreshes. General improvements and fixes The October 2026 Gateway release (3000.338) includes Power Query Engine 2.159.229 and introduces the following improvements: Accessibility improvements in the installer and configurator Building on the accessibility work in the September release, this update improves the experience for users who rely on assistive technologies: Keyboard navigation: Moving through the gateway installer and configurator with the keyboard is smoother and more predictable. Screen-reader announcements: Screen readers now give clearer, more accurate announcements of controls, status changes and actions. High-contrast support: Readability and visual consistency are better when Windows high-contrast themes are on. Power Query configuration settings preserved during connection tests Running a connection test no longer affects your Power Query configuration settings. They stay as you set them, so you can validate connectivity without reapplying your configuration afterward. Better diagnostics for gateway service-start failures When the gateway service fails to start, it now provides more detailed diagnostics. Administrators can find the root cause faster and restore connectivity with less downtime. Feature updates and new capabilities in OPDG: Admin APIs for connections and gateways (Preview) Managing connections at scale is a priority for many organizations. Until now, administrators could only see the connections they had been given permission for, which made tenant-wide governance difficult. The new Admin Connections REST APIs give Fabric administrators full visibility and control over every connection in the tenant, including on-premises data gateway, virtual network gateway and cloud connections. These APIs can be called by Fabric administrators or by service principals, so you can automate governance and audit workflows. Admin actions such as viewing or deleting a connection and changing role assignments are recorded in the audit logs for traceability. Learn more in the related documentation. Power BI Desktop compatibility This update brings the on-premises data gateway up to date with the October 2026 release of Power BI Desktop. Download on-premises data gateway (standard mode) Download on-premises data gateway (personal mode) With this version of the gateway, reports you publish to the Power BI Service and refresh through the gateway use the same query execution logic and runtime as the October version of Power BI Desktop. Best practices for upgrading your gateway Some customers have told us they upgraded production gateways straight to a new release and then ran into unexpected issues, such as failed refreshes or connection errors. Most of these can be avoided by upgrading in stages. We strongly recommend validating every new gateway release in a lower environment before you upgrade production. Explore the following best practices: Start with a development or test environment: Install version 3000.338 on a non-production gateway that matches your production setup as closely as possible: the same data sources, connectors, authentication methods and network setup. This lets you catch compatibility issues before they reach business-critical workloads. Validate your key scenarios in the test environment: Confirm that the scenarios your organization depends on still work as expected: Scheduled and on-demand refreshes for your critical semantic models and dataflows DirectQuery and live connection reports Connection tests for each data source type you use Any custom connectors, if you use them Gateway service start-up and sign-in Monitor before you promote: Give the test gateway a representative period, such as a few refresh cycles, before you move on. Review refresh history, gateway logs and performance to spot any regressions early. Back up before upgrading production: Before you upgrade a production gateway, make sure the gateway recovery key is stored securely and you have a record of your gateway configuration. You'll need these if you have to restore or migrate the gateway. Upgrade production clusters one member at a time: If you run gateway clusters, upgrade one member at a time while the other members keep serving requests. Confirm each upgraded member is healthy before moving to the next. Keep all members of a cluster on the same version when you're done, because mixed versions can lead to inconsistent behavior. Schedule production upgrades during a maintenance window: Plan production upgrades for periods of low refresh activity and let stakeholders know ahead of time. That way, any unexpected issue has minimal business impact. Stay on a supported version: Microsoft supports only the last six releases of the on-premises data gateway. Upgrading regularly keeps you on a supported version with the latest security, reliability and accessibility improvements. Next steps Upgrade to version 3000.338 to get the latest accessibility, configuration reliability and diagnostics improvements. Please share feedback and feature requests through the Power BI Ideas forum to help shape future gateway investments. Thank you!
Copy job for SAP with ABAP Add-On in Microsoft Fabric (Preview)
SAP systems sit at the center of many enterprises’ core business operations, powering processes across finance, supply chain, manufacturing, procurement, and HR. That makes SAP data some of the most business-critical data in the enterprise. As organizations modernize their analytics and AI platforms, bringing SAP data together with the rest of the enterprise data estate has become increasingly important. But moving SAP data at enterprise scale has historically been difficult. SAP landscapes are complex, data volumes are large, and extraction architectures often require specialized frameworks, custom code, and additional operational layers. For many organizations, this creates friction between where their most important operational data lives and where they want to analyze, enrich, and activate it. We are delivering the next step of our SAP roadmap: Copy job for SAP with ABAP Add-On in Microsoft, this new capability complements offerings like: SAP Business Data Cloud Connect was announced in SAP and Microsoft accelerate business insights and AI innovation with SAP Business Data Cloud Connect for Microsoft Fabric and will be available over the coming months). It will enable bi-directional zero-copy sharing between SAP Business Data Cloud and Microsoft Fabric without the need for data movement. Mirroring via SAP Datasphere, a turnkey data replication capability providing scalable near real-time data movement from SAP sources into Fabric OneLake (Generally Available). To learn more, refer to the Fabric mirroring documentation. Now, organizations can extract large volumes of SAP data through Copy job, reduce the need for external extraction frameworks, and build a scalable path from initial ingestion to ongoing incremental updates. Copy job provides a configuration driven experience for moving data across clouds, applications and on-premises systems – designed to support high-scale, multi-cloud data movement for petabyte-scale ingestion scenarios. Copy job helps bring data into OneLake as part of a unified, governed foundation for analytics and AI. High-performance SAP extraction with Copy job and Microsoft ABAP add-on integration This new integration option enables scalable, high-throughput extraction from SAP systems, making it easier than ever to bring large volumes of SAP data into Microsoft Fabric for analytics, reporting, and AI. Figure: High-level architecture diagram of Copy job with ABAP Add-on. Broad data coverage across SAP Systems Extracting data from SAP systems at scale can be complex and resource intensive. This new capability simplifies the process while delivering high performance. The solution runs directly inside SAP using a Microsoft-provided ABAP Add-On. Data is extracted at the application layer and transferred efficiently through Copy Job in Fabric Data Factory. This removes the need for complex external extraction frameworks and reduces operational overhead. It supports a wide range of SAP data sources. You can extract from SAP tables, views, and ABAP CDS views, including semantically rich models used for analytics. The capability works across both SAP ECC and SAP S/4HANA, whether deployed on-premises or in the cloud. Providing consistent access to both raw operational data and business-ready data models. Flexible data delivery styles for real-world SAP scenarios Through the integration with Copy Job, the solution handles data movement at scale. The integration is designed for high throughput and efficient processing of large datasets. Parallel execution capabilities help accelerate ingestion and reduce data transfer times. The solution supports different loading strategies depending on your needs. You can perform full snapshots for initial ingestion or bulk replication scenarios. For ongoing updates, incremental loads can be configured using watermark-based extraction. This allows you to process only the data that has changed. Together, these capabilities make it easier to design efficient pipelines. You can start with a large initial load and then transition seamlessly to incremental updates, without changing the overall architecture. SAP data in OneLake, ready for analytics and AI After ingestion, SAP data is immediately available in Microsoft OneLake. From there, it can be used across the entire Fabric platform. You can build Power BI reports directly on SAP data and operational datasets. You can run large-scale analytics workloads or combine SAP data with non-SAP sources from across your organization creating a unified data foundation without silos. With all data in one place, it also becomes easier to enable AI-driven scenarios. Applications and data agents can access consistent, trusted business data to generate insights and drive automation. Get started For more information, refer to the ABAP Add-On for SAP data extraction with Copy Job in Microsoft Fabric documentation. You can start exploring this capability today to: Accelerate SAP data ingestion Simplify data extraction architectures Enable scalable analytics and AI scenarios Looking ahead Copy job for SAP with Microsoft ABAP Add-On is another step in our continued investment in SAP data integration for Microsoft Fabric. SAP is one of the most important enterprise data sources for our customers, and Data Factory in Fabric is designed to help organizations bring SAP and non-SAP data together through scalable, flexible data movement experiences. With Copy job, customers can move data across clouds, applications, and on-premises systems into OneLake. With the Microsoft provided ABAP Add-On, that same Copy job experience now extends more deeply into SAP, helping customers bring business-critical SAP data into Fabric for analytics, reporting, and AI. We will continue expanding SAP data integration capabilities across Microsoft Fabric so customers can simplify their data architectures, reduce silos, and build a unified, governed foundation for enterprise analytics and AI.
Playbook for metadata driven Lakehouse implementation in Microsoft Fabric
Co-Author – Gyani Sinha, Abhishek Narain Overview A well-architected lakehouse enables organizations to efficiently manage and process data for analytics, machine learning, and reporting. To achieve governance, scalability, operational excellence, and optimal performance, adopting a structured, metadata-driven approach is crucial for lakehouse implementation. Building on our previous blog, Demystifying Data Ingestion in Fabric, this post explores how to design and implement an end-to-end metadata-driven Lakehouse using Microsoft Fabric. While the core design principles are applicable to platforms like Azure Databricks and Microsoft Fabric, this blog focuses on leveraging Microsoft Fabric to create a scalable, governed, and high-performance lakehouse—rooted in real-world customer implementations. Basic components of metadata driven Lakehouse implementation framework Below graphic represents the basic building blocks (components) of the reference lakehouse implementation. Basic_building_blocks_of_metadata-driven_lakehouse_implementation Basic building blocks of metadata-driven Lakehouse implementations The table outlines the different components and their respective purposes. # Component name Purpose 1 Control Tables Implement a control table to orchestrate and manage data ingestion, validation, and processing in a Lakehouse. Control tables must store parameters and configurations for ingestion, validation, and ETL processes, enabling dynamic adjustments without modifying the code. 2 Data Ingestion Implement the metadata driven Data Ingestion component leveraging the control table to copy data from various source systems to the lakehouse. You may also use Shortcuts and the Mirroring feature in Microsoft Fabric to streamline ingestion and minimize data movement. Mirroring continuously replicates your existing data estate directly into Fabric's OneLake, including data from Azure SQL Database, Azure Cosmos DB, and Snowflake. 3 Data Validation Implement a data validation component to ensure the integrity of the migrated data. This component will help detect and resolve any discrepancies that might arise during the migration or ingestion process. By systematically validating the data, you can ensure its accuracy, completeness, and consistency, ultimately safeguarding the quality of the migrated datasets. 4 Data Profiling and Data Quality Implement data profiling to gain a comprehensive understanding of your data. This process provides a descriptive overview, highlighting aspects like missing values, datatype distributions, and key statistics. Additionally, it helps identify anomalies by triggering alerts, enabling proactive data quality management and ensuring the data is ready for further processing or analysis. 5 Transformation and enrichment Implement a data transformation and enrichment component to transform and enrich the data for consumption based on configurable transformation, enrichment, and standardization rules. 6 Auditing Implement auditing component to audit the records ingested and processed into lakehouse. Auditing includes identifying any errors or issues that may have occurred during the process, as well as reviewing performance metrics to identify areas for improvement. 7 Notification Implement notification component to notify in case of success or failure events. This is super critical to ensure that the operation team is notified during all critical events. 8 Config Management Implement centralized config management component for managing the configuration to different source and target systems. 9 Reporting Implement a reporting component to visualize metrics related to ingestion, validation, and transformation processes. This will provide the operations team with a single pane of glass, offering an end-to-end status of the lakehouse and enabling them to effectively monitor and manage all processes. Metadata driven framework implementation Now that we've covered the key components, let's explore how these elements can be integrated to create a robust, metadata-driven lakehouse implementation using Microsoft Fabric. Metadata-driven_lakehouse_implementation_using_Microsoft_Fabric Metadata-driven lakehouse implementation using Microsoft Fabric The diagram above highlights the key processing components, such as data ingestion, data profiling, and transformation, at the top, along with cross-cutting components like configuration management, auditing, notification, and reporting that support all processing activities. Key components used in building the metadata-driven lakehouse implementation include - Data ingestion – There are several approaches to implementing data ingestion in Fabric, including a low-code method using Microsoft Fabric Data Pipeline with pre-built source and destination connectors, or a code-based approach using Microsoft Fabric's Spark-based implementation. The destination in Fabric can vary based on the use case or customer preference, including lakehouse files, lakehouse tables, or Data Warehouse. Additionally, other ingestion methods like mirroring and shortcuts are available, which also need to be managed. The benefits of storing data in lakehouse files are it supports both structured and unstructured data in their original format, making it a reliable source of truth for future consumption. Metadata-driven_Data_Ingestion_component Metadata-driven Data Ingestion component The image illustrates the key modules and the high-level data ingestion flow, starting with the control module, which queries the 'ingest_control' table to manage and control the ingestion process based on the configured sources handled by the config module. The data ingestion module is responsible for transferring data into the target lakehouse and utilizes the notification module to send alerts in case of failures. All activities are logged in the 'ingest_audit' table and presented through the reporting module, offering a single pane of glass to monitor the ingestion process into the lakehouse. The monitoring module also tracks shortcut and mirrored items to ensure these are properly captured, using the 'shortcut_audit' and 'mirroring_audit' tables. Metadata-driven Ingestion reference implementation in Action Data validation – The validation module, typically written in Spark, uses the configuration to validate both the source data and the target lakehouse or data warehouse data, checking for completeness and reasonableness. The validation results are stored in the 'validation_results' table and are presented through the reporting module, providing the operations team with insights into any discrepancies introduced during the migration or ingestion process. Playbook_for_metadata_driven_Lakehouse_implementation_in_Microsoft_Fabric Data Validation Component The table provides examples of validation category, scope & criteria. Validation Category Validation Scope Validation Criteria Completeness Row Level Record Count Validation Completeness Column Level Columns Count Validation Completeness Column Level Columns Datatype Validation Reasonableness Column Level Numerical Columns Aggregation Check Reasonableness Column Level Categorical Columns Group By Count Validation Reasonableness Row Level Checksum Validation (first 100 rows) Data quality – The metadata-driven data quality component leverages metadata to automatically assess and enforce data quality rules across the lakehouse or data warehouse. It validates data consistency, accuracy, and compliance with predefined standards. The results are captured in a data quality results table and visualized through the reporting module, enabling the operations team to proactively identify and address any data quality issues. You can use Microsoft Purview’s Data Quality feature to scan lakehouse data and configure data quality rules for automated reporting of data health. Refer to Data Quality for Fabric Lakehouse in Unified Catalog for more information. PII anonymization - PII anonymization component involves identifying and anonymizing personally identifiable information (PII) from datasets to protect individuals' privacy while still allowing for data analysis and decision-making. This is essential in scenarios where sensitive data, such as names, addresses, and social security numbers, is involved. In a lakehouse scenario, PII anonymization is crucial for protecting data from unauthorized access and breaches, ensuring compliance with regulations like GDPR and CCPA, and maintaining data quality and integrity by preventing biases. This process helps organizations use data responsibly without compromising individuals' privacy. Transformation & enrichment – The transformation and enrichment component utilize the enrich control table to retrieve the list of datasets to be transformed, enriched, and stored from the bronze layer to the silver layer. This component handles both simple Spark-based transformations, such as renaming columns and changing data types, as well as more complex rule-based operations, like conditional filtering, any custom business logic or deriving new columns managed through 'transformation_config' table. Once the data is transformed, the serve control table is used to determine which datasets should be served into the gold layer after performing necessary aggregations. The audit module tracks the transformed records and logs the status of each run for accountability and traceability. Playbook_for_metadata_driven_Lakehouse_implementation_in_Microsoft_Fabric Transformation and Enrichment component Reference implementation in action. Bringing it all together using task flow in Microsoft Fabric End-To-End_Metadata-driven_Lakehouse_implementation_using_Microsoft_Fabric_in_ta End-To-End-Metadata driven Lakehouse implementation using Microsoft Fabric in task flow Conclusion Implementing a metadata-driven Lakehouse using Microsoft Fabric enables organizations to efficiently manage and process data with governance, scalability, and optimal performance. By following the structured framework outlined in this playbook, key components like data ingestion, validation, profiling, transformation, and auditing ensure data integrity and quality. This guide emphasizes the importance of cross-department collaboration for seamless implementation, unlocking the full potential of data to drive insights and innovation. We hope this playbook serves as a valuable resource for your Lakehouse implementation journey. Special shout out to Winnie and Dharmendra for their continued contributions!On-premises data gateway September 2026 release
The September 2026 release of the on-premises data gateway (version 3000.334) continues our commitment to delivering secure, reliable, and manageable connectivity between on-premises data sources and Microsoft Fabric services. This release includes improvements focused on gateway manageability, operational visibility, enterprise governance, and platform reliability, helping organizations manage their gateway environments with greater confidence. It also brings compatibility updates for the September 2026 release of Power BI Desktop, ensuring consistent query execution and a seamless experience between Power BI Desktop and cloud-based refresh scenarios. Additionally, this release includes enhancements across security, authentication, diagnostics, and overall platform quality. Feature updates and new capabilities in OPDG Soft Delete in OPDG: Accidental gateway deletions can be disruptive, often requiring administrators to recreate gateway configurations and restore connectivity. With Soft Delete, deleted gateways are retained for 30 days, providing administrators with the ability to recover them and reduce the impact of unintended deletions. Recover deleted gateways Reduce operational disruptions Improve gateway management and reliability Built with customer feedback in mind and another step toward a more resilient connectivity experience in Microsoft Fabric. Learn more about the soft delete in the gateway soft delete documentation. Security improvements and updates Customers are encouraged to upgrade to the September 2026 release to benefit from the latest security updates and dependency improvements. This update helps improve the security posture of on-premises data gateway deployments and addresses vulnerability findings that may be reported by security scanning tools. Upgraded the embedded Apache Log4j library to version 2.26.1. Addressed the security vulnerability documented in CVE-2026-18401. As part of our ongoing commitment to security and reliability, we continuously evaluate and update third-party dependencies. These updates are incorporated into gateway releases following comprehensive security reviews, compatibility validation, and product qualification testing to help ensure a secure, stable, and reliable experience for customers. General improvements and fixes The September 2026 Gateway release (3000.334) includes Power Query Engine 2.158.928 and introduces the following improvements: Fixed a sign-in issue impacting gateway installations on Windows Server 2016. Improved accessibility across the Gateway Configurator application to provide a more inclusive and user-friendly experience. Power BI Desktop compatibility This update brings the on-premises data gateway up to date with the September 2026 release of Power BI Desktop. Download on-premises data gateway (standard mode) Download on-premises data gateway (personal mode) This version of the gateway will ensure that the reports that you publish to the Power BI Service and refresh via the gateway will go through the same query execution logic/run-time as in the September version of Power BI Desktop. Next steps Upgrade to version 3000.334 to take advantage of the latest security, authentication, and diagnostics improvements. We encourage you to share feedback and feature requests through the Power BI Ideas forum to help shape future gateway investments. Thank you!
Modernize your Azure Data Estate with Microsoft Fabric: A guided path from Azure Data Factory and Azure Synapse
Authors: Faisal Mohamood and Bogdan Crivat If you haven't already, check out FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents for a complete look at all of our FabCon Europe announcements across Fabric and Microsoft Databases. Most enterprise analytics estates were assembled rather than designed. A tool for ingestion, another for transformation, a warehouse for data processing, a lake for everything else, and a layer of glue holding it together. That architecture did its job for a decade, but it was built for a world where data moved on a schedule and insight could wait. AI changed the deadline. The organizations pulling ahead today are the ones consolidating on a single platform where data, analytics, and AI share one foundation instead of one integration backlog. For teams running Azure Synapse Analytics and Azure Data Factory, Microsoft Fabric is the next step in that investment—not a departure from it. Fabric unifies data integration, engineering, and warehousing in one SaaS experience, reducing the operational burden of disparate tools and creating a clearer path to AI-driven workloads. The question customers now ask are not whether to modernize, but how to do so without disrupting the pipelines their businesses rely on every day. Upgrade to Fabric Data Factory with confidence Azure Data Factory has earned the trust of customers worldwide by powering mission-critical data integration workloads. Organizations that rely on Azure Data Factory and Azure Synapse pipelines have built critical data integration foundations that form the backbone of their business operations. Fabric Data Factory builds on that trusted foundation while bringing customers into a unified data platform for AI transformation. With OneLake, Copilot-powered experiences, integrated analytics, and Fabric-native innovation, customers can modernize their data integration estate while preserving the investments that matter most. At FabCon Barcelona, we are excited to announce a streamlined upgrade experience that helps Azure Data Factory customers begin their journey to Fabric Data Factory with confidence. This new experience enables Azure Data Factory customers to bring their existing data factory into Microsoft Fabric, view their Azure Data Factory pipelines directly within Fabric, and continue using familiar management and monitoring experiences, all before making any migration decisions. Customers can experience Fabric immediately while preserving their existing Azure Data Factory investments. This is another important step toward our vision that every Azure Data Factory customer can become a Fabric Data Factory customer. The experience is built around three principles we consistently heard from customers: transparency, control, and confidence. Customers want to understand what will change, what will remain the same, and when they should modernize. We provide a guided path that allows organizations to explore, assess, validate, and upgrade on their own terms. The journey begins directly from Azure Data Factory with a simple view in Fabric experience. Customers can bring their Azure Data Factory environment into a Fabric workspace and immediately see their familiar data factory assets and pipelines within the Fabric experience. Existing Azure Data Factory assets remain the source of truth, while customers gain access to Fabric as a natural extension of their current experience. This allows teams to become familiar with Fabric, explore the broader Fabric platform, and understand the value of a unified data estate without disrupting production workloads. Once inside Fabric, customers can evaluate their readiness for Fabric Data Factory using built-in migration assessment capabilities. The assessment provides visibility into pipeline and activity compatibility, helping customers understand which workloads are ready to upgrade, which may require review, and which capabilities are planned for future support. By surfacing compatibility information upfront, customers can make informed modernization decisions and prioritize migration efforts based on business needs. Connection mapping and migration guidance further simplify planning and reduce manual effort. This assessment-first approach is a direct response to customer feedback. Trust is built through visibility, and customers consistently told us they want a clear understanding of readiness before committing to change. After reviewing assessment results, organizations can choose when and how they upgrade to Fabric Data Factory. Supported pipelines can be upgraded incrementally, allowing teams to validate outcomes, gain operational confidence, and modernize at the pace that makes sense for their business. Existing Azure Data Factory workloads can continue operating while organizations evaluate and transition workloads over time. This staged approach helps reduce risk while enabling customers to realize the benefits of Fabric Data Factory and the broader Microsoft Fabric platform. The upgrade journey from ADF to FDF allows customers to plan, explore Fabric, assess readiness, validate outcomes, and upgrade when ready. The journey from Azure Data Factory to Fabric Data Factory is designed to be transparent, low-risk, and customer-driven, helping every Azure Data Factory customer become a Fabric Data Factory customer on their own terms. Read more about the Fabric Data Factory announcements at FabCon Barcelona. Guided migration with Microsoft-approved partners Microsoft-approved partners can guide customers’ upgrade from start to finish, or customers can explore the upgrade independently with no effect on their existing Azure Data Factory pipelines. Customers can now request partner-guided upgrade support online and get connected with Microsoft partner expertise to help plan and execute their Fabric Data Factory upgrade. Partners can help assess the customer’s environment, prioritize workloads, address compatibility requirements, develop the upgrade plan, execute and validate upgrades, and accelerate deployment to production. Learn more about how partners can help guide migration. Modernizing Spark workloads with Fabric Data Engineering Fabric Data Engineering provides a unified foundation for building and scaling Apache Spark workloads alongside the rest of the analytics estate. With capabilities such as the Native Execution Engine, high concurrency, and starter pools, teams can improve performance, reduce operational overhead, and work more easily with shared data in OneLake. The Spark in Azure Synapse to Fabric Data Engineering migration assistant accelerates modernization by migrating Spark pools, notebooks, and Spark job definitions, while mapping lake databases through OneLake catalog shortcuts. Artifacts are copied while data remains in place, allowing existing pipelines to continue running without downtime. A guided experience tracks progress and provides a detailed report of what migrated successfully and what requires attention. OBOS, one of the Nordic region’s leading residential developers, used a phased approach to migrate more than 600 notebooks and pipelines and consolidate over 4,500 data objects into 87 lakehouses. By validating technical results and live business KPIs across both environments before cutover, OBOS reduced operational costs by 20% and accelerated data processing by 30%. “We deliberately ran the old and new environments in parallel, comparing row and column counts and validating business KPIs through live reports before we switched anything over. That rigorous validation mattered, because for a data platform like ours, trust is the product.” - Dag Erlend Berger, Product Lead for the Data Platform, OBOS Complementing the migration assistant, the Fabric data engineering agent (Project Osmos), now in preview, helps accelerate the engineering work that goes beyond moving artifacts. Teams can delegate complex migration and modernization tasks, such as adapting Spark notebooks, refactoring pipelines, and validating migrated workloads. Osmos inspects the relevant data and code, plans and executes the work in Fabric, and iteratively validates and refines the results against the task’s requirements. Authorized teammates can contribute context and steer the same persistent task, with Fabric permissions governing access. This helps reduce manual engineering effort while keeping quality, maintainability, and team oversight central to the transition. Accelerating query performance with Fabric Data Warehouse For organizations managing data volumes in terabytes or petabytes, Fabric Data Warehouse provides superior performance and cost efficiency compared to Synapse dedicated SQL pools. The migration assistant for data warehouse simplifies and automates this transition for existing Synapse customers. The assistant, built directly into the Fabric experience, provides a guided path to convert artifacts from Synapse dedicated SQL pools into Fabric Data Warehouse, helping with schema conversion and data movement alike. It delivers a clear, actionable snapshot of migration results alongside a detailed summary of items that need attention, and Copilot is available to help resolve issues on the spot. To further reduce migration effort, the migration assistant gives customers the flexibility to migrate only what they need. Customers can select specific schemas or individual objects instead of migrating an entire environment, with visibility into object dependencies and guidance on related artifacts that should be migrated together. This allows organizations to break large modernization projects into manageable phases while maintaining confidence that dependent objects are accounted for. Large-scale modernization programs are inherently iterative. Source systems continue to evolve while migration projects are underway, creating a challenge for organizations that need to keep target environments synchronized without repeatedly restarting migration efforts. To address this, we introduced incremental migration support in Migration Assistant. Customers can return to an existing migrated warehouse at any time and apply new changes from their source system, whether they are using a live connection or uploaded SQL files. The experience intelligently identifies differences, helps resolve conflicts, and updates only what has changed, transforming migration from a disruptive, start-over exercise into a repeatable, low-friction process. This significantly reduces the operational burden on migration teams and makes it easier for organizations to move to Fabric with greater confidence. Dentsu, a global advertising and public relations company, was dealing with data growing faster than what its teams could keep up. In partnership with OneLake GmbH, Dentsu accelerated its migration to Fabric, applying deep technical expertise to design a scalable, enterprise-grade analytics platform. “Fabric has evolved beyond self-service analytics to a full enterprise-class platform. By combining data warehousing, lake storage, and Power BI, we’ve unlocked a foundation that sparks curiosity and innovation. People naturally ask, ‘What can I build on top of this?” —Patrick Sura, Global Reporting Architect, Dentsu Nebraska Furniture Mart, a Berkshire Hathaway company managing a large BI estate under significant performance and resource pressure, migrated to Fabric Data Warehouse using the migration assistant. “The tool facilitated every step of the process, automatically addressed column type conflicts, and effectively handled data migration right after the metadata transfer.” — Siri Kakumanu, Senior Manager, Data Analytics and Business Intelligence, Nebraska Furniture Mart Read more about Analytics announcements at FabCon Barcelona. The future of your data estate starts now Whether you are modernizing data pipelines, scaling analytics workloads, or simplifying Spark operations, these tools are designed to help you move forward with confidence and at your own pace. If you want to learn about the migration paths available to Fabric, start with Azure to Fabric Migration site. If you’ve scoped your migration, use cases and are ready to get started, check out our migration documentation for guidance and actionable steps. If you’re looking for hands-on support, connect with your Microsoft account team or visit the Microsoft Fabric Community to learn from customers who have already made the move.FabCon/SQLCon Barcelona 2026: What’s new in Fabric Data Factory
If you haven't already, check out FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents for a complete look at all of our FabCon Europe announcements across Fabric and Microsoft Databases. Almost every conversation I have with customers comes back to the same issue: data fragmentation remains the single biggest challenge to harnessing AI. Harmonizing data across the systems and applications where it resides, and making that data available to the people, applications, and agents that need it, is the work — and most teams are still doing a surprising amount of it by hand. At the European Microsoft Fabric and SQL Community Conference, we are showcasing what’s possible when a data platform is built to address fragmentation across silos while respecting the diversity and heterogeneity of enterprise data estates. We’re introducing more than 45 new capabilities, including additional sources for unifying and distributing data, stronger replication governance, new data destinations, more resilient pipelines, richer monitoring, and AI assistance across the end-to-end experience. The following capabilities, announced at FabCon Barcelona, can help teams operate their multicloud data estates day in and day out. A foundation for the AI-powered enterprise AI is redefining how every organization operates. But AI is only as powerful as the data that grounds it. That is why data integration has never been more important. At Microsoft, we are building the foundation for the AI-powered enterprise with Microsoft Fabric and Data Factory, unifying data across operational systems, clouds, applications, and analytics platforms into a single, trusted, governed data estate. From zero-ETL data unification and real-time intelligence to metadata-driven integration and agentic experiences, we are enabling organizations to turn fragmented data into enterprise intelligence that powers business decisions, workflows, and AI agents. Our ambition is not simply to modernize data integration, but to transform it from a process of moving data into the intelligence layer that powers AI agents, applications, and people with trusted business context. Unifying the data estate: Zero ETL, and now zero excuses Data silos create friction that makes it harder to realize value from data. Data must be copied or extracted, the pipelines that move it must be managed and monitored, and data distributed across systems must be governed. Mirroring helps eliminate this friction by continuously bringing data into OneLake without placing a load on source systems or requiring pipelines to maintain. It has become a fast way for customers to obtain a governed, current view of their operational data. Today, we are extending Mirroring in the two directions customers requested: adding more sources and increasing each source by going beyond data replication. Mirroring for Google BigQuery and Mirroring for SharePoint Lists are both generally available, opening two of the most requested paths into OneLake — one at analytical scale, the other for the lists business teams keeps their working data in. Coming soon, Mirroring for Dynamics 365 Business Central will let customers bring data from selected tables and companies directly into OneLake, unlocking richer reporting and analytics across Microsoft Fabric. Extended Capabilities in Mirroring are now generally available, including Change Data Feeds. We’re also announcing an addition to the extended capabilities in Mirroring for Snowflake: replication of security policies. Governance has traditionally been a challenge for replication. The data may be copied cleanly, but its permissions are not requiring customers to rebuild security policies manually in the destination. Replicating Snowflake security roles in OneLake carries that governance context with the data. Open Mirroring continues to grow through our partner ecosystem, with additional partner investments landing this release. This is an important dimension of our Mirroring roadmap and the only way in which we can cover the breadth of sources that matter to every organization. We are always grateful to our partners for joining us in building a complete and comprehensive Mirroring roadmap. Learn more about extended capabilities in the Mirroring documentation. Multicloud, petabyte-scale data distribution Getting data in is only half of the story. Increasingly, our customers need to distribute data to another cloud, a partner, or their own customers' environments. Bespoke approaches to data distribution are costly and can impose a large integration tax. With Data Factory, our vision is to support data movement across clouds and diverse data platforms. We have a breadth of capabilities in our portfolio to drive data movement from batch to streaming scenarios and multicloud sources and destinations. Copy job in Data Factory is purpose-built for data distribution, with capabilities such as Change Data Capture, Slowly Changing Dimension Type 2, and audit capabilities that preserve history and lineage in the destination instead of requiring them to be reconstructed later. An exciting addition to the Copy Job is the integration of batch-to-stream and stream-to-batch capability, minimizing the gap between these two modalities in data integration. Copy job can now write changes directly to eventstreams, bringing the wealth of batch data sources to enable greater flexibility. Copy job execution can now also be triggered through Fabric Activator, which means that Copy jobs can be triggered in more ways than through a wall-clock schedule. Both of these improvements enable customers to build richer and more elegant architectures for how data integration is done. We are also expanding Copy job’s multicloud data distribution capabilities, giving customers more flexibility in where data lands and greater control over how delivery is managed. This includes SharePoint folders as a destination and support for loading multiple source folders into separate destination tables within a single job. To make distribution easier to operate, audit columns add traceability to data delivered to Snowflake, while workspace monitoring brings job health and throughput into a centralized view so teams can spot failed or slow-running jobs without opening each one. Custom staging database and schema support give customers control over where CDC and SCD Type 2 staging objects are created, helping data delivery fit their existing security and operational practices. Transformation in the tools people already use Transformation is the most widely used integration workload in the Microsoft Fabric ecosystem because it serves people across the full spectrum of data work. A citizen developer shaping data in Power Query, a data engineer using Notebooks to clean, join, and enrich data with custom code, and a code-first team managing a dbt project are solving the same fundamental problem through very different tools and experiences. Our goal is to serve each of them in the way they work best on a shared foundation that does not compromise scale, performance, or governance. At FabCon, we are advancing that vision across Power Query, Dataflow Gen2, notebooks, and dbt — making transformation faster to run, easier to reuse and operate, and more consistent across Power BI and Fabric. In Dataflow Gen2, we are improving performance and scale with optimized Lakehouse writes, V-Order compression controls that help teams balance write cost with downstream query performance, and a modern evaluator expanding across connectors for more consistent execution. We are also introducing Shared Queries so teams can define preparation logic once and reuse it across dataflows, reducing duplication and keeping business rules consistent. We are broadening where Dataflow Gen2 can deliver prepared data by adding destinations across Fabric, Snowflake, and SharePoint. Other multicloud destinations, including Amazon S3 and Google BigQuery, are coming soon. The additions I find particularly compelling are Excel and email destinations: they put trusted data directly into the business tools and workflows where decisions happen, reducing the manual exports and handoffs that still sit at the end of too many data processes. We are also making Dataflow operations easier to manage. Downloadable diagnostics and Dataflow Gen2 run details in Monitoring Hub give teams the execution context they need to move from a failed refresh to an actionable cause faster. One of the innovations I am most excited about is bringing years of Power Query Online advancements to Power BI Desktop. This creates a more consistent Power Query experience across products and gives authors a more natural path from self-service preparation in Power BI to governed, scalable transformation in Dataflow Gen2. For our existing Power BI customers, we are also enhancing the Dataflow Gen1-to-Gen2 Migration Wizard to provide a guided, lower-risk path to modernization. At FabCon, we are adding API support to automate migration across larger estates, a downloadable upgrade report to capture readiness and follow-up actions, and new validation rules to surface compatibility issues earlier. Together, these enhancements help administrators plan and track the move to Fabric with greater confidence. For code-first teams, we are making dbt Job in Fabric generally available with broader enterprise support while preserving the familiar dbt workflow. We are landing dbt-generated logs in OneLake so run history, model execution time, and test failures can be analyzed; extending where teams can build models through Lakehouse and additional Fabric adapters; and carrying environment configuration through deployment pipelines with variable library support. Support for dbt Core v2, previously known as Fusion, is coming soon. Orchestrating data with ease: From low code to pro-code Scale, reliability, and flexibility are essential to any credible data integration platform. Pipelines in Fabric Data Factory power more than 25 billion orchestration runs each month. Built on Azure Data Factory’s proven platform, pipelines provide a widely used orchestration foundation for enterprise data integration. At FabCon Europe in Barcelona, we’re delivering the next wave of orchestration capabilities in Fabric Data Factory: more resilient pipelines, richer monitoring, agentic experiences that reason over pipeline runs, new Actions activities that enable pipelines to integrate directly with Fabric platform APIs, and business activities. The Lakehouse Maintenance activity enables you to run vacuum and optimize directly from your pipelines, so maintenance happens on the same cadence as the data that needs it — faster queries and lower storage overhead, with no separate job to own. Pipeline activities also support exponential retry, where retry delays increase over time, so transient throttling resolves itself instead of turning into a failed run and a morning of manual re-runs. Outlook activity now supports service principal and workspace identity, so notifications run on a workspace identity or service principal rather than a personal account — email workflows remain operational when personnel change and can be deployed cleanly across environments. Pipeline-level dependencies let you define relationships between pipelines, enabling dependent pipelines to run only after upstream pipelines succeed. Monitoring itself gets richer: runtime events, performance metrics, and intelligent error classifications now sit together in Monitoring Hub, so an engineer goes from alert to cause without leaving the monitoring surface. Agentic investigation uses AI-powered analysis to help identify whether an issue may be related to code, data, or capacity. New activities extend what a pipeline can do. We’re introducing activities that let you invoke Fabric platform APIs natively from pipelines and incorporate business activities into pipeline workflows. Agentic approvals with the Approval activity put human-in-the-loop decisions inside the pipeline, with an agent that evaluates signals and surfaces a risk score based on the environment, data classification, volume, and requestor, and leaves a full audit trail on every decision. AI-assisted data integration AI in data tools has traditionally taken the form of a chat window used primarily for authoring and starting conversations. What we’re delivering now is different: AI-assisted and AI-driven experiences integrated across the data integration lifecycle, from authoring and operationalizing to monitoring, troubleshooting, repairing, and automating workflows. Fabric Model Context Protocol (MCP) and Fabric Skills provide the foundation for this end-to-end continuum. The MCP gives agents a standardized way to reach tools and resources, which means a developer can work with an agent to create a dataflow, write and update queries, trigger a refresh, start a pipeline run, and check its status — without a bespoke integration for each one. Agent-driven automation scenarios build on this foundation, and the Data Factory MCP and related skills are publicly available for developers. Unified Copilot and Fabric Skills investments give the assistants integrated across different surfaces of Fabric a common understanding of the estate and shared context. AI-powered operations and observability-focused agents turn a wall of run history into an actionable answer about what broke. Taken together, they shorten the two tasks that consume most of a data engineer's week: writing the logic and finding out why it stopped working. Upgrading the integration estate you already have Azure Data Factory has earned the trust of customers worldwide by powering mission-critical data integration workloads over the last 10 years. Organizations that rely on Azure Data Factory and Azure Synapse pipelines have built critical data integration foundations that form the backbone of their business operations. Fabric Data Factory builds a trusted foundation while bringing customers into a unified analytics platform designed for the AI era. With OneLake, Copilot-powered experiences, integrated analytics, and Fabric-native innovation, customers can modernize their data integration estate while preserving the investments that matter most. At Fabric Conference Barcelona, we are excited to announce a streamlined upgrade experience that helps Azure Data Factory customers begin their journey to Fabric Data Factory with confidence. This new experience enables Azure Data Factory customers to bring their existing data factory into Microsoft Fabric, view their Azure Data Factory pipelines directly within Fabric, and continue using familiar management and monitoring experiences, all before making any migration decisions. Customers can experience Fabric immediately while preserving their existing Azure Data Factory investments. This is another important step toward our vision that every Azure Data Factory customer can become a Fabric Data Factory customer. Learn more about upgrading from Azure Synapse and Azure Data Factory to Microsoft Fabric. Customers leading the way The clearest way to explain what we are building is to watch a real customer use these capabilities for mission critical use. London Stock Exchange Group (LSEG) operates some of the world's most critical financial market infrastructure, and its data and analytics business turns operational data from many systems into governed data products that customers consume inside their own environments. Before Fabric, each of those three steps had its own machinery: pipelines to build and watch, analysis running on copies that engineers spent time reconciling, and a bespoke last mile for every customer of LSEG that was onboarded. LSEG’s data integration architecture is now vastly modernized. Mirroring brings the operational data into OneLake and keeps it current, the Fabric workloads shape it into the products customers pay for, and Copy job distributes those products out to customer environments — whether that environment is Fabric, another cloud such as Databricks or Snowflake, or a platform of their own. As Toni McDerment, who leads data interoperability at LSEG, puts it, the team is expanding distribution while streamlining integration. That is the whole data integration story in one customer: ingestion, analytics and delivery on a single estate. Across the conference, other customers showed the same shift from their own angles: Mediterranean Shipping Company — the world's largest container shipping company, with more than 1,000 vessels — replaced six-hour (sometimes multi-day) ETL cycles with real-time mirroring from SQL Server 2025 into Microsoft Fabric, moving operational data into analytics in seconds instead of hours while cutting storage costs 20% through new compression. For KPMG, onboarding clients and provisioning environments for new engagements — which previously required tickets and setup across multiple tools — decreased 87% from about 16 hours to 2 hours. Porsche Cup Brasil replaced spreadsheet-based, manual race reporting with a unified Fabric data pipeline — streaming more than 180 telemetry channels from 75 race cars via Eventstream into Eventhouse, Azure Data Factory, OneLake, and Power BI. The solution reduced engine-fault detection and response time from approximately 30 minutes to minutes, allowing teams to remove a failing engine from the grid before a breakdown. And we have many more customers achieving similar outcomes, with the same conclusion: the ceiling on what AI can do for a business is set by the quality, accessibility, and governance of the data underneath it. Looking ahead Data Integration is always a means to an end – data movement, orchestration, connectors are all structural elements that contribute toward the goal of turning massive amounts of data into business value. With Microsoft Fabric, our goal is to make these constructs disappear so that customers can focus on what ultimately matters – harnessing the value that resides in the data to improve business outcomes by leveraging AI. Our core focus in Data integration is making our products enterprise ready, work across clouds and be AI-driven. The work across our key investments and the 50-plus capabilities in this release are driving towards it. We are excited about what comes next and grateful to the customers, partners, and our community members who build this with us. Your ideas shaped this release, and they are already shaping the next one. Read the full list of FabCon announcements in the September release blog. Learn more Data Factory in Microsoft Fabric Get started with Microsoft Fabric What's new and planned for Data Factory In-depth technical blogs on the Microsoft Fabric Updates BlogOn-premises data gateway August 2026 release
The August 2026 release of the on-premises data gateway is version 3000.330. The new August 2026 release of the on-premises data gateway (version 3000.330) continues our commitment to delivering secure, reliable, and manageable connectivity between on-premises data sources and Microsoft Fabric services. This release includes improvements focused on gateway manageability, operational visibility, enterprise governance, and platform reliability, helping organizations manage their gateway environments with greater confidence. It also brings compatibility updates for the August 2026 release of Power BI Desktop, ensuring consistent query execution and a seamless experience between Power BI Desktop and cloud-based refresh scenarios. Additionally, this release includes enhancements across security, authentication, diagnostics, and overall platform quality. We have received a few questions from community members regarding CVEs identified in third-party components used by the on-premises data gateway. As part of our ongoing commitment to security and reliability, we continuously evaluate and update third-party dependencies. These updates are incorporated into gateway releases following comprehensive security reviews, compatibility validation, and product qualification testing to help ensure a secure, stable, and reliable experience for customers. Security and dependency updates are delivered through regular gateway releases. We recommend keeping your gateway deployment up to date to benefit from the latest security enhancements, dependency updates, performance improvements, and platform reliability fixes. Power BI Desktop compatibility This update brings the on-premises data gateway up to date with the August 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 August version of Power BI Desktop. Next steps Upgrade to version 3000.330 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.
Upcoming changes to legacy Teams and Outlook activities in Fabric Data Factory pipelines
Beginning October 30, 2026, users will no longer be able to add new legacy Teams or legacy Outlook activities to pipelines. These legacy activities will no longer appear as options when users add new activities to a pipeline. Existing legacy activity instances can still be edited and used in existing pipelines. New notification scenarios should instead use the modern Microsoft Teams and Outlook 365 Email activities.Workspace Outbound Access Protection (OAP) for Operations Agent and Fabric Maps (Preview)
Co-authors: Andre Terceros and Bodhisatva Gautam Workspace Outbound Access Protection (OAP) in Microsoft Fabric helps WS admins secure outbound connections from workspace items to external resources. Administrators can control outbound access by blocking unwanted connections by default and allowing only approved connections through configured rules. As organizations adopt AI-powered operations at scale, governance and security remain at critical requirements. With this preview release, Microsoft Fabric introduces Outbound Access Protection (OAP) for Operations Agent and Fabric Maps, enabling workspace administrators to control the outbound actions an agent can perform. OAP for Operations Agent When OAP is enabled, Operations Agent continues to perform core functions including reasoning, recommendation generation, rule evaluation, and telemetry collection. However, outbound actions are governed by the workspace's configured access policies. Administrators gain greater visibility through in-product notifications, Teams messaging experiences, and the Operations Agent Activity Log, making it easier to identify and troubleshoot blocked actions. Figure: Outbound Access Protection helps workspace administrators govern outbound Operations Agent actions while providing clear visibility when actions are blocked. What's new with Operations Agent and OAP? With Outbound Access Protection support for Operations Agent, workspace administrators gain more control over how agent-initiated actions interact with external services and resources. The following updates improve governance, visibility, and operational oversight while helping organizations continue to automate with confidence. Govern outbound agent actions through workspace-level OAP policies. Control whether Operations Agent can send Teams notifications based on allowed connections. Prevent unauthorized cross-workspace actions when OAP policies restrict outbound access. Receive clear visibility when actions are blocked through in-product notifications and Teams messaging experiences. Monitor agent activity and OAP-related outcomes through the Operations Agent Activity Log. Figure: Activity Log Operations Details show the steps the agent completed and each action’s status, including when an action is blocked. OAP for Maps Fabric Maps can connect to a variety of data sources, including Lakehouse across Fabric workspaces, Kusto databases (KQL), Ontologies as well as external geospatial services such as Web Map Services (WMS), Web Map Tile Services (WMTS), and Web Feature Services (WFS). Workspace Outbound Access Protection helps organizations maintain security and compliance by governing outbound connections and requiring explicit approval before a map can access external resources. With OAP enabled, Fabric Maps follows a "default deny" model, ensuring only approved destinations can be accessed. How it Works When Workspace Outbound Access Protection is enabled on a workspace, Fabric Maps evaluates outbound connectivity at multiple stages: Save and Load Operations Whenever a map is created, updated, or loaded, Fabric evaluates all referenced data sources against the workspace policy. If a data source isn't permitted: References are blocked Disallowed sources are redacted when the map is opened Attempts to save unsupported references are rejected Runtime Data Access Map visuals continuously retrieve data such as: Map tiles Geospatial features Query results Before each outbound request is executed, Fabric validates the destination against the workspace's outbound access protection policy. External Service Validation External geospatial services such as WMS, WMTS, and WFS are validated through Data Movement and Transformation Services (DMTS). DMTS acts as a policy enforcement layer and ensures only explicitly approved external endpoints can be reached. Supported Connection Scenarios Lakehouse Lakehouse connectivity receives the most flexibility under the current release. Lakehouse within the same workspace are always allowed. Lakehouse in other workspaces can be allowed using Data Connection Rules. Administrators maintain granular control over cross-workspace access. External Geospatial Services Organizations can securely connect to approved WMS, WMTS, and WFS services. By using Data Connection Rules with the Geospatial Web Services connection type, administrators can create an allow list of approved endpoints. This enables scenarios such as: Accessing enterprise GIS systems Consuming approved mapping services Integrating with external geospatial data providers Kusto Databases and Ontologies Connections to Kusto databases and Ontologies within the same workspace continue to function normally. Cross-workspace connectivity for these sources is currently blocked when OAP is enabled. Future releases will introduce additional policy controls for these connection types. Configuring Fabric Maps with Workspace OAP Enabling protection is straightforward: Enable Workspace Outbound Access Protection for the workspace. Create Data Connection Rules that define approved destinations. Add approved external geospatial services using the Fabric connection experience. Configure Geospatial Web Services rules to authorize required endpoints. Once configured, Fabric Maps can access only the approved destinations specified by policy. Security by Design Workspace OAP for Fabric Maps follows several key security principles: Explicit Allow Lists: Only approved destinations can be reached. All other outbound connectivity is automatically blocked. Consistent Enforcement: Policies are applied during authoring, loading, and runtime execution, ensuring continuous protection throughout the lifecycle of a map. Fail-Closed Protection: If policy validation services become unavailable, Fabric denies cross-workspace connections by default. This fail-closed behavior helps prevent unintended data exposure during service disruptions. What’s next? We are actively working to expand OAP support for additional experiences and plan to add support for Power BI Semantic Models and Reports soon in GA soon. Your feedback is essential! Let us know how we can make Fabric even more secure and flexible for your workloads by sharing your feedback at Fabric Ideas – Microsoft Fabric Community Learn more Workspace outbound access protection overview Outbound Access Protection for Operations Agent (Preview) Workspace Outbound Access Protection for Fabric MapsConnect 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 endpoints
