Add ability to manage Fabric capacity by Operation-Kind(s), Night-hours and Workspaces
Fabric Capacity Surge protection and overages are a step in the right direction. Unfortunately the threshold percentage is same for each workspace in the current UI. The ability to have a higher percentage of CU (s) for interactive operations at specific times (for example, in a customer facing company 8-9am or 1-2pm) and the ability to schedule more CUs for background operations at different times in the day helps us control the spread better. Thirdly, let's face it, all workspaces are not equal - like this😀😁! Some workspaces are meant to be for CxOs and some for Accounting. To be able to control the CU (s) in a more granular fashion is the order of the day. I have been requesting Microsoft for years!
Make Workspace-Level Surge Protection Limit Visible to Workspace Users
Please make the applicable workspace-level surge protection limit visible in the workspace settings. Currently, when surge protection is applied by Capacity Admins, workspace users don't get visibility into how much compute their workspace is allowed to consume. Showing the configured limit in the workspace would make it much easier for users to understand the workspace's actual compute boundaries and avoid throttling. Suggested improvement: Add a section to Workspace Settings showing the applicable surge protection limit, for example: This workspace's surge protection limit: 19.2 CUs (30% of F64)
Enable Managed Private Endpoints Support for Microsoft Fabric Capacities Below F64
Managed Private Endpoints in Microsoft Fabric are currently supported only on F64 and higher capacities. Customers using lower capacities, such as F8, cannot establish private connectivity to Azure services like Azure SQL Database when public network access is disabled. We request support for Managed Private Endpoints on lower Fabric capacities, or the introduction of an alternative secure connectivity mechanism that provides similar functionality without requiring an upgrade to F64. This limitation restricts customers on lower Fabric capacities from implementing private network connectivity to Azure resources. As a result, organizations with security and compliance requirements may need to upgrade to higher capacities primarily to access secure networking capabilities, increasing deployment costs and potentially impacting Fabric adoption for smaller-scale workloads.
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.Ability to Recover Previous Versions of Power BI Service Reports After Overwrite
Description: Currently, when a report developed directly in the Power BI Service is overwritten, there is no supported method to recover the previous version of the report. In the observed scenario: The report was created and maintained in the Power BI Service. The report was subsequently overwritten by a newer version. An earlier version remained visible in the published app; however, it could not be exported because the "Allow users to make a copy of the reports in app" setting was not enabled when the app was published. Enabling this setting after the overwrite does not restore access to the previous version, as it requires republishing the current report and does not provide a mechanism to retrieve historical versions. Expectation: Providing report version recovery would improve resiliency, reduce the risk of accidental data loss, and help customers quickly restore reports when unintended overwrites occur.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.
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?
