The next chapter for CI/CD in Fabric Warehouse (Preview)
Building and operating a data warehouse is increasingly a software engineering discipline. Teams want to develop warehouse changes in isolation, version them in Git, review them through pull requests, promote them safely across environments, and automate the entire process using their existing CI/CD systems. Over the past several releases, we've been evolving CI/CD in Fabric Warehouse around that lifecycle: DacFx established a common schema deployment foundation. Pre, and post-deployment scripts expanded deployments beyond schema changes. Warehouse Item Definition APIs opened the same lifecycle to automation. Together, these investments are creating a more complete CI/CD lifecycle for Fabric Warehouse, from developing and versioning database changes to deploying and automating them across environments. Let’s take a closer look at how each capability moves that experience forward, what’s available today, and what we’re building next. What we've delivered Establishing a consistent deployment foundation with DacFx The first challenge was making Warehouse deployments behave like database deployments, not artifact copies. A Warehouse contains state, data, dependencies, and relationships between database objects. Moving a change from development to production therefore requires understanding what changed and how those changes should be applied to the target database. This is where DacFx became foundational to the experience. With Git Integration, it is represented as a SQL database project in source control. Developers can work using familiar Git practices such as branching, commits, and pull requests. When those changes are synchronized back to Fabric, DacFx understands the database model and determines the schema changes that need to be applied. Figure: Git-based development workflow in Microsoft Fabric, enabling isolated feature development, collaboration through pull requests, and synchronization of Fabric items across feature and shared workspaces, with infrastructure managed as code. We extended that same foundation to deployment pipelines. When a Warehouse moves between development, test and production environments, DacFx compares source and target states and generates the incremental deployment required to move the target to the desired state. Figure: End-to-end CI/CD workflow in Microsoft Fabric, combining Git-based feature development with deployment pipelines to promote Fabric items consistently across development, test, and production environments. That established a consistent path: Develop → Version in Git → Review → Deploy → Validate → Promote. Pre, and post-deployment scripts A production deployment rarely consists of schema changes alone. Teams often need to prepare data before a deployment, seed or initialize data afterward, or execute SQL actions that need to happen at a specific point in the release. To support that workflow, we introduced pre, and post-deployment scripts. A shared SQL query can be designated as a pre, or post-deployment script and becomes part of the SQL project. The designation travels with the Warehouse through Git, allowing those actions to be versioned and deployed together with the database definition. The resulting deployment lifecycle becomes pre-deployment actions → DacFx schema deployment → post-deployment actions Pre, and post-deployment script configuration in Fabric Warehouse, enabling developers to define SQL scripts that execute automatically before and after schema deployment as part of the CI/CD lifecycle. This moves more of the database release process into the CI/CD definition rather than leaving teams to coordinate separate manual steps. Learn more about pre and post-deployment scripts. Warehouse Item Definition APIs Git integration and deployment pipelines provide built-in Fabric experiences, but enterprise CI/CD also needs to work outside the Fabric portal. Customers have existing build systems, automation frameworks and release pipelines and need a programmatic way to manage Warehouse definitions. Warehouse Item Definition APIs are the next part of that foundation. Warehouse definitions support SQL project and DACPAC formats, and Fabric APIs can be used to create a Warehouse from a definition, retrieve its current definition, or update it programmatically. Learn more about the Warehouse REST APIs. This means the same Warehouse definition that underpins Git integration can also participate in API-driven CI/CD workflows. Bringing Familiar Warehouse Development Experiences to Client Tools A complete CI/CD experience starts well before deployment. Developers need familiar tools to build, compare, validate, and manage database changes throughout the development lifecycle. Alongside our DacFx investments, we've strengthened Fabric Warehouse support across SQL Server Management Studio (SSMS) and Visual Studio Code, bringing familiar SQL development workflows closer to the Fabric web experience. These investments include: Database project support in SSMS: Develop and manage Warehouse schemas using SQL database projects and familiar database development workflows. Schema Compare in VS Code: Compare database schemas, review differences, and generate the changes needed to synchronize environments. Consistent database development: Use the same SQL project and DacFx foundation whether developing in the Fabric portal or client tools. Pre, and post-deployment scripts: Maintain deployment scripts as part of the database project, enabling a consistent deployment experience across web-based and client-based development workflows. The goal is simple: developers should be able to choose their preferred development environment without changing how their database projects are versioned, built, or deployed. This brings together the flexibility of familiar SQL development tools with the integrated CI/CD experience in Fabric Warehouse. What's next for CI/CD in Fabric Warehouse Building on this foundation, we’re focusing on three investments: Deployment configurations: Give developers control over how changes are applied. Cover data handling, object handling, and error handling. Apply different behaviors per environment, such as permissive in development and stricter in production. Fabric CI/CD package (fabric-cicd) support for Warehouse: Simplify end-to-end automation. Deploy Warehouse definitions from source control alongside other Fabric items. Integrate with systems like Azure DevOps and GitHub Actions. CI/CD for SQL analytics endpoint: Extend Git integration and deployment pipelines using the same SQL project and DacFx foundation. Lay the groundwork for coordinated deployments across dependent Fabric items in medallion and data mesh architectures. The goal: Move from CI/CD for individual items to a consistent, predictable, automated lifecycle for interconnected Fabric analytics solutions. Get started with CI/CD in Fabric Warehouse Connect your Warehouse to Git: Set up Git integration to version your Warehouse as a SQL database project and develop changes in isolation. Promote changes across environments: Use deployment pipelines to move Warehouse changes from development to test and production. Automate data actions around your releases: Configure pre and post-deployment scripts so data preparation and seeding travel with your database definition. Integrate with your existing CI/CD systems: Use the Warehouse REST APIs to create, retrieve, and update Warehouse definitions programmatically. Try these capabilities today and share your feedback in Fabric Ideas | Microsoft Fabric Community. Your input directly shapes what we build next for CI/CD in Fabric Warehouse.
Let’s Get Certified: DP-600 Microsoft Fabric Analytics Engineer Associate Livestream
Getting ready for DP-600? Join the Microsoft Fabric Location Intelligence & Security User Group for a free half-day livestream covering every domain of the Microsoft Fabric Analytics Engineer Associate exam. Learn together with a global community, ask questions live, and leave with a strategy for exam day. 📅 Thursday, November 12 ⏰ 11:30 AM GMT | 12:30 PM CET | 5:00 PM IST | 7:30 PM PHT | 6:30 AM ET 📍 Free on YouTube (link sent when you register) Opening: The Fabric Analytics Mindset and DP-600 Overview, Philippa Burgess Session 1: Preparing Data for Analytics in Microsoft Fabric, Thummalacherla Krishnakanth Session 2: Transforming and Querying Data with SQL, KQL and DAX, Ladislau André Session 3: Designing and Building Semantic Models, Tooba Arshad Session 4: Optimizing Semantic Models with Power BI and Excel, Philippa Burgess Session 5: Maintaining Analytics Solutions and DP-600 Exam Strategy, Katia Agoudjil Moderators: Nandan Hegde, Thummalacherla Krishnakanth and Abel Chimbua Wanda Register: https://luma.com/vszsn83x This is a qualifying Data Days event toward a free DP-600, DP-700 or DP-800 exam voucher: https://aka.ms/dd/cert Can’t make it live? Register anyway to get the replay and resources. Produced in association with GeoCyber Systems LLC.Bring your Fabric data into your next app with connectors
Most business applications start with data that already exists. Customer orders may live in a Fabric SQL database. Inventory history may be in a Lakehouse. Sales performance may already be modeled in Power BI. The opportunity is not to move that data again, but to turn trusted data into an experience that helps people make decisions and take action. Connectors in Fabric Apps shorten that path. They give an app a consistent way to work with Fabric data, so developers can spend less time on integration plumbing and more time building the experience users need. Connect to the Fabric data you already trust. Build the experience your users need. Keep the application close to the data and governance foundation already in place. Instead of beginning with infrastructure, start with the customer's need: What should this app help someone understand, decide, or do? From data to an application Imagine a large telecommunications provider operating thousands of cell sites and serving millions of customers. Network telemetry may stream into a Lakehouse; service-impact and incident data may live in a Fabric SQL database; and trusted availability and capacity measures may already be modeled in Power BI. A report can show where the service is degrading. But a network operations engineer may need to go further: Which sites and customers are affected? Is the issue driven by congestion, equipment, power, or an upstream dependency? What maintenance work or recent changes are associated with the site? Can I create or update an incident and route the next action from the same experience? This is where a Fabric App adds value. Connectors let the app combine governed network and operational data in one task-oriented experience for investigation, triage, and action. Architecture: Network operations app Network telemetry remains in Fabric; operational records stay in their governed source; and trusted measures continue to come from the semantic model. The Fabric App brings those sources together so an engineer can move from a network signal to an informed operational action without reconstructing context across multiple tools. Choose the connector that matches the job Choose the connector that matches the Fabric item and the job the app needs to perform. Fabric Apps supports documented connector patterns for lakehouse SQL analytics endpoints, warehouses, SQL databases in Fabric, and Power BI semantic models. Fabric source Connector type Documented operations Lakehouse SQL analytics endpoint fabric-sqlanalytics Read Warehouse fabric-warehouse Read, create, update, delete SQL database in Fabric fabric-sqldatabase Read, create, update, delete Power BI semantic model fabric-semanticmodel executeQuery Request only the operations the scenario needs. For example, a read-only inventory experience should not request write access. An operational app that updates a warehouse or SQL database should make that requirement explicit. Three real-world patterns Incident triage A telecommunications provider can build a network operations app on a Lakehouse, Fabric SQL database, and semantic model. An engineer can search for a cell site; review latency, congestion, availability, and impacted services; inspect recent maintenance or configuration changes; and create or update the operational incident from one experience. Value: The engineer moves from detecting service degradation to understanding impact and coordinating the next action without switching across disconnected monitoring and case-management views. Customer 360 for sellers A sales team may have accounts and order data in a warehouse, product signals in a Lakehouse, and trusted revenue measures in a semantic model. A Fabric App can organize this information around the account and add a tailored experience for exploration, notes, recommended next steps, or AI-assisted questions. Value: The app is designed around the seller’s job, not around the boundaries between data systems. Retail store operations from a semantic model Imagine a retailer such as Nordstrom with trusted sales, inventory, fulfillment, and customer-service measures already defined in a Power BI semantic model. A Fabric App can use that model as the analytical foundation for a store operations experience where a manager reviews daily performance, identifies products at risk of stocking out, investigates order or pickup delays, and coordinates the next action with the store team. Value: Store teams reuse trusted business measures and move from insight to action without recreating logic or switching across multiple reports and operational tools. Start with one focused workflow A good first app starts with a narrow, valuable job. The builder journey is: Create or initialize a Fabric Apps project. Identify the Fabric item behind the workflow. Add a connector with only the operations the app needs. Test with the permissions and data boundaries expected for users. For example, a read-only warehouse connection can expose governed site and service-impact data to the app: npx rayfin connector add \ --type fabric-warehouse \ --workspace-id YOUR_WORKSPACE_ID \ --item-id YOUR_WAREHOUSE_ITEM_ID \ --name network-operations \ --operations read The connector is added to the project configuration and can then be used through the generated connector interface. For complete syntax, supported operations, prerequisites, and current limitations, see Connect Fabric Apps to Fabric data. Build from the data you already trust Your most valuable business data is already in Microsoft Fabric. Connectors help you turn that data into focused applications that do more than display insight by helping you complete real business tasks. Get started with Fabric App and connect to your data.Securing and governing your medallion layers in Fabric Data Warehouse
Coauthor - Artur Vieira Part 4 of a series on medallion architecture with Fabric Data Warehouse. Security should follow the layers, not fight them. In Part 1 we chose the pattern, in Part 2 we built the layers, and in Part 3 we covered the operating practices that keep them healthy. Security is the natural next step, because a medallion architecture already gives you something most platforms do not: three clearly different audiences. A medallion architecture creates clear boundaries between raw, refined, and curated data. Applying security and governance at those boundaries helps reduce unnecessary exposure, simplify access decisions, and give each audience the data it needs without opening every layer.. The following approach shows how to secure and govern a medallion pipeline in Fabric Data Warehouse. Why this matters Most access problems in analytics platforms are not dramatic breaches. They are cases of unnecessary access, such as an analyst who can read raw customer records because the entire warehouse was shared or a service account with more permissions than its task requires. A medallion architecture simplifies this work because each layer already signals a different level of sensitivity. Raw data is typically the most exposed and least useful to a business user, while curated data is shaped for broader consumption. The security model should follow that progression. The goal is simple: as data moves toward Gold, the audience can expand because the data has been cleaned, shaped, and protected for broader use. Rule 1: Separate the layers before you secure them Access control is much easier when the layers are separate objects. This is the same layout rule from Part 1, now with a security payoff. In Fabric, if Bronze, Silver, and Gold live in separate workspaces, you can keep the Bronze workspace restricted to a small engineering group while giving a wider audience access to the Gold workspace. Separate workspaces also provide clearer access boundaries and can help isolate workloads across the medallion layers. Workspace roles and item permissions are not the same thing, and the difference matters for medallion. Admin, Member, and Contributor all receive CONTROL on every warehouse and SQL analytics endpoint in the workspace: full read/write access plus the ability to manage SQL permissions. Viewer receives CONNECT and ReadData, so viewers can read every table and view with T-SQL. When you share a single warehouse instead, you choose the level: Read lets the recipient connect only, “Read all data using SQL” grants ReadData (the equivalent of db_datareader), and “Read all data using Apache Spark” grants ReadAll over the warehouse’s files in OneLake. ReadData and ReadAll are separate permissions that do not overlap. Treat ReadAll as an engineering permission: row-level and column-level security apply only to queries on the warehouse or SQL analytics endpoint, so Spark access to the underlying files should go only to people who are allowed to see everything in that layer. Access path What it grants Typical use in a medallion design Workspace Admin, Member, Contributor CONTROL on every warehouse and SQL analytics endpoint; sees unmasked data Engineers who build and operate the layer Workspace Viewer CONNECT and ReadData on every warehouse in the workspace Read-only consumers of a whole workspace, usually Gold Item share: Read Connect only; no table access until granted with T-SQL Granular, object-by-object access Item share: Read all data using SQL (ReadData) Read-only access to all tables and views, like db_datareader Gold consumers and report users Item share: Read all data using Apache Spark (ReadAll) Access to the warehouse’s files in OneLake through Spark Engineers who need Spark; grant sparingly Do this well: Put each layer in its own workspace when governance matters, or at least in its own Fabric item. Assign workspace roles deliberately. Admin, Member, Contributor, and Viewer are not interchangeable. Give analysts Viewer access to Gold and no path into the Bronze workspace at all. Share Gold with “Read all data using SQL” for consumers, or share with Read only and add T-SQL GRANTs when they should see just some objects. Rule of thumb: if one workspace role grants access to raw and curated data at the same time, the layout is doing security a disservice. Rule 2: Grant the least privilege each layer needs Within a warehouse, Fabric Data Warehouse supports granular SQL permissions. You can grant or deny access to schemas, tables, views, and procedures, which is especially useful when multiple medallion layers share one warehouse. If Bronze and Silver sit in the same warehouse separated by schemas, revoke general read access on the Bronze schema and let only engineers or a service identity use it. Most consumers should never need more than read access to Gold. Do this well: Default to read-only for anyone who consumes data rather than builds it. Give pipelines and service identities only the permissions their job requires, on the layers they actually touch. Review permissions when a layer changes owners, not only when someone complains about access. Rule of thumb: many people need Gold, a few need Silver, and very few should need Bronze. Rule 3: Use row-level security when one table serves many audiences Row-level security in Fabric Data Warehouse controls which rows a user can view based on group membership or execution context. This lets one Gold table safely support audiences such as different regions, departments, or customers without creating a separate table for each group. This belongs mostly in Gold. That is where a single fact table often serves several regions, departments, or customers at once. Bronze and Silver are usually restricted to a small team already, so filtering rows there solves a problem you should not have. One scope note: row-level and column-level security apply to queries on the warehouse or SQL analytics endpoint. Power BI semantic models in Direct Lake mode fall back to DirectQuery to honor them, so include that in your Gold performance testing. Do this well: Apply row-level security to every table that requires audience-specific filtering. If a table has no row-level security policy, users with access to that table can view all rows permitted by their other assigned permissions. Account for pipeline identities in the predicate, so data movement is not blocked by the filter. Test as a restricted user, not only as an administrator, so modeling mistakes surface before publication. Rule of thumb: use row-level security to share one trusted table safely, not to compensate for a missing Gold model. Rule 4: Protect sensitive columns instead of hoping nobody queries them Some fields should not travel all the way to Gold. The cleanest control is simply not exposing a sensitive column in the curated layer at all. When a sensitive field must remain in the warehouse, use column-level security to block access for roles that should not see it. Use dynamic data masking when the column must remain available but its value should be obscured for users without permission to view the original data. Implement column-level security with a GRANT SELECT that lists only the permitted columns; any query that touches another column fails. Masking behaves differently. Administrators, members, and contributors hold CONTROL on the warehouse and see unmasked data by default, and a user with query access can infer masked values through range filters. Use masking to prevent accidental exposure, and rely on column-level security and least privilege when a value must stay hidden. Do this well: Drop identifiers in Silver or Gold when the business question does not need them. Use column-level security when a role should not see a field at all, and masking when the field must be present but obscured. Grant the unmask narrowly and treat it as a decision worth recording. Rule of thumb: the safest sensitive column is the one Gold never carries. Rule 5: Make governance visible Security defines who can access data. Governance explains where the data came from, what it means, how it should be handled, and how it is being used. Fabric’s lineage view helps trace how data moved between items, especially when pipelines and dataflows do the work. Descriptions on tables and columns are worth the effort, because they tell the next person which fields are sensitive and how a value was derived. Audit logs matter most on Bronze and Silver, where unexpected access is the signal you actually want to catch. Do this well Document how Gold fields are derived from Silver, so a report can be traced back to its source. Keep a catalog of sensitive fields and where they live in each layer. Review access to each workspace and item on a schedule, rather than only after an incident. Rule of thumb: if nobody can explain where a Gold number came from, governance is missing even when security is fine. Compliance in a medallion pipeline A clear medallion design also makes compliance work easier to reason about. Bronze typically holds personal data in its rawest form, and Silver is a natural place to pseudonymize, filter, or otherwise reduce what moves forward. When a deletion request arrives, use the layer boundaries to identify every copy of the affected data and remove or update it according to your organization’s retention and deletion requirements. Then refresh downstream Silver and Gold data so the corrected state is reflected throughout the pipeline. Better still, decide early whether sensitive data needs to land in Bronze at all. The least expensive compliance problem is the one you never create. Access at a glance Use this as a starting point when you map audiences to layers. Layer Typical audience Primary control Fine-grained control Bronze Data engineers and service identities Restricted workspace or item permissions Schema-level grants and denies Silver Data engineers and modelers Moderately restricted access Object permissions, pseudonymization Gold Analysts and business consumers Broad read-only access Row-level security, column-level security, and data masking Takeaway Secure each layer for its audience. Bronze stays highly restricted, Silver stays moderately restricted, and Gold is widely readable but carefully shaped. Use workspace roles and item permissions as your first line of control, then SQL permissions, row-level security, column-level security, and masking for the fine-grained cases. Pair that with lineage and audit so the pipeline can be explained, not just accessed. Done well, a medallion architecture does not only deliver clean data. It also makes it obvious who should see what. Ready to go deeper? Explore the Fabric Data Warehouse security documentation, then stay tuned for Part 5 of this series, where we’ll cover performance tuning your medallion pipeline. References Row-level security in Fabric Data Warehouse Implement row-level security in Fabric Data Warehouse Column-level security in Fabric Data Warehouse Dynamic data masking in Fabric Data Warehouse Workspace roles in Fabric Data Warehouse Share your warehouse and manage permissions (Read, ReadData, ReadAll) SQL granular permissions in Fabric Data Warehouse 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 pipelineBring insights and action together with Fabric Apps in Org apps
Business users move from understanding what happened, to investigating why, to acting. Microsoft Fabric can bring that journey together. Fabric Apps provide purpose-built, data-driven experiences when users need more than a report. Org apps distribute them alongside Power BI reports and other supported Fabric content in a curated destination. Move from insight to action in one destination Power BI reports help users monitor performance, explore trends, and understand what’s happening in the business. Many insights, however, lead to a next step: submitting a request, updating a plan, investigating an exception, assigning an owner, or tracking a resolution. A Fabric App provides the custom interface and workflow for that next step. Including it in an org app places action beside the reports and operational content that provide context. Users enter one destination organized around their role, review the insight, open the Fabric App, and act. Understanding apps in Fabric Experience Purpose Value Fabric Apps Build for a specific task Create purpose-built applications connected to Fabric data, with managed APIs, authentication, hosting, and service integration. Org apps Distribute in business context Package Fabric Apps with Power BI reports, paginated reports, notebooks, maps, and real-time dashboards, with tailored navigation, branding, and audiences. Workspace apps Distribute Power BI content Package and publish reports and dashboards from a workspace. Does not support notebooks and real-time dashboards, automatically granting and revoking access to underlying items and support for Fabric Git integration What the combined experience looks like Consider a retailer that wants regional managers to identify store issues and coordinate a response. The Store Performance page displays a Power BI report, with other business experiences available through the org app navigation. Start with the insight A regional manager opens the Retail Operations Hub, an app designed around the work of running stores. The landing experience surfaces a Power BI report with revenue, margin, inventory, and customer-service trends. A real-time dashboard highlights emerging operational issues. Action Planner opens as a dedicated Fabric App page within the Retail Operations Hub. Continue into a Fabric App The report shows that a store is missing its sales target while carrying excess inventory. The manager opens the Store Action Planner, a Fabric App included in the same org app. The application brings the relevant context into a focused workflow where the manager can review the exception, choose a response, assign owners, and track the plan. Keep reporting and actions connected The org app keeps the solution together while tailoring content for regional and store managers. Business owners can update navigation and included items without rebuilding the Fabric App. Each team retains clear ownership: BI authors evolve reports, developers improve the Fabric App, and business owners curate the org app. Benefits One place to work: Move from Power BI insight to action without finding another tool. Role-based distribution: Give each audience the right mix of reports, applications, and operational content. Clear ownership: Let BI authors, developers, and business owners evolve their parts independently within one consistent destination. Business context: Organize navigation and branding around the process, not the underlying technology or workspace. Get started Build the tailored experience with Fabric Apps, then use the org app guidance to package it with Power BI reports and other supported Fabric content. Build the experience users need with Fabric Apps. Distribute it in the context of their work with org apps.A Leader in Data Integration—six years running
Microsoft is a Leader in the 2026 Gartner® Magic Quadrant™ for Data Integration Tools For the sixth consecutive year, Microsoft has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Data Integration Tools—and this year, the story isn't just about unifying data, it's about what customers are building on it. In our view, it reflects how far Microsoft Fabric has come—from a unified platform to an open, AI-ready foundation that connects data across clouds, formats, and partners. Gartner evaluates vendors on two critical dimensions: Completeness of Vision and Ability to Execute. Microsoft offers Microsoft Fabric, Azure Data Factory, SQL Server Data Integration Services (SSIS), Power Query, and Azure Synapse Analytics as its data integration tools. The report noted Microsoft’s global reach, industry diversity and our ongoing investment in innovative data integration capabilities. The MQ measures both the strength of the vision as well as ability to execute. The 2026 iteration firmly places Microsoft as a leader. We agree with Gartner’s perspective that our success hinges on delivering seamless integration across Microsoft’s Data Integration portfolio, unifying experiences across data sources, and building a strong, engaged community that drives adoption and advocacy. The report also observed that with a broad global presence serving customers across industries, we continue to invest in advancing Fabric’s data integration capabilities, including real-time data, AI enablement, and data governance, helping organizations unlock greater value from their data. Our key strengths Unified vision for data management: Microsoft Fabric brings together data integration and data management in a unified platform, empowering both technical and business users to build, manage, and deliver end-to-end data pipelines. This includes support for diverse data integration scenarios and AI-driven workloads, simplifying how organizations turn data into value. Open ecosystem and interoperability: We continue to expand Fabric’s interoperability capabilities, making it easier for customers to connect, integrate, and work with data wherever it lives. From expanding Mirroring and OneLake shortcuts to integrating with Apache Spark and Apache Airflow, and partnering with dbt for native transformations, we are committed to providing customers with flexibility and choice. Thriving community and partner ecosystem: Our growing global partner ecosystem and Fabric community are critical to accelerating customer success. Through investments in partner enablement, systems integrator expertise, and global events and conferences, we are expanding access to the skills, resources, and support customers need to realize the full potential of Microsoft’s Data Integration portfolio. In addition, with the breadth and depth of today’s data estate, governance is critical. Capabilities like data lineage, policy enforcements, observability and monitoring give customers the confidence to deploy widely while having the insights they need to monitor, control and optimize. Additionally, the ever-growing range of data sources available with mirroring and shortcuts enable customers to harmonize their multi-cloud and hybrid data estates in OneLake to enable our customers’ frontier transformation ambitions. We believe the entirety of these product truths reflect the priorities our customers have asked for: one platform for every data professional, openness across clouds and formats, deep insights to govern effectively and a thriving ecosystem to help them succeed. Microsoft Fabric: your unified, AI-powered data estate At the core of our data integration strategy is Microsoft Fabric, a unified, AI-powered data and analytics platform designed to simplify the complexities of modern data ecosystems. Now with over 44,000 customers, Fabric delivers an all-in-one, software-as-a-service (SaaS) experience that spans data ingestion, engineering, science, real-time intelligence, and visualization—all built on Microsoft OneLake, a single, unified data lake for your entire organization. With OneLake, you load your data once and use that single copy across every Fabric workload and engine, eliminating duplication and reducing complexity. Built on open standards such as Delta Lake and Apache Iceberg, OneLake lets Delta tables be accessed as Iceberg without data movement or conversion, while the OneLake catalog provides a central hub for data discovery, governance, and collaboration. Many ways to bring data into OneLake Fabric Data Factory Fabric Data Factory integrates seamlessly with OneLake, offering cloud-scale services for data movement, orchestration, transformation, deployment, and monitoring. With native dbt support and Apache Airflow integration, data teams can use the tools they already know to tackle even the most complex ETL scenarios. Customers with existing SSIS investments can retain those workloads while modernizing with Fabric, and the on-premises data gateway connects Fabric to data behind private networks. Shortcuts and mirroring Shortcuts and mirroring offer a zero-copy, zero-ETL approach to bringing data into OneLake. Shortcuts virtualize data from across clouds—including Amazon S3 and Google Cloud Storage—directly into OneLake, enabling near real-time analysis through live connections to the source. Mirroring replicates operational databases and data warehouses, including Google BigQuery, into the lake, keeping data synchronized and ready for analytics. Partnerships with Snowflake, Databricks, and SAP extend bidirectional data sharing even further. Real-Time Intelligence Fabric Real-Time Intelligence empowers organizations to ingest and process streaming and high-granularity data instantly, driving real-time insights and automated decision-making for scenarios such as IoT analytics, fraud detection, and operational dashboards. Whether through batch processing, incremental updates, or real-time streaming, Fabric gives organizations a secure, scalable foundation for every data integration pattern—across cloud, multicloud, and hybrid environments. Customer success Real customer experiences show how Microsoft Fabric is making a measurable difference. Organizations like IWG, Mercedes Benz, Mediterranean Shipping Company, LSEG, and EY have adopted Microsoft Fabric to build the robust data foundation required for AI. At IWG, shortcuts in OneLake replaced costly pipelines and data movement, helping cut report generation time by 90% and giving 2,000 users access to data insights. "Microsoft Fabric was a game changer because of its ability to create shortcuts without physically moving data from one place to another. Before, if I had to incorporate three sources, I had to create pipelines to bring in the data. That pipeline had a cost. The data movement had a cost. With Fabric, it's two clicks and that's it." — José Viegas, Senior Data Architect, IWG Looking ahead Six years in, the conversation has shifted from bringing data together to putting it to work. This year's recognition we feel reflects that shift: an open platform that meets data wherever it lives, a growing community of partners and experts, and customers like IWG turning faster access to data into real business results. We're grateful to the customers, partners, and Fabric community who help shape what we build. Learn more Explore the complimentary Gartner report: 2026 Magic Quadrant for Data Integration Tools Learn more about Data Factory in Microsoft Fabric Learn more about Microsoft OneLake. Get started with Microsoft Fabric Gartner, Magic Quadrant for Data Integration Tools, [By Thornton Craig, Robert Thanaraj, Sharat Menon, Jenna Goodrich, Nina Showell , 2 November 2026 . Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose. Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Microsoft.
My workspace governance improvements (Generally Available)
My workspace governance features, which give administrators governance controls over their users' personal My workspaces, are now generally available. As My workspaces continue to be used for business-critical content, organizations need governance capabilities that scale with their environment. These enhancements give administrators greater flexibility to access, manage, and recover content when needed, while enabling automation that reduces operational overhead and improves consistency across the tenant. These enhanced tenant administrator controls for My workspace are also available in government clouds. What's new Two new admin REST APIs make temporary admin access to a personal workspace fully programmable: Grant Admin Temporary Access: grants a Fabric administrator 24-hour access to a user's My workspace. Remove Admin Temporary Access: revokes that access before the 24-hour window ends. Both can be called by a Fabric administrator or by a service principal. The service principal identity must be enabled for Admin API access in your tenant settings. SPN support and these new APIs allow tenant administrators to automate management of tenant users’ My workspaces contents instead of doing it by hand in the Admin Portal. Reminder: Restoring orphaned My workspaces When a user is hard deleted in Microsoft Entra, their My workspace becomes orphaned and moves to a Deleted state, with contents retained for 30 days. During that window, you can restore it with the Restore Workspace API. Important: new workspace name is required when restoring a former My workspace, and you assign a new admin to own the recovered content. Try the Admin controls and new APIs and let us know what you think in the comment section.NDAC Global Fabric Data Days DP-700: Fabric Data Engineer Associate
NDAC Global Fabric Data Days DP-700: Fabric Data Engineer Associate Excited to invite you to a power-packed learning event designed for Microsoft Fabric enthusiasts, data professionals, and DP-600 certification aspirants! Date: 28 Nov 2026 (Saturday) Time: 09:00 AM – 01:00 PM IST Mode: Online Session Line-up Session 01 | 09:00 AM – 10:00 AM IST Implement and Manage Analytics Solutions Ritesh K (Lead Fabric Data Engineer) Session 02 | 10:00 AM – 11:00 AM IST Ingest and Transform Data Inturi Suparna Babu (Fabric Super User) Session 03 | 11:00 AM – 12:00 PM IST Monitor and Optimize Microsoft Fabric Solutions Rajendra Ongole (Microsoft MVP) Session 04 | 12:00 PM – 01:00 PM IST Prepare for exam day and open Q&A Krishnkanth T (Fabric Super User) 𝐑𝐞𝐠𝐢𝐬𝐭𝐞𝐫 𝐍𝐨𝐰: • Meetup: https://www.meetup.com/nextgen-data-aspirants-community/events/317341542/?utm_medium=referral&utm_campaign=share-btn_savedevents_share_modal&utm_source=link&utm_version=v2&member_id=471647775 • YoutTube Live: https://www.youtube.com/watch?v=vYBfDGYAz5EFind expensive queries from Capacity Metrics (Generally Available)
When warehouse capacity usage spikes, you need to quickly understand what ran, which warehouse drove the usage, and which queries require investigation. The Monitor in warehouse action in the Microsoft Fabric Capacity Metrics app connects the capacity-level view directly to Warehouse Monitor. It opens the selected warehouse with the relevant time window already applied, eliminating manual correlation across monitoring experiences. Follow the activity into your warehouse Open Capacity Metrics: From the Compute page, select your capacity and review CU % over time. Capacity Units, or CUs, represent the compute consumption tracked for the capacity. Choose a timepoint: Select the usage increase you want to investigate, and then select Explore and open TimePoint Detail. Choose an operation window: Under Background operations for time range, select a supported warehouse query operation whose Start and End times cover the interval. Then select Monitor in warehouse. Explore Warehouse Monitor: Open Query history to review statements that ran during the selected interval. Access required: Access to the Capacity Metrics app and the Admin role in the workspace containing the warehouse. For supported operations and navigation, refer to the Monitor in warehouse documentation. Find the queries worth investigating Start with CPU time. Add the column through Column options and sort from highest to lowest. CPU time is the processor time allocated to an execution. It is not elapsed duration or the Capacity Units billed for an individual query. No single metric explains the complete workload. Review these columns together: Data scanned: Identify statements that read large volumes of data. Compare OneLake reads with local disk, and memory reads to understand caching behavior. Result cache hit: A value of 2 means the query reused a cached result, 1 means the execution created a result set cache, and 0 means result caching did not apply. Query text: Review joins, predicates, and filters for unnecessary scans or processing. Label: Connect statements to a workload, business process, or test variation. Is distributed: Separate distributed executions, represented by 1, from nondistributed requests, represented by 0. For queries with high CPU time or data scanned, select View similar runs to determine whether the behavior is recurring or isolated. Add Query Insights fields such as application, SQL pool, status, and error code to identify the originating workload and distinguish expensive successful executions from failed or interrupted ones. For field definitions, refer to the query execution history column reference documentation. Make the same correlation with AI The Data Warehouse operations skill in Skills for Fabric can correlate Capacity Metrics data with Query Insights activity for the same warehouse and time window, using your existing permissions. Example prompt: Investigate the capacity spike for my warehouse from 14:00 to 15:00 UTC on November 3, 2026. Identify queries with high CPU time or data scanned, explain why each query stands out, and suggest the next investigation step. Review the supporting metrics and query details before making tuning or workload-management decisions. Next steps Try Monitor in warehouse the next time you see a capacity usage increase. Start with CPU time and data scanned, compare similar runs, and use workload metadata to determine what drove the activity. For more guidance, refer to the Warehouse performance guidelines, query blocking troubleshooting, and Monitor T-SQL queries documentation.Join us at FABCON + SQLCON 2027 in Atlanta and save
Planning to join us at FABCON + SQLCON 2027? Register by November 13 to save $300 with early-access pricing, and use code MSCMTY to save an additional $200. Plus, a limited number of buy one, get one (BOGO) offers are available. Ask your account team or Fabric partner to find out how to get one. From March 8–12, 2027, FABCON + SQLCON brings the Microsoft data community together in Atlanta for five days of learning, connection, and hands-on experiences. Two conferences. One registration. FABCON + SQLCON brings together Microsoft Fabric, SQL, and Azure AI in one event. You can mix and match sessions and workshops across both conferences based on the topics most relevant to you. Whether you're exploring Microsoft Fabric, already scaling it in production, building with SQL, or looking at how AI is changing the data landscape, you'll have opportunities to: Hear directly from Microsoft and community experts. Explore expert-led sessions across Fabric, SQL, AI, analytics, data engineering, governance, Power BI, and more. Build practical skills through hands-on workshops. Learn from real-world customer experiences and implementation patterns. Connect with peers, Microsoft product experts, partners, and the broader data community. Register by November 13 to save Take advantage of early-access pricing before it ends: Save $300 by registering by November 13. Save an additional $200 with discount code MSCMTY. Ask your account team or Fabric partner about a limited number of available BOGO offers. FABCON + SQLCON 2027 March 8–12, 2027 Atlanta, Georgia Register today and start planning your FABCON + SQLCON 2027 experience.
