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?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.
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 Talluri
Custom 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.Disclose the number of Fabric Trials used in the Admin portal
I learned today that Microsoft is limiting the number of Trials per tenant. It makes sense, but there is, currently, no way to see the number of Fabric Trials that have been activated. So please disclose this number in the Fabric Admin portal, for instance in the Capacities part under Trials. It makes it much easier to decide if we can still use a Trial for Proofs of Concept or need to log a call with Microsoft to upgrade the quota for Fabric capacities from 0 to any other number.
Separate per-subscription quota for Capacity Overage
Hi, Current state: Capacity Overage uses per-subscription CU quota that is shared with capacity reservations and PAYG scale-ups. Because scale-ups and capacity overage may be managed by different people, there may be conflict in using available quota. Also, tenant admins have no way of limiting usage of capacity overage by capacity admins. Desired state: Capacity Overage is a separate operation in Azure. If it would have a per-subscription quota, then subscription owners could effectively manage the availability of the feature for capacity admins. It also would protect the overlap with scale up CU needs.
Extended Workspace Surge Protection Policies
Enhance workspace-level surge protection by introducing finer control over how consumption limits are applied, instead of the current all-or-nothing model (limited vs. exempt via Mission Critical). Key Enhancements 1. Mission-Critical with Limits (Not Full Exemption) Currently, marking a workspace as Mission Critical fully removes it from workspace-level limits. Proposed change: allow Mission-Critical workspaces to still have configurable limits. Today: Mission Critical → no limit (full exemption) Proposed: Mission Critical → optional higher/custom limit (e.g., 30–50%) This avoids scenarios where critical workloads can unintentionally monopolize capacity. 2. Per-Workspace Custom Limit Override Introduce the ability to override the global workspace consumption threshold with a custom per-workspace limit. Example: Default capacity rule: 5% Workspace A: 8% Workspace B: 15% This keeps the global policy simple while allowing exceptions without using Mission Critical as a workaround. Value Reduces over-reliance on “Mission Critical = unlimited” Prevents critical workloads from becoming new noisy neighbors Provides precise governance aligned with real workload patterns Improves capacity stability without forcing isolation into separate capacities
