Hello team, I would like to propose an improvement regarding item management within Microsoft Fabric workspaces. Currently, it is possible to select multiple items and move them into a folder, which is very helpful for organizing content. However, this same multi-selection capability is not available for deleting items, meaning users must delete them one by one. Proposal Enable bulk deletion of items using the same multi-selection mechanism that is already available for moving items. Motivation In real-world scenarios, especially during development and iterative workflows: Users often create multiple versions of assets (e.g., notebooks, pipelines, etc.) while refining solutions. Once a final or optimized version is achieved, previous iterations need to be cleaned up. Performing this cleanup item by item is inefficient and time-consuming. While it is technically possible to automate this via code or APIs, having this functionality directly in the UI would significantly improve usability and productivity. Risk considerations I understand that bulk deletion can introduce risks. To mitigate them, an approach similar to Azure could be followed: Confirmation prompts (e.g., typing the item name or workspace name). Soft delete or recovery mechanisms, where applicable. Role-based restrictions (e.g., allowing bulk delete only for specific roles such as Admin or Contributor). Suggested approach Extend the existing multi-selection UI to support a “Delete” action. Apply appropriate safeguards (confirmation steps, role validation). Optionally, provide visibility of affected items before confirmation. Expected benefits Faster cleanup of development artifacts Improved user experience and productivity Consistency with existing multi-selection capabilities Reduced friction in iterative development workflows Closing This enhancement would align perfectly with how users already interact with items in Fabric and would remove a small but meaningful point of friction in daily usage. I would be happy to share more detailed scenarios if helpful. Thank you for your continued innovation.   ---------------   Hola, equipo, Me gustaría proponer una mejora en lo que respecta a la gestión de elementos dentro de los espacios de trabajo de Microsoft Fabric. Actualmente, es posible seleccionar varios elementos y moverlos a una carpeta, lo cual resulta muy útil para organizar el contenido. Sin embargo, esta misma función de selección múltiple no está disponible para eliminar elementos, por lo que los usuarios deben eliminarlos uno por uno. Propuesta Permitir la eliminación masiva de elementos utilizando el mismo mecanismo de selección múltiple que ya está disponible para mover elementos. Motivación En situaciones reales, especialmente durante el desarrollo y los flujos de trabajo iterativos: Los usuarios suelen crear varias versiones de los activos (por ejemplo, cuadernos, flujos de trabajo, etc.) mientras perfeccionan las soluciones. Una vez que se alcanza una versión final u optimizada, es necesario limpiar las iteraciones anteriores. Realizar esta limpieza elemento por elemento resulta ineficiente y consume mucho tiempo. Si bien técnicamente es posible automatizar esto mediante código o API, disponer de esta funcionalidad directamente en la interfaz de usuario mejoraría significativamente la usabilidad y la productividad. Consideración de riesgos Entiendo que la eliminación masiva puede conllevar riesgos. Para mitigarlos, se podría seguir un enfoque similar al de Azure: Mensajes de confirmación (por ejemplo, escribir el nombre del elemento o el nombre del espacio de trabajo). Mecanismos de eliminación lógica o de recuperación, cuando corresponda. Restricciones basadas en roles (por ejemplo, permitir la eliminación masiva solo para roles específicos como Administrador o Colaborador). Enfoque sugerido Ampliar la interfaz de usuario de selección múltiple actual para que admita una acción de "Eliminar". Aplicar las medidas de seguridad adecuadas (pasos de confirmación, validación de roles). Opcionalmente, proporcione visibilidad de los elementos afectados antes de la confirmación. Beneficios esperados Limpieza más rápida de los artefactos de desarrollo Mejora de la experiencia del usuario y de la productividad. Coherencia con las capacidades de selección múltiple existentes Menor fricción en los flujos de trabajo de desarrollo iterativo. Cierre Esta mejora encajaría perfectamente con la forma en que los usuarios ya interactúan con los elementos en Fabric y eliminaría un pequeño pero significativo punto de fricción en el uso diario. Con gusto compartiré escenarios más detallados si resulta útil. Gracias por su continua innovación. ... View more

I ran into an issue with scheduled refresh on a dataset that uses Personal Cloud Connections with SharePoint files. In Power BI Desktop, all queries refreshed fine. I then published to the Service and set up scheduled refresh. In app.powerbi.com, the dataset showed errors like “scheduled refresh is disabled because at least one data source is missing credentials,” even though all my SharePoint cloud connections and credentials were valid. After a lot of troubleshooting I discovered the real root cause: in Power Query I had added one new table whose Source step still pointed to a local desktop path (C:\…) instead of a SharePoint URL. Every other query used SharePoint URLs and Personal Cloud Connect, but this one local file prevented the entire dataset from refreshing. The Service error message never indicated that the problem was a local file path mixed in with cloud sources, so I had to manually inspect each query’s Source step to find it. Feature request: When a dataset contains a mixture of cloud‑connected sources (e.g. SharePoint/OneDrive) and unsupported/local sources (e.g. local file paths without a gateway), please show a specific, actionable error message. For example: “One or more of your data sources is not cloud‑connected (for example, a local file path). Go back to your Power BI Desktop model and check the Source step for each query.” Ideally, the message would either list the offending queries or at least clearly call out that a local/not‑cloud‑reachable source exists. This would save a lot of time versus the current generic credential/gateway error, especially for models that mostly use cloud sources with Personal Cloud Connections. ... View more

Currently when there is an outage as per the tenant setting Service interruption notifications - Microsoft Fabric | Microsoft Learn customer will erceive notification for the following reliability scenarios: Open report reliability Model refresh reliability Query refresh reliability Notifications are sent when there's an extended delay in operations like opening reports, semantic model refresh, or query executions. After an incident is resolved, you receive a follow-up email.   As the current tenant setting is limited to reports and semantic models, we would like to have an option that enables customers to receive all outage-related notifications for both Microsoft Fabric and Power BI. ... View more

Today, when creating an Activator rule from a Power BI visual, we can set the evaluation frequency (for example, 1 evaluation per hour), but we cannot control when those evaluations happen during the day or week. Two related gaps:   No time window control. Alerts run 24/7 at the chosen frequency. There is no way to scope evaluations to specific days or hours of the day. No start time control. The evaluation cycle appears to anchor to the Activator creation time, so the rhythm of the schedule depends on when the rule was saved rather than a business-meaningful anchor the user picks.   Proposal Extend the frequency configuration to also support: Time windows: pick the days of the week and the hour range during which the alert should evaluate (for example, Mon to Fri, 09:00 to 18:00). Custom start time: let users set an explicit start time for the evaluation cycle instead of defaulting to the creation timestamp.   Example scenarios A retail operations team only needs inventory alerts during store hours. A support team wants SLA breach alerts only during staffed shifts, not overnight. A finance team wants market-hours-only evaluations for trading dashboards.   Why it matters Cuts noise from off-hours alerts that no one is around to act on. Reduces unnecessary evaluation volume and the capacity it consumes. Aligns Activator's behavior with how teams actually operate. ... View more

Customer would like to know more details on how the Average utilization% is calculated in the Capacity Metrics app. As per the official documentation: Understand the metrics app compute page - Microsoft Fabric | Microsoft Learn, it is only mentioned that the Average Utilization% is the Average utilization percentage of the capacity. The utilization is calculated with respect to base capacity units of the capacity and does not consider autoscale capacity units. However, this doesnot mention any formula used to calculate Average Utilization. Customer is using this formula as per the above definition to calculate the Average utilization:  However, this doesnot match with the Average utilization% values displayed on the Capacity Metrics app. Hence, it would be great to display the formulas used to calculate the average utilization in the Metrics app or in the documentation for Customer reference. ... View more

It would be really useful to have security settings to show or hide individual report pages. Currently, audiences control access only at the report level, not per page. ... View more

Please create a directory in Lakehouses where we can put folders and files that we wish to check in to Git.   For example, we would like to put configuration files in a Git-tracked folder.   Fabric Deployment Pipelines should also be able to deploy this directory and its contents to Test and Prod. ... View more

Provide a simple way to write formulas that work with the data displayed in a visual. For example, the running total of a measure in a table or in a chart according to the sort order of the visual should be something like this: Running Total = ReportData[Sales] + PREVIOUS ( ReportData[Running Total] ) Where ReportData is the content of the current visual, Sales and Running Total are the names of the columns in the current visual. The user is not expected to know the model content, the calculation can be executed on top of any data currently being displayed. More details about a proposal for visual calculations in DAX here: https://www.sqlbi.com/articles/a-proposal-for-visual-calculations-in-dax/ ... View more

Working scenario: In an existing report the matrix Bold formatting worked as expected. After selecting/unselecting bold in row headers works as expected. When opened a new page and created a new matrix visual selecting bold/unbold in row header and row sub totals work as expected. However when created a new report with the same model and exact same columns the matrix visual automatically bolds the first column. When additional column is added it appears has bold but only the last column works as expected. If row header is toggled between bold or unbold, it just bolds/unbolds the last column . If additional column is added and select row subtotals it bolds the total along with the first column. We received an update from Engineering team informing that it is by design as of now "The subtotal row headers are always rendered with the bold font family regardless of the 'Row Headers' bold toggle. The toggle doesn't control subtotal row header font which has its own forced bold styling". The working and non working has a different theme which explains why the old/new PBIX are behaving the way they are. This needs to be changed and bold formatting should work as expected in the existing report. ... View more

Enable the Variable Library as a centralized location for storing all environment‑specific variables, allowing us to adjust them for promotion scenarios (e.g., from dev to prod) without relying on deployment pipelines.   It would be ideal if semantic model parameters or data sources could reference a Variable Library, similar to how deployment pipelines handle variables today. When using CI/CD Option 1 — Git‑based deployments — it isn’t possible to hardcode environment‑specific values or data sources, since these differ across environments. Example: If I build a report in a dev workspace/branch that uses a dev data source, and then promote it to a prod workspace/branch via PR, I have no way to automatically switch the data source to the production version. I would need to submit an additional PR just to update the prod branch, resulting in the same report with different hardcoded sources.  ... View more

Product Microsoft Fabric Area Data Warehouse / SQL Type Bug / UX issue Description In Microsoft Fabric Warehouse, queries using CTEs behave inconsistently between execution and UI-based view creation. A SELECT statement with CTE runs successfully, and the following also works when executed manually:   ``` CREATE OR ALTER VIEW schema.view_name AS WITH ... SELECT ... ``` However, using the “Save as view” button on the same query fails with the error: > Incorrect syntax near the keyword 'WITH'. This error is misleading. The SQL syntax is valid, and the view can be created successfully when CREATE OR ALTER VIEW is executed explicitly. The failure appears to be caused by how the UI wraps the query internally. Impact Valid SQL is rejected only via the UI Users are led to believe CTE is unsupported in Warehouse views Results in unnecessary investigation and loss of trust in the authoring experience Expected behavior “Save as view” should preserve valid CREATE VIEW semantics, or Clearly communicate any limitations instead of returning a misleading syntax error   ... View more

Support the creation of DAX calculation groups in Power BI Desktop - otherwise Power BI can only consume calculation groups created in Analysis Services, whereas it would be very useful to have this feature in any Power BI model. Even just a simple text window with a script would be fine. You can clean up the UI later. Thanks. ... View more

Summary Add an advanced context-menu option on standard visuals that allows users to view and edit the visual’s JSON directly from the Power BI canvas. Problem Statement Today, advanced users increasingly rely on editing visual JSON to apply formatting or behavior changes that are not currently exposed through the Power BI Desktop UI. The only way to do this is by saving the report as a .pbip project and manually editing the visual JSON files. While powerful, this workflow: Is unintuitive and error-prone for many users Requires leaving the Power BI canvas and working directly with project files Discourages experimentation due to the risk of breaking the report Creates a barrier for users who are comfortable with JSON but not with the .pbip file structure or source control workflows As a result, many users are editing .pbip files simply to unlock visual customizations that feel like they should be available in-context. Proposed Feature Introduce an Advanced option in the visual right‑click context menu (or Format pane) such as: Right‑click visual → Advanced → Edit Visual JSON This would: Open a modal or side-pane JSON editor scoped only to the selected visual Display the current visual definition JSON (read/write) Validate changes before applying them Allow users to revert to the previous state if the JSON is invalid Optionally, this could be gated behind: A preview feature flag A warning or “advanced users only” acknowledgment Read-only mode with an explicit “Enable Editing” toggle Benefits Improves productivity by keeping advanced customization in the canvas where users are already working Reduces friction compared to editing .pbip files directly Encourages experimentation with faster feedback and safer iteration Aligns with real-world usage—many users are already editing visual JSON today, just through unsupported workflows Future-proofs the product by allowing advanced users to access new or undocumented properties without waiting for full UI support Why This Matters Power BI already exposes the full visual definition internally; this feature simply makes it accessible in a safer, more discoverable, and more user-friendly way. Similar to how Tabular Editor exposes advanced model metadata, this would serve power users without impacting the default experience for most users.   This capability would significantly reduce reliance on .pbip file manipulation while empowering advanced users to push Power BI visuals further. ... View more

Power BI displays numbers correctly based on regional settings (e.g., comma as decimal separator), but copying values exposes the raw floating‑point value with a dot separator. Please add an option to copy the formatted (displayed) value so locale, rounding, and readability are preserved. ... View more

If multiple users want to work with the same Dataflow Gen 2, they currently need to take over ownership, which can be challenging for users in the future. It would be helpful to have an option like workspace permission support, allowing users to edit Gen 2 without needing ownership. ... View more

Variable Library string values can contain invisible/non‑printable characters. When used in pipelines (e.g. Workspace or Dataflow references), this can cause opaque runtime failures surfaced as generic 500 “token access” errors. Suggestion: warn or block non‑printable characters (especially leading/trailing), or surface a clear validation error instead of InternalServerError. ... View more

The data preview in the Results section of a SQL query (in either a warehouse or lakehouse) is very difficult to read as it is currently set up. It would be massively improved by implementing the following: Show the total row count at the bottom of the Results rather than just showing the row preview limit (10,000) if the actual row count goes beyond this Ideally, this would show something like Columns: 4  Rows: 56012  Rows Displayed: 10000 Allow columns in the Results to be dragged wider so it's possible to read the full column names and data As far as I can see, there's currently no way to do this in Fabric ... View more

Dark Mode for Power BI Service and Fabric. ... View more

Please add workspace settings >> Data Warehouse >> Collations to the Fabric rest API config.   This is the only way make Lakehouse SQL Endpoint Case insensitive, it is a must for customers coming from a SQL background.  Currently I deploy workspaces by automation, then manually change the collation then deploy Lakehouses & Warehouses which is time consuming and annoying....   This is pre-req before the terraform provider could also be updated to set.   Thanks, Darren ... View more