Option to rename Fabric capacity in the Fabric admin portal
In Azure we give our resource a name using a standard naming convention. For Fabric one of our capacities is named something like xxx02prdxxxfab001 (xxx1 = our prefix, prd = production, xxx2 = solution abbrivation, fab = fabric resource, 001 = capacity number 1). We are using this naming convention, because properties of a resource can change and you don't want te get stuck with a resource name with a specific name, that might not be valid in the future. But this name is now also the name of the capacity in Fabric, where, in Fabric, we actually want to rename it to a name more recognizable to it's properties, like "F64 production capacity". The option is already there in Fabric on the capacity settings, but you can't change the name after clicking the pencil button. We are using multiple capacities, so it would be usefull to have the ability the rename the capacities.
Dynamic SQL Pools in Warehouse
Custom SQL Pools is now in preview, but I see a limitation in the sense that you cannot allocate more than 100% capacity to all pools. I would like to see the ability to create multiple pools and assign pools a priority. I am considering an example where I have heavy ETL workloads that run late at night that I would want to grant 100% of resources with a medium priority. At the same time, I want an intraday ETL pool at uses 35% with a high priority and a pool for reporting that is allocated up to 70% with a medium priority. In this configuration, we have pools subscribing to more than 100%, but the scheduler could grant nodes based on priority.
Dashboard to see the Copilot Usage in Power BI
I would like to propose the development of a centralized dashboard within Microsoft Fabric that provides a comprehensive view of Microsoft Copilot usage across all users within a tenant. Currently, organizations often need to gather usage insights from multiple locations and reports, which can make monitoring adoption, engagement, and utilization more complex and time-consuming. A unified dashboard would simplify this process by consolidating all relevant Copilot usage metrics into a single, easy-to-navigate interface. Key Benefits: Centralized visibility of Copilot adoption and usage across the tenant. Improved user experience by eliminating the need to navigate multiple reporting sources. Easier tracking of user engagement and licensing utilization. Better support for customer discussions regarding Copilot value, adoption, and ROI. Consistent and aligned reporting for administrators, support teams, and stakeholders. Such a dashboard would help organizations quickly understand how Copilot is being used across their environment while providing a more efficient and streamlined reporting experience.
Enable Data Buy & Sell Across - Fabric, Non-Fabric, Tenants and Regions
Requested Enhancement: Enable Microsoft Fabric Marketplace capabilities that allow organizations to seamlessly buy, share, and sell data products across: - Fabric and non-Fabric environments - Different Microsoft Entra tenants (cross-tenant) - Different Azure regions (cross-region) The experience should provide a unified marketplace where organizations can discover, purchase, subscribe to, and consume data products regardless of whether the provider or consumer is using Fabric. Similarly, organizations should be able to publish and monetize data products for both Fabric and non-Fabric consumers without requiring complex data-sharing, integration, or onboarding processes. Key Requirements: - Support data product buying and selling between Fabric and non-Fabric platforms. - Enable seamless cross-tenant data commerce and sharing. - Enable cross-region data discovery, subscription, and consumption. - Provide a consistent marketplace experience for data providers and consumers. - Simplify onboarding, governance, billing, and access management for marketplace transactions. Business Value: - Creates a global data marketplace that extends beyond the Fabric ecosystem. - Unlocks new revenue opportunities by allowing organizations to monetize data assets across tenants, regions, and platforms. - Simplifies secure data sharing and collaboration between business partners, customers, and suppliers. - Reduces friction associated with cross-region and cross-tenant data exchange. - Positions Microsoft Fabric as a central hub for enterprise data commerce, enabling seamless buy-and-sell experiences across the broader data ecosystem.
Reintroduce Tenant/Capacity Switch to Control "Users can create Plan items" Post-GA
During the Preview phase of Fabric Plan items, administrators had access to a dedicated tenant/capacity setting: "Users can create Plan items". With General Availability (GA), this granular administration toggle was removed, enabling the capability broadly. Business & Governance Impact Plan items require an underlying SQL Database and consume additional Capacity Units (CUs). In enterprise environments, allowing all users to freely create Plan items creates significant operational and financial risks: Uncontrolled CU Consumption: Unrestricted creation leads to unexpected spikes in Capacity Unit utilization, impacting high-priority workloads across shared capacities. Database Sprawl: Automatic provisioning of underlying SQL DB dependencies without administrative oversight creates governance, compliance, and management overhead. Lack of Cost Allocation: Administrators cannot enforce least-privilege access or limit Plan item creation to authorized departments/workspaces. Proposed Solution Re-introduce the tenant-level and capacity-level governance setting under the Fabric Admin Portal: Tenant-Level Toggle: Allow Fabric Admins to enable/disable Plan item creation globally or restrict it to specific Security Groups. Capacity-Level Override: Allow Capacity Admins to turn off Plan item creation on specific capacities where CU consumption needs to be strictly budgeted or reserved for core analytics pipelines.
Feature Request: Add Relative-Date / T-5 Incremental Export Scheduling to Azure Cost Management
Hi all, I would like to suggest an enhancement to Azure Cost Management Exports. Today, the export scheduler appears to support standard recurring schedules such as daily, weekly, and monthly. However, for operational cost processing, it would be very useful to have support for a relative-date incremental export pattern, for example: - export current date minus 5 days only - export only the latest stabilized day - avoid re-exporting previously completed dates in every month-to-date run Why this matters? In our case, repeated month-to-date exports create unnecessary overhead because previously completed days are included again and again. This leads to: - larger export volumes - redundant file downloads - repeated SQL loads - more storage usage - more network traffic - unnecessary transaction and processing cost Suggested features It would be helpful if Azure Cost Management could support: - T-5 / T-N relative-date export - single-day rolling export - incremental export mode - an option to exclude already completed dates - a configurable stabilization window Example If today is August 9, 2026, the export could generate August 4, 2026 only, instead of re-exporting the entire month-to-date range. This would make Azure Cost Management much more efficient for teams that process cost data incrementally and need to avoid repeated extraction of already completed days. Would others find this useful as well?Suggestion: Page-Level Visibility Control Based on RLS/OLS in Power BI
Hi Team, Good day. I would like to propose an idea for consideration regarding report security and user experience in Power BI. Currently, we are implementing Row-Level Security (RLS) and Object-Level Security (OLS) based on defined rules to control data access. As an enhancement, it would be highly beneficial if we could extend this capability to also control page-level visibility based on user access. Example scenario: User 1: Access to Page 1 and Page 2 User 2: Access only to Page 2 In this case, it would be valuable if Page 1 could be completely hidden from User 2, rather than just restricting the data within the page. This would improve report usability, maintain cleaner navigation, and enhance overall user experience. Thank you for considering this suggestion. Please let me know if any additional details are required. Thanks, Srikanth TalluriCustom live pools on capacity level
If you like me started with working with notebooks in Fabric and have company policy that dictate using private links you will have discovered Microsoft “starter pools” are no longer an option. The startup time goes from below 10 seconds to 3-5 minutes. Microsoft have luckily decided to do something about this and have now introduced custom live pool in public preview. This is a great first step for customers – however it has one very limiting factor – it only work with workspace pools. These sessions will “only” be available on one given workspace and not across multiple workspaces. My proposal is to introduce custom live pools on capacity level. I want to be able to define environments on capacity level and share custom live pools on any workspace connected to this capacity. This will have the following benefits: Much easier for the admin to administrate custom live pools Cost effective – we would max want to pay for X custom live pools and spread them between all of the workspace for a given capacity – we cannot/“will not” set this up pr. workspace and have idle custom clusters across many workspaces. Link to current configuration on custom live pools on learn: Configure custom live pools in Microsoft Fabric - Microsoft Fabric | Microsoft Learn
More control over smoothing and proactive warning of throttling due to overburn on F-SKU reduction
We need to be able to have more options to configure how smoothing works, and more proactive warning and visibility of its impacts. Smoothing in general is a great feature. In our use-case, smoothing worked against us, cost us money unnecessarily, and we had no way to turn it off or be confident about managing its side-effects. We had a one-off job that needed more capacity than normal so we increased the Capacity in question from F4 to F128. Based on test runs of a real but smaller slice of the data, we estimated ~6M CUs were needed. We had no other workloads that needed to compete for compute on the Capacity at that time. We wanted to use the full available compute for our background job. We ran for about 20h and after that the job had finished, so we turned the capacity back down to F4. That immediately caused throttling which would have taken ~6d to clear with an F4 (about 4-5h on F128), so we restarted the Capacity to clear the overburn. Metrics afterwards showed that our estimation on the CUs used was accurate, but that due to smoothing, the costs for the compute had been delayed and not burnt down by the time we reduced. So even though the Compute wasn't fully utilised and over the period the job was running there were more CUs available than used, we got throttled afterwards and charged for more CUs on top. There was clearly enough compute capacity on the Capacity during the jobs lifetime to have completed in the period, so that we didn’t have to incur extra costs. We have effectively been billed for Capacity that we would never have used for anything else, that we were trying to use for the one purpose, and could not. We would have tuned smoothing to kick in at close to 100% of capacity (ie avoiding bursting), if the option existed, and if we had understood all of this. On reducing a Capacity SKU, it would be useful to have a warning about outstanding overburn causing immediate and extended throttling, and for how long. This is a service interruption and should not happen without proactive notification, as it currently does. It would also make sense if smoothing was more intelligent, and could observe that no other workload is burning available CUs, and thus that the consumption spend does not need to be delayed. This would be fairer to us as a customer than denying us use of paid-for capacity CUs and 'losing' that spend. Note, this is similar to Configurable Smoothing of Capacity Usage - Microsoft Fabric Community. But the use-case and request for notification is different, so I thought worth posting separately.Configurable Smoothing of Capacity Usage
Smoothing currently balances the CUs required to complete background tasks across 24 hours. This often means that overnight we are under-utilising our capacity and offsetting some of the load to our peak usage period during the day. Since the peak period also includes many interactive processes, smoothing is actually creating usage peaks right when we are using the processes which are most impacted by those peaks. We should be able to control smoothing by setting a percentage of capacity that can be utilised by background processes. If background usage is below this figure the spare capacity should then be used to speed up background processing. Example: Consider a 6 CUhr background operation starting at midnight. Currently, it would consume 0.25 CUhr per hour for 24 hours. Running an F2 Sku, I set my Background Processing Limit to 50% between 00.00 and 06.00. Now the operation consumes 1 CUhr per hour for 6 hours and no consumption for the remaining 18 hours.
