The Fabric community is upgrading!
We're excited to announce that the Microsoft Fabric Community will move to an upgraded platform experience beginning August 14, 2026. This upgrade is a major milestone that gives us a more modern, scalable foundation while enabling faster innovation and a better overall community experience. Most importantly, it positions us to respond quicker to feedback and continue improving the community over time. Why We're Upgrading The current platform has served us well, but it's built on an older architecture that makes it difficult to take advantage of modern technologies and deliver improvements at the pace we'd like. By upgrading to the latest platform, we're creating a more flexible, future-ready foundation that will allow us to: Deliver updates and enhancements faster Improve reliability and maintainability Respond more quickly to community needs Continue evolving the experience based on feedback What Members Can Expect The majority of the community experiences you use today will continue to be available after the upgrade, along with several improvements, including: A more modern and intuitive user experience Improved navigation and accessibility Enhanced filtering and content discovery Continued investments in performance and usability Updated Ideas statuses that provide clearer visibility into suggestion progress While a small number of enhancements will follow shortly after launch, this upgrade establishes the foundation for ongoing innovation and future improvements. RSS Feeds RSS feeds will continue to be available after the upgrade. As part of the upgrade, RSS feed URLs will change. RSS feed URLs are configured to automatically redirect to the new RSS feed URLs, so subscribers should continue to receive updates without interruption. Will my existing RSS subscriptions stop working? No. Exisitng RSS feed URLs will automatically redirect to the new URLs. Most users should not need to take any action. If you maintain custom automations or integrations that reference RSS feed URLs directly. Upgrade Timeline August 13, 2026 In preparation for the upgrade, any new support requests that the community managers need to process, such as username changes, email mappings, etc, will be paused started August 13th until after August 16th. August 14, 2026 | 7:00 PM PST Upgrade Begins The community will enter read-only mode while the upgrade is performed. During this time: Existing content will remain viewable New posts, replies, and content creation will be temporarily unavailable A maintenance page may be displayed during portions of the upgrade August 15, 2026 Validation & Stabilization Our team will validate key experiences, monitor platform health, and address any necessary stabilization work before reopening the community. August 16, 2026 Community Returns to Full Operation The upgraded Microsoft Fabric Community will be fully available to all members. Looking Ahead This upgrade is about more than technology. It's about creating a stronger foundation that allows us to move faster, deliver improvements more consistently, and build a better community experience for everyone. Thank you for your patience, support, and contributions to the Microsoft Fabric Community. We're excited for the future of Fabric and Power BI and look forward to building the next generation of the community together. Known Issues Post Upgrade We are aware there are a few minor issues after the upgrade. The team is actively investigating and working on fixes.Fabric Welcome Popup - Hide/Disable
Team - I am back with another requirement from my end users. They dont want to see the "Welcome to Fabric View " pop-up when they log in using Fabric apps URL. I have gone through all the tenant setting and I dont see any way to hide or disable this pop-up. Did anyone come across similar requirement? Any thoughts or suggestions? -PattFabric IQ: Do Ontology entity synonyms work with Data Agent?
Hi, everyone! Short intro Currently I'm using the "super-duper-mega-nano-ultra" product - Microsoft Fabric to build natural language processing flow on-top of Microsoft Fabric Warehouse data. As for now It's rather a POC than production solution. I found a lot of the official Microsoft' documentation related to my task, but I have a little problem... The solution architecture (high-level) I made some investigations and as the result is the following architecture, which I want to implement (picture below): The idea is the next: the Microsoft Fabric Warehouse schema is connected to Microsoft Fabric Lakehouse, using shortcut; the Microsoft Fabric Ontology consumes the Microsoft Fabric Lakehouse as a data source for data binding; the Microsoft Fabric Data Agent uses a Microsoft Fabric Ontology (enriched with business context) to process natural language questions. The Microsoft Fabric Warehouse contains the following (dummy) objects (picture below): Tenant settings Microsoft documentation says, that specific tenant configurations should be applied to use Microsoft Fabric Ontology with Microsoft Fabric Data Agent (https://learn.microsoft.com/en-us/fabric/data-science/data-agent-tenant-settings) - everything is configured properly. Ontology configuration My Microsoft Fabric Ontology is configured as below (the configuration is influenced by Microsoft Fabric Ontology tutorial, which can be found here - https://learn.microsoft.com/en-us/fabric/iq/ontology/overview). Main view - two entities with a single relationship: ETLEntity entity configuration - the entity has the description, one synonym, metadata: ETLEntityRun entity configuration - the entity has the description, one synonym, metadata: As for now the Microsoft documentation says, that Microsoft Fabric Ontology descriptions, synonyms, metadata help Microsoft Fabric Data Agent to better understand the context (https://learn.microsoft.com/en-us/fabric/iq/ontology/how-to-add-semantic-enrichment). The problem My Microsoft Fabric Data Agent is connected to my Microsoft Fabric Ontology, which is described above, but the agent can't answer the simple questions about entities and the questions examples are provided below (the Microsoft Fabric Ontology Graph model was refreshed successfully before questions were asked): ETLEntity successful question without synonym usage: ETLEntityRun successful question without synonym usage: ETLEntity failed question with synonym usage: ETLEntityRun failed question with synonym usage: Looks like Microsoft Fabric Data Agent can't figure out, which entities are unicorn/wizard, even if they have appropriate synonyms. It's not my first iteration - I tried a lot, but result still the same every time. I feel like I missed something obvious in my configuration, but what... What are your thoughts? P.S.: the provided configuration is simple; objects and their metadata has no business context - It's just a sample, which I built to test some scenario; I think It's enough to check such use-case.
High CU consumption after enabling Workspace Monitoring
Hi everyone, I’m wondering if anyone else has experienced very high CU consumption after enabling Workspace Monitoring in Microsoft Fabric. In my case, I tested it on an F4 capacity, and the additional CU usage was significant enough that the capacity became difficult to use for the actual workloads running in the workspace. I understand that Workspace Monitoring creates and uses Fabric resources for collecting and storing logs, so some additional capacity consumption is expected. However, the overhead I’m seeing feels quite high and it makes no sense to enable this feature I’m interested if there are any answers on following questions: Have you noticed a significant CU increase after enabling Workspace Monitoring? Is the impact especially noticeable on smaller capacities such as F2/F4/F8? Have you found any practical way to reduce the monitoring overhead? Are you using Workspace Monitoring in production on smaller capacities, or do you avoid it because of the CU cost? At the moment, my concern is that on smaller capacities the monitoring workload itself can consume enough capacity to materially affect the workloads it is supposed to help monitor. Would be interested to hear about other people’s experience and whether this is expected behaviour.Org Apps - Getting warning on web content
Team - I came across another scenario where there is an org app/Workspace PowerBI app that has Power BI reports & Embedded Tableau reports. These are trusted reports & HPTTS links . When app link is shared with end user they get a warning banner on top of the report with message - "This page contains contents not provided by Microsoft. Web contents could contain code with security or privacy risks" is there a way to suppress this message ? Not sure if anyone else is having similar issue. I was doing some research on this and found similar post in the community dated 10 years ago- there was no fix at that time and it was decided to put in as an idea. https://community.fabric.microsoft.com/discussions/power-bi-designer/getting-warning-on-web-content-in-power-bi-dashboard/35989/replies/36329 -Patt
Microsoft Fabric Airflow DAG Queued for 30 Minutes on Starter Pool
Hi everyone, I am trying to run a simple data ingestion DAG using Apache Airflow Jobs in Microsoft Fabric. The purpose of the DAG is to import data into a Microsoft Fabric Lakehouse. The DAG is intentionally simple, and I am currently trying to understand an issue related to DAG execution and queuing. Environment: Orchestration: Apache Airflow Job in Fabric Target: Microsoft Fabric Lakehouse Schedule: Manual (schedule=None) Authentication: OneLake token through an environment variable Compute/Pool: Starter Pool Issue: When I manually trigger the DAG, the DAG run remains in the Queued state for approximately 30 minutes. During this time, the task does not appear to start executing. After approximately 30 minutes, the DAG run eventually changes to Failed.
Microsoft Fabric Trial extension for DP-800 certification exam
Hello Microsoft Support Team, I am requesting a extension for my current Microsoft Fabric Trial, which is scheduled to expire in 4 days. I am actively using this trial to prepare for the DP-800 certification exam, which I am scheduled to take in September. I am hoping to get an extension so I can retain my study materials, workspaces, and continue my hands-on preparation without losing my progress. Thank you for your time and for supporting my certification journey. Best regards, Tiberiu
Architecture Issue : 600 tables treated in loop in Bronze
Dear all, Our architecture consists of four layers: Raw, Bronze, Silver, and Gold. Raw is composed of a single workspace, and Bronze also has its own workspace. Each workspace has its own lakehouse inside it. Tables land in Raw, coming from different sources, and are then shortcutted into Bronze. In Bronze, we have created persisted tables that mirror the Raw tables (with a few additional fields) but include historisation. These are fed incrementally, on a daily basis, based on the fields available in the Raw tables plus the last-run information stored in a table called load_audit, which records successful/failed runs and their characteristics. Both the audit table updates and the movement of data from shortcutted tables into persisted tables are handled by a single notebook. Problem: We are having issues with a specific source. This source comes from SQL Server 2019 and has more than 600 tables. Mirroring from source into Raw is working fine. The issue lies in appending data from the shortcutted tables into the Bronze persisted tables (the incremental load). Currently, this is done sequentially: the notebook loops through each table, applies the increment, and moves on to the next. This is taking a considerable amount of time — imagine, for example, 1 minute per table. There is also the problem of small files accumulating while feeding the audit load table. Simplified, it works like this: For each table: Incremental load into persisted table Insert run result into the audit load table Move to next table I discussed this with the data engineering team, and they are proposing the following: Create two separate notebooks, each with their own common utilities inside. 3.1. One will handle the large tables, and the other the small tables. 3.2. The large tables will be processed using the Spark engine (Spark workload), and the small tables using Python/Pandas. 3.3. A possible rule of thumb: if a table has fewer than 100K records, it goes to the small-table notebook; otherwise, it goes to the big-table notebook. 3.4. Partitioning by target schema and target table. 3.5. How do we address parallel execution across tables within each notebook? Splitting into two notebooks by size doesn't by itself remove the sequential loop — should we also parallelize within each notebook (e.g., concurrent threads for the Pandas notebook, or a Fabric pipeline ForEach with concurrency for the Spark notebook)? 3.6. How does this approach address the small-files problem on the audit load table? Splitting the workload doesn't inherently batch or compact writes — would we need OPTIMIZE/compaction scheduled on the audit table, or should writes be batched instead of one insert per table? 3.7. Should the 100K-record threshold be based on row count, or would data volume (MB/GB) or column count be a more reliable measure? A 100K-row table with 5 narrow columns and a 100K-row table with 200 wide/text columns have very different costs. 3.8. Where will the Pandas workload actually execute — on the driver node? If so, could running many small-table loads concurrently create memory/CPU contention with the Spark jobs running alongside it? What do you think about this approach? Could you please provide some guidance? Thanks a lot, Pedro
