I want to be able to check the CU usage rate from more than 14 days ago in Microsoft Fabric Capacity Metrics. ... View more

We are currently using Power BI in an embedded fashion where the data and the analytics are surfaced to all our client in a Software-As-A-Service fashion in a multi-tenant setup with row level security. Basen on Microsoft's recommendation of implementing multi-tenancy in a secured way we have implemented service principle profile. And we found out that the Service Principle based query are not being differentiated in the Fabric Capapcity Metrics app. This differention is very vital for our tracking of the infrastructure usage and analysing infrastructure throttling.  ... View more

Enable individual users / freelancers to study and practice fabric with a per-user license similar to Premium Per User in Power BI. F2 is a price point that is too high for them. Strong limitations in time and resources available would make sense, but there should be a clear monthly cap that cannot be like the current F2. ... View more

To make it easy to filter workspaces, and also enable cost chargeback scenarios, it should be possible to apply Tags to workspaces. ... View more

I would like to be able to trigger specific thresholds for any item in Microsoft Fabric Capacity Metrics and have notifications from Activator. ... View more

Currently, Capacity Metrics are only available for Power BI Premium and Fabric capacities. However, users on Premium Per User (PPU) often face performance and memory-related issues without visibility into resource usage. It would be extremely helpful to have a lightweight version of Capacity Metrics or similar telemetry available for PPU workspaces to help diagnose refresh failures, memory pressure, and performance bottlenecks. This would empower users to self-diagnose and optimize their reports without needing to upgrade to full Premium capacity. ... View more

Microsoft Fabric needs auto-scale capabilities that allow us to define scale CU budgets by workspace & capacity.    I have outlined the Why, What, Who, Where, and How of this feature here: https://youtu.be/6pGrhGt7SXE   Why do we need AutoScale? End of the month end of quarter End of year   WHAT? Need CU’s to meet demand.   Who needs it? Data Engineering Data Analysts Data Scientists Report Consumers   Where should this be implemented? Workspace Capacity Tenant How should this be implemented? PAYGO Set budgets Allow Reservations ... View more

As a Fabric Administrator / Capacity admin in my organization, I have to work with many workspaces and not all of the assets (semantic modes, reports, dashboards) are built by an IT team. Some are built very jankly by novice users. Unfortunately the capacity is shared amongst all users and I have no way to limit the capacity consumption by workspace. That means that if a novice user deploys a bad data model to the capacity, all workspaces will essentially choke on itself and all users start complaining of slow dashboards and creating a negavtive impression of Power BI in the org.  I have been suggested by "Industry experts" to get another capacitity and assign all "development" workspaces to it, and vet datasets before deploying to production capacity. But again this only works if we have an army of IT resources (knowledgeable in Power BI people)  to vet ever single asset being deployed. But thats simply not the case. Additionally, we don't have unlimited budget to spend on Power BI / Fabric capacities unfortunately.  As such my idea is as follows: Somehwere in the admin portal / capacity settings, We add some kind of resource limitation setting by workspace. This way I can safely grant a novice developer a slice of the capacity without affecting the rest of my users on the tenant.  I could go on as to why this will benefit all of us in so many ways, but for the sake of brevity I'll leave it at that. If you'd like to understand the idea more please reach out to me.  ... View more

Today I got this:  So , after a long reading of information across learn.microsoft.com,  I assume for the moment that it is related to the fact that or home region is Spain where there is no Fabric functionality yet available and hence no trial can be created. But, as said, it is just an assumption. If the message would "cannot assign... due to <meaningful reason or missing condition> the Fabric support & I would loose much less time.  ... View more

Make it possible to see storage consumption at Item level in the Capacity Metrics App.   At the moment, we can only see storage consumption at Workspace level, and this makes it difficult to pinpoint exactly which items (lakehouses, warehouses) consume most storage in our workspace.   Displaying the storage size (gigabytes) at Item level would increase the usability of the Storage page in Capacity Metrics App. ... View more

The customer has expressed interest in automating the scaling process for Fabric capacities (F SKUs) that have been provisioned through the Azure portal. She referenced the existing functionality available for Power BI Embedded capacities (A SKUs), as described in the following Microsoft documentation: https://learn.microsoft.com/en-us/power-bi/developer/embedded/azure-pbie-scale-capacity#autoscale-your-capacity. She is seeking similar autoscaling capabilities—both scale-up and scale-down—for F SKUs. At present, we informed her that such automation is not yet supported for Fabric capacities in the Azure portal. The customer has expressed hope that this feature will be introduced in the near future, enabling her to manage Fabric capacity scaling with the same flexibility currently available for A SKUs.   ... View more

We need insights into the storage consumption of active files and soft deleted files.   The Capacity Metrics App's Storage page should have the ability to show the storage size of soft deleted files and the storage size of active files. And the total.   Today, it is not possible to differentiate between storage size of soft deleted files and active files in the Capacity Metrics App. ... View more

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.   ... View more

When reserving 64 CUs or more, we should be able to use the F64 benefits (Copilot, report readers without pro license, etc.) on any workspaces assigned to capacities which are backed by the reserved CUs.   Even if we create 2xF32, the workspaces assigned to those F32 capacities should get F64 benefits because these capacities are backed by 64 reserved CUs. ... View more

As a capacity administrator, it would be extremely helpful to see all the scheduled notebooks/refreshes/dataflows/pipelines/etc in one place -- ideally with a perspective on what impact these jobs may have on the overall capacity of the workspace. Right now, anyone can set up a job to run whenever they want... and most everyone just leaves it at default -- which means twice a day (1am Pacific Time and India Time) my capacity gets dropped to its knees. Knowing what's scheduled (and who scheduled it) will enable me to mitigate this issue. ... View more

Possibility to split an F64 capacity into smaller sub-capacities, while retaining F64 benefits (e.g. Power BI free readers can read content). The capacity admin should be able to set a "ceiling" on how much compute each sub-capacity is allowed to use. This will help to avoid compute consumption getting out of hand. The sum of the max limits ("ceilings") for each sub-capacity could exceed the max limit of the original capacity. So we could be "optimistic" when assigning limits to sub-capacities, if we choose. However, if the actual combined consumption of the sub-capacities hits the limits of the original capacity, then we would of course be throttled just like today. The purpose would be the ability to limit the resource consumption of some workspaces, by assigning them to a limited sub-capacity, while also keeping the benefits of being on an F64+ capacity. ... View more

The TimePointBackgroundDetail table records capacity usage at 30-second intervals. We would like to propose a feature improvement to enable data retrieval in 30-minute intervals. Alternatively, if there is another method to retrieve such data, we would greatly appreciate your guidance. ... View more

Microsoft should allow users to choose whether to enable smoothing rather than making it a mandatory feature. The smoothing capability should be an option, not an imposition from Microsoft. Smoothing introduces uncertainty, making it difficult to optimize costs for a Microsoft Fabric subscription. Additionally, smoothing is causing challenges across multiple areas, as highlighted in discussions within the Microsoft Fabric Community. Search - Microsoft Fabric Community ... View more

Have one Eventhouse for Fabric monitoring for each capacity and not for each workspace. That will dramatically reduce my costs and make it easier to correlare the different telemtry streams.  ... View more