Azure AI Foundry vs. Azure Databricks – A Unified Approach to Enterprise Intelligence
Key Insights into Azure AI Foundry and Azure Databricks Complementary Powerhouses: Azure AI Foundry is purpose-built for generative AI application and agent development, focusing on model orchestration and rapid prototyping, while Azure Databricks excels in large-scale data engineering, analytics, and traditional machine learning, forming the data intelligence backbone. Seamless Integration for End-to-End AI: A critical native connector allows AI agents developed in Foundry to access real-time, governed data from Databricks, enabling contextual and data-grounded AI solutions. This integration facilitates a comprehensive AI lifecycle from data preparation to intelligent application deployment. Specialized Roles for Optimal Performance: Enterprises leverage Databricks for its robust data processing, lakehouse architecture, and ML model training capabilities, and then utilize AI Foundry for deploying sophisticated generative AI applications, agents, and managing their lifecycle, ensuring responsible AI practices and scalability. In the rapidly evolving landscape of artificial intelligence, organizations seek robust platforms that can not only handle vast amounts of data but also enable the creation and deployment of intelligent applications. Microsoft Azure offers two powerful, yet distinct, services in this domain: Azure AI Foundry and Azure Databricks. While both contribute to an organization's AI capabilities, they serve different primary functions and are designed to complement each other in building comprehensive, enterprise-grade AI solutions. Decoding the Core Purpose: Foundry for Generative AI, Databricks for Data Intelligence At its heart, the distinction between Azure AI Foundry and Azure Databricks lies in their core objectives and the types of workloads they are optimized for. Understanding these fundamental differences is crucial for strategic deployment and maximizing their combined potential. Azure AI Foundry: The Epicenter for Generative AI and Agents Azure AI Foundry emerges as Microsoft's unified platform specifically engineered for the development, deployment, and management of generative AI applications and AI agents. It represents a consolidation of capabilities from what were formerly Azure AI Studio and Azure OpenAI Studio. Its primary focus is on accelerating the entire lifecycle of generative AI, from initial prototyping to large-scale production deployments. Key Characteristics of Azure AI Foundry: Generative AI Focus: Foundry streamlines the development of large language models (LLMs) and customized generative AI applications, including chatbots and conversational AI. It emphasizes prompt engineering, Retrieval-Augmented Generation (RAG), and agent orchestration. Extensive Model Catalog: It provides access to a vast catalog of over 11,000 foundation models from various publishers, including OpenAI, Meta (Llama 4), Mistral, and others. These models can be deployed via managed compute or serverless API deployments, offering flexibility and choice. Agentic Development: A significant strength of Foundry is its support for building sophisticated AI agents. This includes tools for grounding agents with knowledge, tool calling, comprehensive evaluations, tracing, monitoring, and guardrails to ensure responsible AI practices. Foundry Local further extends this by allowing offline and on-device development. Unified Development Environment: It offers a single management grouping for agents, models, and tools, promoting efficient development and consistent governance across AI projects. Enterprise Readiness: Built-in capabilities such as Role-Based Access Control (RBAC), observability, content safety, and project isolation ensure that AI applications are secure, compliant, and scalable for enterprise use. Figure 1: Conceptual Architecture of Azure AI Foundry illustrating its various components for AI development and deployment. Azure Databricks: The Powerhouse for Data Engineering, Analytics, and Machine Learning Azure Databricks, on the other hand, is an Apache Spark-based data intelligence platform optimized for large-scale data engineering, analytics, and traditional machine learning workloads. It acts as a collaborative workspace for data scientists, data engineers, and ML engineers to process, analyze, and transform massive datasets, and to build and deploy diverse ML models. Key Characteristics of Azure Databricks: Unified Data Analytics Platform: Central to Databricks is its lakehouse architecture, built on Delta Lake, which unifies data warehousing and data lakes. This provides a single platform for data engineering, SQL analytics, and machine learning. Big Data Processing: Excelling in distributed computing, Databricks is ideal for processing large datasets, performing ETL (Extract, Transform, Load) operations, and real-time analytics at scale. Comprehensive ML and AI Workflows: It offers a specialized environment for the full ML lifecycle, including data preparation, feature engineering, model training (both classic and deep learning), and model serving. Tools like MLflow are integrated for tracking, evaluating, and monitoring ML models. Data Intelligence Features: Databricks includes AI-assistive features such as Databricks Assistant and Databricks AI/BI Genie, which enable users to interact with their data using natural language queries to derive insights. Unified Governance with Unity Catalog: Unity Catalog provides a centralized governance solution for all data and AI assets within the lakehouse, ensuring data security, lineage tracking, and access control. Figure 2: The Databricks Data Intelligence Platform with its unified approach to data, analytics, and AI. The Symbiotic Relationship: Integration and Complementary Use Cases While distinct in their primary functions, Azure AI Foundry and Azure Databricks are explicitly designed to work together, forming a powerful, integrated ecosystem for end-to-end AI development and deployment. This synergy is key to building advanced, data-driven AI solutions in the enterprise. Seamless Integration for Enhanced AI Capabilities The integration between the two platforms is a cornerstone of Microsoft's AI strategy, enabling AI agents and generative applications to be grounded in high-quality, governed enterprise data. Key Integration Points: Native Databricks Connector in AI Foundry: A significant development in 2025 is the public preview of a native connector that allows AI agents built in Azure AI Foundry to directly query real-time, governed data from Azure Databricks. This means Foundry agents can leverage Databricks AI/BI Genie to surface data insights and even trigger Databricks Jobs, providing highly contextual and domain-aware responses. Data Grounding for AI Agents: This integration enables AI agents to access structured and unstructured data processed and stored in Databricks, providing the necessary context and knowledge base for more accurate and relevant generative AI outputs. All interactions are auditable within Databricks, maintaining governance and security. Model Crossover and Availability: Foundation models, such as the Llama 4 family, are made available across both platforms. Databricks DBRX models can also appear in the Foundry model catalog, allowing flexibility in where models are trained, deployed, and consumed. Unified Identity and Governance: Both platforms leverage Azure Entra ID for authentication and access control, and Unity Catalog provides unified governance for data and AI assets managed by Databricks, which can then be respected by Foundry agents. Here's a breakdown of how a typical flow might look: Mindmap 1: Illustrates the complementary roles and integration points between Azure Databricks and Azure AI Foundry within an end-to-end AI solution. When to Use Which (and When to Use Both) Choosing between Azure AI Foundry and Azure Databricks, or deciding when to combine them, depends on the specific requirements of your AI project: Choose Azure AI Foundry When You Need To: Build and deploy production-grade generative AI applications and multi-agent systems. Access, evaluate, and benchmark a wide array of foundation models from various providers. Develop AI agents with sophisticated capabilities like tool calling, RAG, and contextual understanding. Implement enterprise-grade guardrails, tracing, monitoring, and content safety for AI applications. Rapidly prototype and iterate on generative AI solutions, including chatbots and copilots. Integrate AI agents deeply with Microsoft 365 and Copilot Studio. Choose Azure Databricks When You Need To: Perform large-scale data engineering, ETL, and data warehousing on a unified lakehouse. Build and train traditional machine learning models (supervised, unsupervised learning, deep learning) at scale. Manage and govern all data and AI assets centrally with Unity Catalog, ensuring data quality and lineage. Conduct complex data analytics, business intelligence (BI), and real-time data processing. Leverage AI-assistive tools like Databricks AI/BI Genie for natural language interaction with data. Require high-performance compute and auto-scaling for data-intensive workloads. Use Both for Comprehensive AI Solutions: The most powerful approach for many enterprises is to leverage both platforms. Azure Databricks can serve as the robust data backbone, handling data ingestion, processing, governance, and traditional ML model training. Azure AI Foundry then sits atop this foundation, consuming the prepared and governed data to build, deploy, and manage intelligent generative AI agents and applications. This allows for: Domain-Aware AI: Foundry agents are grounded in enterprise-specific data from Databricks, leading to more accurate, relevant, and trustworthy AI responses. End-to-End AI Lifecycle: Databricks manages the "data intelligence" part, and Foundry handles the "generative AI application" part, covering the entire spectrum from raw data to intelligent user experience. Optimized Resource Utilization: Each platform focuses on what it does best, leading to more efficient resource allocation and specialized toolsets for different stages of the AI journey. Comparative Analysis: Features and Capabilities To further illustrate their distinct yet complementary nature, let's examine a detailed comparison of their features, capabilities, and typical user bases. Radar Chart 1: This chart visually compares Azure AI Foundry and Azure Databricks across several key dimensions, illustrating their specialized strengths. Azure AI Foundry excels in generative AI and agent orchestration, while Azure Databricks dominates in data engineering, unified data governance, and traditional ML workflows. A Detailed Feature Comparison Feature Category Azure AI Foundry Azure Databricks Primary Focus Generative AI application & agent development, model orchestration Large-scale data engineering, analytics, traditional ML, and AI workflows Data Handling Connects to diverse data sources (e.g., Databricks, Azure AI Search) for grounding AI agents. Not a primary data storage/processing platform. Native data lakehouse architecture (Delta Lake), optimized for big data processing, storage, and real-time analytics. AI/ML Capabilities Foundation models (LLMs), prompt engineering, RAG, agent orchestration, model evaluation, content safety, responsible AI tooling. Traditional ML (supervised/unsupervised), deep learning, feature engineering, MLflow for lifecycle management, Databricks AI/BI Genie. Development Style Low-code agent building, prompt flows, unified SDK/API, templates. Code-first (Python, SQL, Scala, R), notebooks, IDE integrations. Model Access & Deployment Extensive model catalog (11,000+ models), serverless API, managed compute deployments, model benchmarking. Training and serving custom ML models, including deep learning. Models available for deployment through MLflow. Governance & Security Azure-based security & compliance, RBAC, project isolation, content safety guardrails, tracing, evaluations. Unity Catalog for unified data & AI governance, lineage tracking, access control, Entra ID integration. Key Users AI developers, business analysts, citizen developers, AI app builders. Data scientists, data engineers, ML engineers, data analysts. Integration Points Native connector to Databricks AI/BI Genie, Azure AI Search, Microsoft 365, Copilot Studio, Power Platform. Microsoft Fabric, Power BI, Azure AI Foundry, Azure Purview, Azure Monitor, Azure Key Vault. Table 1: A comparative overview of the distinct features and functionalities of Azure AI Foundry and Azure Databricks Concluding Thoughts In essence, Azure AI Foundry and Azure Databricks are not competing platforms but rather essential components of a unified, comprehensive AI strategy within the Azure ecosystem. Azure Databricks provides the robust, scalable foundation for all data engineering, analytics, and traditional machine learning workloads, acting as the "data intelligence platform." Azure AI Foundry then leverages this foundation to specialize in the rapid development, deployment, and operationalization of generative AI applications and intelligent agents. Together, they enable enterprises to unlock the full potential of AI, transforming raw data into powerful, domain-aware, and governed intelligent solutions. Frequently Asked Questions (FAQ) What is the main difference between Azure AI Foundry and Azure Databricks? Azure AI Foundry is specialized for building, deploying, and managing generative AI applications and AI agents, focusing on model orchestration and prompt engineering. Azure Databricks is a data intelligence platform for large-scale data engineering, analytics, and traditional machine learning, built on a Lakehouse architecture. Can Azure AI Foundry and Azure Databricks be used together? Yes, they are designed to work synergistically. Azure AI Foundry can leverage a native connector to access real-time, governed data from Azure Databricks, allowing AI agents to be grounded in enterprise data for more accurate and contextual responses. Which platform should I choose for training large machine learning models? For training large-scale, traditional machine learning, and deep learning models, Azure Databricks is generally the preferred choice due to its robust capabilities for data processing, feature engineering, and ML lifecycle management (MLflow). Azure AI Foundry focuses more on the deployment and orchestration of pre-trained foundation models and generative AI applications. Does Azure AI Foundry replace Azure Machine Learning or Databricks? No, Azure AI Foundry complements these services. It provides a specialized environment for generative AI and agent development, often integrating with data and models managed by Azure Databricks or Azure Machine Learning for comprehensive AI solutions. How do these platforms handle data governance? Azure Databricks utilizes Unity Catalog for unified data and AI governance, providing centralized control over data access and lineage. Azure AI Foundry integrates with Azure-based security and compliance features, ensuring responsible AI practices and data privacy within its generative AI applications.Migrating Azure Data Factory and Synapse Pipelines to Fabric Data Factory
Migrating data pipelines from Azure Data Factory (ADF) and Azure Synapse Pipelines to Microsoft Fabric Data Factory represents a significant modernization opportunity and a catalyst for accelerating AI innovation across the enterprise. With Fabric Data Factory, customers can unify their data estate, streamline data engineering workflows, and more effectively leverage real-time analytics, generative AI, and machine learning at scale. This article outlines the key technical considerations for a successful migration from ADF/Synapse pipelines to Fabric Data Factory. Fabric Data Factory vs. ADF and Synapse Pipelines: What’s Different? Fabric Data Factory is officially described by Microsoft as the next generation of Azure Data Factory, built to handle your most complex data integration challenges with a simpler, more powerful approach. It retains ADF’s core engine capabilities while introducing major improvements enabled by Fabric’s unified, AI-centric platform including OneLake, expanded activities and native Copilot experiences. A fundamental shift is the move to a fully managed SaaS model, with several important differences: No infrastructure management: Fabric eliminates Azure Integration Runtimes entirely. Compute is managed automatically within a Fabric capacity. For on‑premises connectivity, the On‑Premises Data Gateway (OPDG) replaces ADF’s Self‑Hosted Integration Runtime. No publish step: Pipelines are authored directly in the Fabric portal and can be saved or executed immediately, removing the separate publish step required in ADF. Simplified data connections: Traditional Linked Services and Datasets are replaced by Connections and inline data properties within activities, reducing configuration complexity. New native activities: Fabric introduces capabilities not available in ADF/Synapse pipelines, including Office 365 Outlook email, Teams messaging, semantic model refresh, Fabric notebooks, Invoke SSIS (preview), and Lakehouse maintenance (preview). Enhanced CI/CD: Built‑in deployment pipelines support cherry‑picking, individual item promotion, Git integration, and SaaS‑native CI/CD beyond ADF’s ARM template–based approach. AI Copilot: Fabric Data Factory includes Copilot to assist with pipeline creation and management, a capability not available in ADF or Synapse pipelines. For more details see: Differences between Data Factory in Fabric and Azure - Microsoft Fabric | Microsoft Learn Common Migration Challenges and Recommended Mitigations Migrating to Fabric Data Factory introduces new choices and challenges. While the move to Fabric offers substantial benefits, success depends on understanding key differences, migration challenges and planning accordingly. The table below summarizes the most important considerations to help guide a smooth and successful transition. Table 1. Migration Challenges and Mitigation Challenge Description Recommended Mitigation Feature Gaps Some ADF/Synapse features (e.g., SSIS IR, Managed VNets, certain triggers) are not yet fully supported in Fabric. Delay migration of affected pipelines or redesign using Fabric‑native alternatives. Monitor updates via the https://roadmap.fabric.microsoft.com Mapping Data Flows ADF Mapping Data Flows don’t directly map to Fabric equivalents. Rebuild using Dataflow Gen2, Fabric Warehouse SQL, or Spark notebooks. Validate transformation logic and data types post‑migration. Trigger Redesign Fabric lacks centralized trigger management; scheduling must be defined at the pipeline level. Recreate triggers per pipeline and apply standardized naming conventions and documentation to maintain operational clarity. Global Parameters ADF Global Parameters must be converted to Fabric Variable Libraries. Use Microsoft’s conversion guidance and account for differences in data types and runtime usage patterns. See Convert Azure Data Factory Global Parameters to Fabric Variable Libraries. Dynamic Connections Fabric does not support dynamic linked service properties in the same way as ADF. Parameterize connection objects within pipeline activities using dynamic content. Deployment Performance Some environments report slower execution of deployment pipelines in Fabric. Break deployments into smaller logical units and validate performance during pilot phases prior to production rollout. Capacity Planning Fabric uses a fixed‑capacity compute model instead of ADF’s elastic pay‑as‑you‑go runtime. Right‑size Fabric capacity based on peak load testing and continuously monitor usage with tools such as the Fabric Capacity Estimator. Migration Tooling Migration Assistant: Microsoft Fabric includes a built‑in Migration Assistant for both ADF and Synapse pipelines, designed specifically to support pipeline migrations. To assess migration readiness, open your ADF/Synapse pipeline instance, go to the authoring canvas, and select Migrate to Fabric (Preview) > Get started (Preview). As shown in the assessment summary below, pipelines are grouped into migration readiness categories such as Ready, Needs Review, Coming Soon, and Unsupported. This classification gives engineering teams early visibility into potential migration risks by highlighting activities or configurations that may behave differently in Fabric and require validation or adjustment after migration (Needs review), features that are not currently supported in Fabric but are planned for future availability (Coming soon), or not available in Fabric and will require redesign or re‑implementation (Unsupported). In enterprise environments with large pipeline estates, this insight is critical for avoiding unexpected failures or delays during migration. After completing the assessment, you can proceed with the migration wizard and mount your ADF pipelines into Microsoft Fabric. Mounting does not migrate your ADF pipelines to Fabric Data Factory at this stage. Instead, it creates a reference to your existing instances within the Fabric workspace without consuming Fabric capacity. After mounting, run pipelines side by side to validate behavior and results. Once the side by side has been validated, select Migrate to Fabric button to proceed with connection mapping and the actual migration to Fabric Data Factory. After completing the migration process, you will be presented with the Migration Results page. This view provides a summary of all selected pipeline resources along with their migration status and corresponding Fabric resource names. Successfully migrated pipelines are now available as Fabric‑native items within the workspace, while any errors or unmapped dependencies are flagged for further review. For Synapse Analytics pipelines, you transition directly into the Fabric Data Factory experience (assess->map->migrate flow) rather than mounting first to reference Synapse pipelines externally. For detailed migration steps, follow this link: Assess your Azure Data Factory and Synapse pipelines for migration to Fabric - Azure Data Factory | Microsoft Learn PowerShell automation tool: Microsoft provides a PowerShell upgrade utility to accelerate migration from Azure Data Factory to Fabric Data Factory. Using the Microsoft.FabricPipelineUpgrade module, you can translate a large subset of ADF pipeline JSON into Fabric‑native definitions, giving you a fast, scalable starting point for migration. The tool covers common patterns such as Copy, Lookup, Stored Procedure, and standard control flow. Manual follow‑up is still required for edge cases (custom connectors, complex expressions, and some data flow scenarios). Import-AdfFactory -SubscriptionId <your Subscription ID> -ResourceGroupName <your Resource Group Name> -FactoryName <your Data Factory Name> -PipelineName "pipeline1" -AdfToken $adfSecureToken | ConvertTo-FabricResources | Export-FabricResources -Region <region> -Workspace <workspaceId> -Token $fabricSecureToken For step‑by‑step guidance, see: Detailed Tutorial for PowerShell-based Migration of Azure Data Factory Pipelines to Fabric - Microsoft Fabric | Microsoft Learn Open‑Source Migration Tooling In addition to Microsoft‑supported migration utilities, the Fabric Toolbox provides a set of open‑source tools designed to assist with migration planning, readiness analysis, and pipeline translation from ADF and Synapse to Fabric Data Factory. Fabric Data Factory Migration Assistant PowerShell: An open‑source tool from the Fabric Toolbox that supports migration from both Azure Data Factory and Synapse ARM templates and built as a browser‑based single‑page application (SPA). https://github.com/microsoft/fabric-toolbox/tree/main/tools/FabricDataFactoryMigrationAssistant Fabric Assessment Tool: An open‑source command‑line utility used to connect to and scan workspaces in order to extract inventory data and assess migration scope by creating a structured export of assets for planning and analysis. https://github.com/microsoft/fabric-toolbox/tree/main/tools/fabric-assessment-tool When to Use What? Organizations typically adopt one of three migration strategies when transitioning ADF or Synapse pipelines to Fabric Data Factory: Lift‑and‑Shift to accelerate transition timelines with minimal pipeline refactoring. Modernization to re‑architect orchestration logic and fully leverage Fabric‑native analytics and AI capabilities. Hybrid to balance migration velocity with targeted modernization of high‑value or low‑parity workloads. The appropriate migration paths should be aligned with business priorities, existing integration patterns, and the desired pace of platform transformation, and is largely determined by the feature parity between existing ADF/Synapse assets and their Fabric Data Factory equivalents. A range of migration tooling options are available depending on migration scope and pipeline complexity: Built-In Fabric UI Assistant – Migrate to Fabric: Use this assistant to assess pipeline readiness across both ADF and Synapse environments, mount existing ADF pipelines into a Fabric workspace, perform side‑by‑side validation, or migrate supported Synapse pipelines directly into Fabric Data Factory experience. PowerShell Upgrade Tool (Microsoft‑supported): Use this for bulk ADF migrations at scale, repeatable upgrades, and CI/CD‑driven pipeline conversion with a supported path. Fabric Data Factory Migration Assistant PowerShell (Open Source): Use for early analysis, connector mapping, and generating a migration starting point outside the Fabric UI. Fabric Assessment Tool (Open Source): Use before migration to understand scope, inventory, dependencies, and readiness across your Fabric and data estate. Manual migration: best suited for complex, low‑parity pipelines and provides an opportunity to modernize architecture using Fabric’s native capabilities, delivering long‑term benefits in maintainability, performance, and cost. Key Considerations for a Smooth Transition Before migrating, it’s important to understand the architectural differences between Azure Data Factory or Synapse pipelines and Fabric Data Factory. Reviewing these differences early helps determine which pipeline components can be reused, translated, or redesigned for Fabric‑native execution. Start by prioritizing low‑risk, high‑parity pipelines that can be migrated with minimal redesign. Mounting existing ADF pipelines into Fabric enables gradual migration and side‑by‑side testing, allowing teams to validate compatibility before using conversion tools or replatforming workloads. For larger environments, the Microsoft.FabricPipelineUpgrade PowerShell module or Open-Source tools can be used to migrate pipelines at scale while mapping linked services to Fabric connections. Where possible, leverage Fabric‑native capabilities such as Copilot for pipeline authoring, and code fix, deployment pipelines for CI/CD, and OneLake shortcuts to access external data without duplication. It’s also recommended to validate migrated pipelines under production‑like workloads to confirm performance and reliability before cutover. For complex or large‑scale enterprise migrations, engaging Microsoft partners can help accelerate modernization efforts while minimizing operational risk. Partners | Microsoft Fabric For detailed best practices guidance, refer to: Migration Best Practices for Azure Data Factory to Fabric Data Factory - Microsoft Fabric | Microsoft Learn Summary Migrating from Azure Data Factory or Synapse pipelines to Microsoft Fabric Data Factory represents a key step toward building a unified, AI‑ready analytics platform. By leveraging the built‑in migration assessment and associated tooling, organizations can perform pipeline‑level compatibility analysis, identify unsupported activities or configuration dependencies, and implement a phased modernization strategy aligned with workload readiness. Successful transitions require a clear understanding of the architectural shift from ADF/Synapse’s PaaS to Fabric’s SaaS‑managed model, where compute is fully managed within the Fabric capacity, traditional Integration Runtimes are no longer required, and datasets and linked services are replaced with connection‑based configurations defined inline within pipeline activities. By adopting Fabric‑native capabilities such as deployment pipelines for CI/CD, Copilot‑assisted pipeline authoring, and OneLake, organizations can standardize pipeline lifecycle management, enable governed access to shared data assets across domains, and support multi‑cloud integration through virtualized data access allowing pipelines to operate on distributed datasets without duplicating or relocating data across Lakehouse, Data Warehouse, and Real‑Time Analytics workloads within a unified Fabric workspace.This Week on the Fabric Engineering Connection
After a two‑week pause for FABCON & SQLCON - The Microsoft Fabric & SQL Community Conferences, we’re excited to welcome partners back for our first Fabric Engineering Connection call since the conference. Welcome back—and what a great way to restart the conversation! 🙌 This week’s sessions bring partners closer to the people building Microsoft Fabric, with timely insights and takeaways straight from FabCon. 🎙 What’s on the agenda: Fabric AI‑Powered Automation for Pro‑Developers (Americas & EMEA) presented by Evelina Alroy-Brin and Hasan Abo-Shally Recap of Data Warehouse announcements from FabCon presented by Rakesh Krishnan and Tino Tereshko 🇺🇦 🌍 Session times: Americas & EMEA: Wednesday, March 25 | 8–9 AM PT APAC: Thursday, March 26 | 1–2 AM UTC / Wednesday, March 25 | 5–6 PM PT These calls are a great opportunity to reconnect after FabCon, hear directly from engineering, and dig deeper into what’s new—and what’s next—for Microsoft Fabric. 👉 Participation is open to members of the Fabric Partner Community. Join here: https://aka.ms/JoinFabricPartnerCommunity🚨 Partner‑Exclusive Event: AMA with Fabric Leadership
We’re excited to invite Fabric Partner Community members to a live Ask Me Anything (AMA) with Fabric leadership—a rare opportunity to get direct answers and insights from the team shaping Azure Data and Microsoft Fabric. Featured Guest Shireesh Thota CVP, Azure Data Databases Tuesday, March 24 8:00–9:00 AM PT With FabCon + SQLCon wrapping just days before, this session is designed for partners who want to go deeper—ask follow‑up questions, pressure‑test ideas, and understand what’s next as they plan with customers. Topics may include: What’s next for Azure SQL, Cosmos DB, and PostgreSQL Guidance on SQL Server roadmap direction Deep‑dive questions on SQL DB in Fabric Questions about the new DP‑800 Analytics Engineer exam going into beta this month Partners can submit any questions—technical, roadmap‑focused, certification‑related, or customer‑scenario driven. This event is exclusively available to members of the Fabric Partner Community. Not a member yet? Join the Fabric Partner Community to attend this AMA and unlock access to partner‑only events like this: https://aka.ms/JoinFabricPartnerCommunity🚀 FabCon + SQLCon Partner Social Sprint
A 4‑Day LinkedIn Challenge for Partners Attending FabCon + SQLCon in Atlanta If you’re joining us in Atlanta this March for FabCon + SQLCon 2026, we’ve got a new way for you to amplify your impact: the Partner Social Sprint — a daily LinkedIn challenge designed to spotlight partner voices, share real‑world insights, and have some fun along the way. Whether you’re presenting, staffing a booth, or attending sessions, this is your chance to tell your story and connect with the global Microsoft Fabric & SQL community. 🔥 What Is the Partner Social Sprint? A 4‑day LinkedIn posting challenge running during FabCon + SQLCon 2026 in Atlanta. Each day has a theme, and every post earns you entries to win exclusive Fabric SWAG, including the fan‑favorite Fabric Kicks. 🗓 Daily Themes (Conference Week) Tuesday, March 17 – Day 0 (Travel / Partner Day) Why I’m going / why I’m here Wednesday, March 18 – Day 1 One big learning Thursday, March 19 – Day 2 Build your practice Friday, March 20 – Day 3 Customer impact ✅ How It Works If you’re a partner attending FabCon + SQLCon in Atlanta: Post once per day on LinkedIn during the event, following the daily theme. Use the hashtags: #FabConSQLCon26 #PartnerSocialSprintSweepstakes #MicrosoftPartner Tag the FabCon & SQLCon – The Microsoft Fabric & SQL Community Conferences LinkedIn page. Submit all your LinkedIn post URLs via the entry form. 👉 Each post = 1 entry, and if you post all 4 days, you’ll get 1 bonus entry. 🏆 What You Can Win Fabric SWAG Fabric Kicks Recognition in the Fabric Partner Community and across our channels 🌐 Who Should Join? Microsoft partners attending FabCon + SQLCon in Atlanta Partner sellers, architects, engineers, and community champions who want to: Share key learnings in real time Highlight their Fabric & SQL practices Showcase customer success and impact 👉 Ready to Sprint With Us? Get all the details and submit your posts here: https://aka.ms/PartnerSocialSprint Let’s light up LinkedIn with the stories, insights, and innovation coming out of FabCon + SQLCon. We can’t wait to see your posts from Atlanta!🚀 This Week on the Fabric Engineering Connection!
Excited to share what’s ahead for this week’s Fabric Engineering Connection sessions — your weekly opportunity to hear directly from the Microsoft Fabric engineering teams and stay ahead of what’s coming next in the platform. 🎙️ Featured Topics & Speakers: 🔧 Updates on DBT Job Abhishek Narain, Principal PM Manager 🤖 Upcoming Capabilities in Fabric Data Agents Misha Desai, Principal Product Manager Virginia Roman, Senior Product Manager Shreyas Canchi Radhakrishna, Product Manager 🌍 Americas & EMEA 📅 Wednesday, February 25 ⏰ 8:00–9:00 AM PT 🌏 APAC 📅 Thursday, February 26 ⏰ 1:00–2:00 AM UTC (Also available Wednesday, February 25, 5:00–6:00 PM PT) Whether you're deep in deployment, scaling customer workloads, or exploring new Fabric capabilities, these sessions are packed with insights to help you accelerate your practice. 👉 Not yet part of the Fabric Partner Community? Join here: https://lnkd.in/g_PRdfjt Let’s keep learning, building, and shaping the future of Fabric—together. 💡Create an Organizational Assets Library (including Multi-Geo & Information Barriers guidance)
Overview This guide walks through a practical approach to setting up SharePoint Online (SPO) Organizational Assets Libraries (OAL). It includes optional guidance for more complex tenants—such as Multi-Geo and Information Barriers (IB) - because those scenarios are often under-documented. What you’ll accomplish: Create and register Organizational Assets Libraries so templates, fonts, and brand images are available in Office apps, with notes for Multi-Geo, Information Barriers, Brand Center, and Copilot integration where applicable. Applies to: Standard (single-geo) tenants, Multi-Geo tenants, tenants with Information Barriers, and environments using Brand Center and/or Copilot features for organizational assets. Quick start (standard single-geo tenant) Create a SharePoint site to host Organizational Assets Libraries (often the Brand Center site). Create three document libraries (typical): ImageAssets, DocumentAssets (templates), FontAssets. Grant your intended audience Read access (commonly Everyone except external users via the site’s Visitors group). Enable the SharePoint Online Public CDN (tenant setting). Add a Public CDN origin for each library path (one origin per library). Upload approved assets (images, templates, fonts) into their respective libraries. Register each library with Add-SPOOrgAssetsLibrary (repeat per library). Validate registration and end-user experience, then allow up to 24 hours for Office apps to reflect changes. If you’re Multi-Geo or using Information Barriers: follow the same flow, but repeat per geo and complete registration while the site is in Open IB mode (details below). Key constraints and gotchas Multi-Geo: plan a repeatable per-geo pattern (typically one Org Assets site + matching libraries per geo) and keep naming consistent. Information Barriers (IB): Add-SPOOrgAssetsLibrary cannot be run when the target site is segmented—create and register libraries first (site in Open mode), then segment if needed. The “Everyone except external users” principal may be hidden by default, but it’s still commonly used for broad read access. Brand Center: many orgs host Org Assets Libraries in the Brand Center site; if Brand Center is created after libraries exist, it typically detects and uses them automatically. A public CDN must be enabled to support Organizational Assets Libraries. The “Everyone except external users” principal may be hidden by default, but it’s still commonly used for broad read access. Brand Center: many orgs host Org Assets Libraries in the Brand Center site; if Brand Center is created after libraries exist, it typically detects and uses them automatically. A public CDN must be enabled to support Organizational Assets Libraries. Implementation steps Prerequisites: SharePoint Online Management Shell access (or equivalent), permission to manage tenant settings, and the ability to create sites and libraries in each geo. Create a site to host your Organizational Assets Libraries (many orgs use a communication site). For ease of support, keep the site name, library names, and structure consistent over time. Note: A Communication site is recommended, but a Team site can also work. Example site URLs: In a standard tenant you’ll have one site; in Multi-Geo you’ll typically use one per geo. Primary geo: https://contoso.sharepoint.com/sites/BrandCenter EUR geo: https://contosoEUR.sharepoint.com/sites/BrandCenter APC geo: https://contosoAPC.sharepoint.com/sites/BrandCenter If your tenant uses Information Barriers, keep each site in Open IB mode while creating the Org Assets Libraries. You can segment the site later (if required) after libraries are created. Configure a public CDN (required) To use Brand Center and Organizational Assets Libraries, configure SharePoint Online to use a Public CDN. Set-SPOTenantCdnEnabled -CdnType Public -Enable $true Example output: Public CDN enabled locations: SITES/BRANDCENTER/FONTS */MASTERPAGE (configuration pending) */STYLE LIBRARY (configuration pending) */CLIENTSIDEASSETS (configuration pending) Note: You will see the new CDN is in a pending state until complete. This will take some time. Wait for the CDN to finish provisioning. Re-run the status/list commands until “pending” entries clear. Get-SPOTenantCdnEnabled -CdnType Public Get-SPOTenantCdnOrigins -CdnType Public Add CDN origins for each library Add allowed CDN origins for each asset library path (typically one origin per library). Example: Add-SPOTenantCdnOrigin -OriginUrl sites/BrandCenter/ImageAssets -CdnType Public Add-SPOTenantCdnOrigin -OriginUrl sites/BrandCenter/TemplateAssets -CdnType Public Add-SPOTenantCdnOrigin -OriginUrl sites/BrandCenter/FontAssets -CdnType Public Set permissions (required for broad consumption) To ensure most users can consume the assets, grant Everyone except external users (often abbreviated as EEEU) Read access (commonly via the site’s Visitors group). Example: add Everyone except external users to the Visitors group of the Organizational Assets site. Connect-SPOService -Url 'https://contoso-admin.sharepoint.com' $tenant = "9cfc42cb-51da-4055-87e9-b20a170b6ba3" $site = Get-SPOSite -Identity "https://contoso.sharepoint.com/sites/BrandCenter" $group = Get-SPOSiteGroup $site -Group "BrandCenter Visitors" Add-SPOUser -LoginName ("c:0-.f|rolemanager|spo-grid-all-users/" + $tenant) -Site $site -Group $group.Title Note: Organizational Assets Libraries respect SharePoint security trimming. If you need a narrower audience, grant Read to the appropriate groups instead of tenant-wide access. In many environments, Everyone except external users is required during registration (Add-SPOOrgAssetsLibrary) so Office can enumerate the library—test and confirm in your tenant before removing broad access. Create libraries and upload assets Create a document library for each asset type you plan to publish (for example: images, Office templates, fonts). For example: Upload your assets into the appropriate libraries. Example: Register each library using Add-SPOOrgAssetsLibrary. For this to work, Everyone except external users must already have access to the site (for example, via the Visitors group). Office Template Library Example: Add-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/DocumentAssets' -OrgAssetType OfficeTemplateLibrary Image Document Library Example: Add-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/ImageAssets' -OrgAssetType ImageDocumentLibrary Font Document Library Example: Add-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/FontAssets' -OrgAssetType OfficeFontLibrary -CdnType Public Optional: Enable Copilot support for an image library (only applicable to ImageDocumentLibrary). Set-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/ImageAssets' -OrgAssetType ImageDocumentLibrary -CopilotSearchable $true Multi-Geo mini runbook (recommended pattern) Use this as a simple tracking sheet so each geo ends up with a complete, consistent setup. Geo Site URL Libraries CDN origins added Libraries registered Primary https://<tenant>.sharepoint.com/sites/<BrandCenterOrAssetsSite> ImageAssets / DocumentAssets / FontAssets Yes/No Yes/No EUR https://<tenant>EUR.sharepoint.com/sites/<BrandCenterOrAssetsSite> ImageAssets / DocumentAssets / FontAssets Yes/No Yes/No APC https://<tenant>APC.sharepoint.com/sites/<BrandCenterOrAssetsSite> ImageAssets / DocumentAssets / FontAssets Yes/No Yes/No Naming standard (strongly recommended): keep the same site path and the same library names in every geo (for example, always ImageAssets, DocumentAssets, FontAssets). This minimizes per-geo scripting differences and reduces support effort. Wrap-up At this point, each geo should have its own site, libraries, CDN origins, and registered Organizational Assets Libraries. From here, focus on governance (who can publish/approve assets), naming standards, and ongoing lifecycle management (retire old templates/fonts and keep branding current). Validate configuration Admin checks (PowerShell) Confirm the Public CDN is enabled. Confirm CDN origins include one entry per assets library path. List registered Org Assets Libraries and verify each URL + type is present. Get-SPOTenantCdnEnabled -CdnType Public Get-SPOTenantCdnOrigins -CdnType Public Get-SPOOrgAssetsLibrary End-user checks (Office apps) In PowerPoint/Word, confirm organizational templates appear in the template picker (if you registered an OfficeTemplateLibrary). In Office font lists, confirm your org fonts appear (if you registered an OfficeFontLibrary). For image libraries, confirm approved brand images appear in supported pickers; if you enabled -CopilotSearchable, confirm images are discoverable as expected. Timing: New registrations and updates can take up to 24 hours to appear in Office apps. If you updated content, run Set-SPOOrgAssetsLibrary for each changed library, then wait for propagation. Updating content in existing Org Assets Libraries If you already have Organizational Assets Libraries registered and you need to publish updated templates, fonts, or images, use the process below. The high-level flow is: update content → run Set-SPOOrgAssetsLibrary (per library) → wait for propagation. Replace or update content in each library. Upload the new versions of templates/fonts/images into the appropriate library (and remove/retire older versions if needed). If Multi-Geo applies, repeat per geo. Update the matching libraries in each geo’s site so users in each geo get the same (or intentionally regional) set of assets. Run Set-SPOOrgAssetsLibrary for each updated library. Execute the cmdlet against the library URL to refresh the configuration after content changes (run it once per library you updated). Wait for Office app propagation. Allow up to 24 hours for updates to begin showing in Office apps. Example: Set-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/DocumentAssets' -OrgAssetType OfficeTemplateLibrary Notes: If your site is segmented by Information Barriers, confirm the cmdlet behavior in your environment before making changes, and prefer performing registration/updates while the site is in Open mode when possible. For image libraries, if you are using Copilot integration settings (for example -CopilotSearchable), keep the setting consistent when you run Set-SPOOrgAssetsLibrary. Make sure the intended audience still has Read access to the site/library; otherwise users may not see updates due to security trimming. Please note: After registering (or updating) your assets libraries, it can take up to 24 hours before changes become available in Office apps. Once fully enabled, Office apps will surface your templates and fonts. Below is an example. Example of interacting with Org Assets from M365 Apps Org Fonts from PowerPoint: From SharePoint: From Office Apps: Troubleshooting tips If Add-SPOOrgAssetsLibrary fails, confirm the site is not segmented by Information Barriers (Open mode during setup). If assets don’t appear in Office apps, wait for propagation (up to 24 hours) and re-check that the library was registered successfully. If CDN commands show “pending”, allow time for provisioning and re-run the status command. If users can’t see assets, verify the site/library permissions include Everyone except external users (or the intended audience group). Guidance: Using the SharePoint Online Public CDN Enabling the SharePoint Online Public CDN is a required and supported configuration for Organizational Assets Libraries, Brand Center, and related Office experiences. While the word “public” can sound concerning, it’s important to understand what is (and is not) exposed. We take great care to protect the data that runs your business. Data stored in the Microsoft 365 CDN is encrypted both in transit and at rest, and access to data in the Microsoft 365 SharePoint CDN is secured by Microsoft 365 user permissions and token authorization. Requests for data in the Microsoft 365 SharePoint CDN must be referred (redirected) from your Microsoft 365 tenant or an authorization token won't be generated. See: Content delivery networks - Microsoft 365 Enterprise | Microsoft Learn What “Public CDN” actually means Only explicitly approved library paths are cached The CDN does not expose your entire tenant. Administrators must explicitly register CDN origins (specific library paths). If a library is not registered as a CDN origin, it is not served via the CDN. No new content types are exposed The CDN is intended for static, non-sensitive assets such as: Brand images Office templates Fonts It is not designed for documents containing confidential or regulated data. Why Microsoft requires a Public CDN for Org Assets? Performance and reliability Office clients worldwide retrieve assets faster using geographically distributed edge caching. This avoids repeated downloads from SharePoint origin sites. Consistent Office app experiences PowerPoint, Word, Excel, and Copilot rely on CDN-backed delivery to surface: Templates Fonts Brand images Without a public CDN, these features may not function correctly or at all. Best practices Use the practices below to keep Organizational Assets Libraries reliable, secure, and easy for end users to adopt. Where relevant, notes call out additional considerations for Multi-Geo, Information Barriers, Brand Center, and Copilot. Governance and ownership checklist Owners/publishers: named group who can add/change assets (limited membership). Approvals: defined review/approval step before publishing new templates/fonts/images. Versioning/retention: how you retire old assets and prevent outdated branding from appearing in pickers. Rollback plan: how to revert a bad template/font/image quickly. Change communication: how you notify users about new/updated assets and expected timing (up to 24 hours). Assign clear owners (typically Brand/Comms) and a small admin group (typically IT) for each geo’s library and site. Decide what is “approved” vs “draft” content, and enforce it with a simple publishing process (for example, a review checklist or an approvals flow). Version and retire assets deliberately: keep one “current” template set and archive old assets to prevent users from picking outdated branding. Information architecture and naming Keep library names and structures consistent across geos (same library names, same folder conventions) to simplify support and documentation. Use descriptive filenames users can recognize in pickers (for example, “Contoso_Proposal_Template_v3”). Prefer a small number of clearly defined libraries by asset type (images, templates, fonts) rather than many small libraries. Permissions and access Ensure your intended audience has at least Read access to the site and libraries; Organizational Assets still follow SharePoint security trimming. If you use broad access (for example, Everyone except external users), document it and pair it with tight contributor permissions so only approved publishers can change assets. Avoid breaking inheritance in ways that make troubleshooting difficult—keep permissions simple and predictable whenever possible. CDN configuration Plan CDN changes ahead of time: enabling and provisioning can take time, and changes may not be immediate. Register only the origins you need (one per assets library path) and keep them consistent across environments. After changes, allow for propagation time before validating in Office apps. Multi-Geo and Brand Center Use a repeatable pattern: one site + matching libraries per geo, with the same structure and operational runbook. Be aware Brand Center is created in the primary geo; confirm how your org wants to manage global vs regional assets. Document which assets are global (shared everywhere) vs regional (geo-specific) to avoid confusion for publishers and users. Information Barriers (IB) sequencing Create and register Org Assets Libraries before segmenting the site when IB is enabled (create while the site is in Open mode, then segment later if required). After segmentation, re-validate that the right audience can still read the libraries (and that publishers can still manage content). Copilot readiness (image libraries) Use consistent, high-quality metadata for images (titles, descriptions, and tags). Copilot search quality depends heavily on this. If enabling image tagging integration, standardize on a tagging vocabulary (for example, brand terms, campaigns, departments, regions) so results are predictable. Only enable Copilot searchable settings on libraries where content is approved and intended for broad reuse. Q&A Q: What is an Organizational Assets Library (OAL)? A: It’s a SharePoint document library (or set of libraries) that you register so Office apps can surface approved templates, fonts, and images to users directly within the app experience. Q: Do I need SharePoint Brand Center to use OAL? A: No. You can use Organizational Assets Libraries without Brand Center. Brand Center can make asset management more accessible, for example, allowing SharePoint sites to use organizational branding, but OAL can be configured on its own. Q: Why is a “Public CDN” required, and is it safe? A: Office experiences rely on CDN-backed delivery for performance and reliability. “Public CDN” does not mean your whole tenant is exposed—only the specific library paths you register as CDN origins are cached. Access is still governed by Microsoft 365 authentication, token authorization, and SharePoint permissions. Q: Can I use this guide in a standard (single-geo) tenant? A: Yes. In a standard tenant you usually create one site and one set of libraries. The Multi-Geo guidance is only needed if your tenant is Multi-Geo (in which case you’ll typically repeat the pattern per geo). Q: How do Information Barriers (IB) affect setup? A: If a site is segmented, Add-SPOOrgAssetsLibrary cannot register the library. Create the site and register the libraries while the site is in Open mode, then segment afterward if required. Q: Why does “Everyone except external users” (EEEU) matter? A: In many environments, EEEU is required during library registration so Office can enumerate the library. However, OAL still respects SharePoint security trimming. If broad internal availability is the goal, a common pattern is to grant EEEU Read (often via the Visitors group) so Office apps can surface the assets to most internal users. If you need a narrower audience, use a group instead. Q: How long until assets show up (or update) in Office apps? A: It can take up to 24 hours for new registrations or updates to propagate. If you replaced content in an existing library, run Set-SPOOrgAssetsLibrary for each updated library, then allow time for Office apps to refresh. Q: How do I update content in an existing Org Assets Library? A: Replace the files in the library (and repeat across geos if applicable), then run Set-SPOOrgAssetsLibrary against each library you updated. After that, allow up to 24 hours for the updated assets to start showing in Office apps. Q: Do I need to run Set-SPOOrgAssetsLibrary every time I replace files? A: If you want Office apps to reliably pick up changes, run Set-SPOOrgAssetsLibrary after you update content (especially when publishing new/updated templates, fonts, or images). Treat it as the “refresh” step, then wait for propagation. Q: When should I enable Copilot support (CopilotSearchable) for an image library? A: Enable it only for libraries that contain approved, broadly reusable images and have strong metadata (title/description/tags). This helps ensure search results are on-brand and reduces the chance of surfacing unreviewed content. Q: Can I undo this later? A: Yes. You can unregister an Organizational Assets Library using SharePoint Online PowerShell (for example, Remove-SPOOrgAssetsLibrary) and remove CDN origins if you no longer need them. Plan governance so you can retire assets cleanly without disrupting users. Q: Users can’t see the assets (or updates)—what should I check first? A: Start with (1) permissions to the site/library (security trimming), (2) successful registration via Add-SPOOrgAssetsLibrary, (3) if you’re expecting an update, confirm you ran Set-SPOOrgAssetsLibrary for that library, (4) CDN provisioning status and configured origins, and (5) propagation time (up to 24 hours). Additional Reading Create an organization assets library - SharePoint in Microsoft 365 | Microsoft Learn Connect organizational asset libraries to Copilot for an on-brand experience - SharePoint in Microsoft 365 | Microsoft Learn Connect organizational asset libraries to PowerPoint for an on-brand experience - SharePoint in Microsoft 365 | Microsoft Learn Set up and connect organizational asset library (OAL) with image tagging to Copilot search | Microsoft Learn Add-SPOOrgAssetsLibrary (Microsoft.Online.SharePoint.PowerShell) | Microsoft Learn SharePoint Brand Center - SharePoint in Microsoft 365 | Microsoft Learn How to Enable Enterprise Brand Images with PowerPoint Copilot - SharePoint in Microsoft 365 | Microsoft Learn Office 365 Content Delivery Network (CDN) Quickstart - Microsoft 365 Enterprise | Microsoft Learn Use Office 365 Content Delivery Network (CDN) with SharePoint Online - Microsoft 365 Enterprise | Microsoft Learn Content delivery networks - Microsoft 365 Enterprise | Microsoft Learn Multi-Geo Capabilities in OneDrive and SharePoint - Microsoft 365 Enterprise | Microsoft Learn Use Information Barriers with SharePoint | Microsoft Learn✨ FabCon + SQLCon 2026: Partner Know Before You Go Now Live!
Heading to FabCon + SQLCon 2026 in Atlanta? We’ve put together your full Partner Know Before You Go Guide — everything you need to navigate the week, maximize value, and make the most of all partner‑exclusive opportunities. 🚀 Here’s what you’ll find inside: 📅 Partner Day (Mar 17) — A full day of partner‑only learning, strategy, and networking. - SOLD OUT! 🍻 Partner Happy Hour — Connect with other partners and the Microsoft team. 🎤 AMA with the Fabric Partner Success Team — Bring your biggest questions around Data & AI priorities, partner opportunities, funding, enablement, and certifications. 🤝 1:1 Meetings — Book time with Fabric LT or the Partner Success Team to accelerate your strategy and unlock customer wins. 🎤 Partner Elevator Pitch Search — Submit your 2‑min pitch to be featured live on stage! 🔥 Partner Social Media Sprint — Daily LinkedIn challenge + chances to win Fabric SWAG. 🎓 Certification Spotlight — Get recognized during Arun’s keynote for hitting 100+ Fabric certs. 🎥 Testimonial Videos — Share your Fabric customer stories with global visibility. 📱 Whova Event App — Build your schedule, access slides, network, and join the partner community inside the app. 📘The full KBYG guide is attached below.Join the Fabric Partner Community for this Week's Fabric Engineering Connection Calls
🚀 Excited to share this week’s Fabric Engineering Connection lineup for our Microsoft Fabric partner community! We’ll be joined by Johannes Kebeck, Principal PM Manager, to dive into Fabric Maps — and how partners can bring location intelligence and rich geospatial experiences into their Fabric solutions. 📍 Fabric Engineering Connection – This Week 🌎 Americas & EMEA 📅 Wednesday, February 11 ⏰ 8:00–9:00 am PT 🌏 APAC 📅 Thursday, February 12 ⏰ 1:00–2:00 am UTC (Wednesday, February 11, 5:00–6:00 pm PT) These weekly calls are a chance for partners to: ✅ Hear directly from Fabric engineering ✅ See what’s new and what’s coming ✅ Ask questions and share feedback To participate in these calls, you must be a member of the Fabric Partner Community Teams channel. 👉 Join here: https://aka.ms/JoinFabricPartnerCommunity
