In Microsoft Fabric / Power BI, when multiple reports are connected to the same semantic model, Git integration does not preserve or allow control over the default report associated with that semantic model after syncing to a new workspace. This results in unexpected behavior when downloading, modifying, and republishing semantic models—especially after pulling artifacts into a new workspace using Git integration.   Scenario / Reproduction Steps A report is created in Power BI Desktop and published to the Power BI Service. This creates Report 02 test and Semantic Model 02 test. Later, another report is created directly in the Power BI Service using the same semantic model. This creates Report 01 test, also linked to the same semantic model. Both Report 01 test and Report 02 test are linked to the same semantic model in the original workspace, and everything works as expected. Git integration is enabled for the workspace, and all artifacts are pushed to a Git repository. The same artifacts are then pulled into a new workspace using Git integration. Observed Behavior (Issue) In the new workspace, the semantic model automatically selects Report 01 test as the default report. The selection appears to be based on alphabetical order, not on the original or intended default report. When the semantic model is downloaded as a PBIX, modified, and republished: The changes are reflected in Report 01 test instead of the 02 test Report. This issue does not occur in the original workspace and happens only after Git pull into a new workspace. Impact Creates confusion for Fabric admins and developers managing multiple reports per semantic model. Causes unexpected report updates, leading to potential data integrity and governance concerns. Makes Git‑based CI/CD workflows unreliable when: Multiple reports share a single semantic model Default report selection matters for downstream operations. Git integration should provide a way to explicitly define or preserve the default report associated with a semantic model, instead of automatically selecting one based on alphabetical order.   Feature Request Add an option in Git integration / Fabric workspace settings to: Explicitly select or configure the default report for a semantic model or Preserve the original default report association when syncing across workspaces. ... View more

Pipeline schedules should not have an end date by default.   The current 1-year default end date introduces a hidden failure mode where pipelines silently stop running.   Most pipelines are intended to run indefinitely, so this default creates unnecessary operational risk and maintenance overhead.   Removing the default end date would make scheduling more reliable and predictable, while avoiding unexpected disruptions. ... View more

Today, Power BI semantic models (datasets/DAX) work well when Power BI is the only BI tool. However, many organizations use Databricks as their lakehouse and need consistent, governed metrics across multiple BI tools, ML pipelines, and APIs. When the semantic layer lives only in Power BI: Logic is duplicated across datasets and tools Governance/security (RLS/CLS, masking) is fragmented Schema changes in Databricks break reports ML/AI pipelines cannot reuse business logic from Power BI models Proposal: Enable native Power BI integration with Databricks Metric View ... View more

Since today, the subject of email sent based on subscriptions has changed and includes a static prefix "Power BI report subscription delivery", even if I set a particular subject for that email. I would like to have the option to disable that prefix. ... View more

Can you please update this so multiple people have ownership to update the subscriptions?  This causes dis-satisfaction when someone moves departments are leaves the company.  ... View more

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

Hello. Could you add an "Ends with" filter option, in the advanced options of the filter menu, just like in Excel : Hopefully this is understandable, I'm not sure of the names in english. Thank you. ... View more

It’s challenging and time-consuming for both new and experienced report creators to organize data when trying to split cards into categories. By introducing small multiples, it could be a familiar and easy way for report creators to intuitively categorize data, especially if they had more control over layout and formatting. ... View more

Distinct counts are the bane of our existence in big data.  Distinct counts over DirectQuery/DirectLake are not fast or efficient enough, and are very expensive from a compute and cost standpoint.  We need a re-aggregable approximate distinct count in Import Mode using HyperLogLog (HLL).  The idea would be to enable the creation/ingestion of a HLL sketch at the same dimensional grain as other user-defined aggregations so that the sketches can be dynamically merged/aggregated to produce an approximate distinct count.     Consider the following example where we need a distinct count of orders across channels and product groups.  Today, we would need to cache 4 unique intersections of data (1. Overall, 2. By Channel, 3. By Product Group, 4. By Channel & Product Group).  Not only is this compute intensive, but it forces us to create really terrible DAX to detect the user's reporting context and return the correct count.  In addition, it still doesn't allow for correct counts when users arbitrarily include/exclude members of a desired grouping (i.e. all product groups except "PRODUCT GROUP 02").  In an ideal world for this example, we would compute an HLL sketch at the Channel and Product Group level (image below), and either have a new DAX function like "HLLMERGE( <sketch> )" or enhance the APPROXIMATEDISTINCTCOUNT function to accept a column of sketchs, and this would dynamically merge the sketches in context to return the correct approximate distinct count. This would be a huge unlock to be able to dynamically reaggregate approximate distinct counts, as they are very difficult to manage today, and Power BI is well-positioned to do this.  It would be a powerhouse feature for big data users. ... View more

Input Slicer   Currently, users are able to choose from a list of filter operators in the dropdown.   It would be helpful to be able to restrict which filter operators are available in the drop down for end-users to choose from.   Case 1: Limit to a single filter operator - e.g. Is Any Case 2: Limit the filter operator to 2 operators - e.g. Is Any, Contains Any etc... ... View more

Idea Provide an option in Microsoft Fabric Oracle database mirroring to skip or exclude specific columns during replication, especially Oracle system-generated hidden columns (SYS_NC*). Problem Oracle mirroring fails during the initial load when tables contain hidden SYS_NC columns, raising ORA-00904. Currently, users must modify source Oracle databases (for example, drop extended statistics), which is not always acceptable in production environments. Benefit Enables mirroring without source-side schema or statistics changes Improves compatibility with enterprise Oracle databases Reduces onboarding blockers and support escalations Suggested Solution Allow column-level exclusion (or automatic exclusion of hidden columns) during initial load and ongoing replication. ... View more

Currently, Power BI subscriptions can only be managed at an individual report or user level. There is no centralized option for administrators to disable subscriptions at a capacity level or for specific workspaces.  Need a feature to turn off subscriptions for an entire capacity or selected workspaces would greatly improve governance, performance control, and operational efficiency. ... View more

Description: We are currently using Microsoft Fabric with Eventhouse -> Shortcut -> Lakehouse -> Snowflake Iceberg architecture. We have observed that datetime values are stored with millisecond precision (3 digits), for example: 2025-05-03 08:09:34.301 However, downstream systems like Snowflake Iceberg require microsecond precision (6 digits), such as: 2025-05-03 08:09:34.301000 This mismatch leads to compatibility issues when reading Fabric-generated Parquet files in Iceberg tables. Current behavior: Fabric stores datetime values with millisecond precision (scale 3), and there is no built-in way to enforce or convert to microsecond precision. Expected behavior: Fabric should support configurable datetime precision (e.g., 3, 6 digits) or automatically pad milliseconds to microseconds when required, ensuring compatibility with downstream systems like Iceberg. Impact: This is a critical blocker for integrating Fabric Lakehouse with modern data platforms like Snowflake Iceberg and affects enterprise adoption of Fabric in production environments.     ... View more

Hi, during the design of a task flow in a workspace it may happen that a task is accidentally deleted, but it doesn't it exist a manner to restore it: for a such case an undo feature would be very useful to restore the deleted task. Thanks ... View more

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've inherited some large complex Power BI semantic models that were migrated from SQL Server Analysis Services (SSAS) and many of these contain perspectives. I appreciate that they are an underused feature, but it's frustrating having to constantly switch to Tabular Editor to work with them and I'd much prefer if there was better support in both Power BI Desktop and the service for working with perspectives. We have many external customers for whom perspectives would be a good option, yet are put off when they realise they have to turn on the setting in Tabular Editor that says 'this is an unsupported feature' ... View more

The Problem Currently, when a Semantic Model refresh in Fabric/Power BI becomes unresponsive—often due to "zombie" queries on the source system, gateway bottlenecks, or locks on external data sources—the "Cancel" command is merely a request, not a command. As per Microsoft Support, the service waits for a "safe point" or an atomic commit before stopping. However, in many real-world scenarios, the refresh enters a "stuck" state that never reaches a safe point, forcing developers and capacity admins to wait for the 5-hour hard timeout. The Impact Capacity Waste: A "stuck" refresh continues to consume CU (Capacity Units) and memory for hours, unnecessarily inflating costs or throttling other critical workloads. Development Downtime: Developers are blocked from re-triggering a corrected refresh until the "stuck" one clears. Operational Risk: If a refresh is hogging a gateway or source connection, it can cause a "logjam" effect for all other scheduled items in the tenant. The Current "Workarounds" are Non-Viable Microsoft Support often suggests restarting the On-premises Data Gateway or reassigning the Workspace Capacity to kill a stuck process. However, these are not feasible solutions in a production environment because: Collateral Damage: Restarting a gateway or shifting capacity kills every other active refresh and connection in that environment. Service Interruption: It causes a cascade of failures for critical reports that are otherwise running perfectly, leading to widespread business disruption just to stop one "zombie" process. Administrative Overhead: It requires high-level permissions and causes manual cleanup work for admins across the entire tenant. The Proposed Solution: The "Force-Kill / Discard Shadow" Switch Since Power BI/Fabric utilizes a "copy-on-write" approach—where a new version of the model is constructed in the background while the original remains available for queries—there is a logical path for a forced interruption: Discard Shadow State: Introduce a "Force Kill" option that immediately terminates the Service’s tracking of that specific Refresh ID. Immediate Resource Release: Rather than waiting for the external query to return or the "commit" phase, the Service should immediately stop billing CUs for the process and mark the background "shadow" model for deletion. Source Termination: Trigger a "Cancel" signal to the Data Gateway or the SQL/Data Lake source to attempt to kill the session at the source, but do not make the Service wait for confirmation from the source before releasing the Fabric Capacity. The Argument: Data Integrity is Not at Risk The standard justification for this delay is "maintaining data integrity." However, Power BI/Fabric utilizes a shadow-refresh (copy) mechanism. Since the refresh is building a new version of the model in the background while the original remains live for users: Force-killing the refresh should simply discard the background shadow copy. The original model remains untouched, so no data corruption can occur. There is no logical reason to wait 5 hours to "safely" discard a model that is already failed/stuck. Why this is feasible: Because the original dataset remains untouched until the very final "commit" phase, "killing" a refresh during the processing phase should carry zero risk of data corruption to the live model. We are simply asking for the ability to "toss out the draft" immediately rather than waiting 5 hours for the draft to realize it's stuck. Conclusion In the era of Fabric's "Pay-as-you-go" and "Capacity-based" pricing, being forced to pay for 5 hours of a stuck refresh is a significant pain point. We need a "Kill Switch" that prioritizes Capacity Governance over "Waiting for a safe point" when the developer knows the refresh is already a failure.   #Semantic Model, #Capacity Management, #Developer Experience, #Refresh. ... View more

Currently for customers who purchased Azure from CSP provideres need to reach out to the provider to get the emission information.    https://learn.microsoft.com/en-us/power-bi/connect-data/service-connect-to-emissions-impact-dashboard But the options for the CSP provider to share the data are below: Providing customer‑specific exports or reporting packs from EID visuals and reports ·   Using exported EID data to create offline or downstream customer‑specific reports   We would request either one of the below solution to be implemneted so that the CSP providers can share the emissions to the individual customers .  OPTION 1 (preferred option) As a CSP, we are in need of a filter in the Emissions Impact Dashboard (EID) by specific customers/tenants. At the moment, there is no option to apply such a customer/tenant filter. While we could add a Tenant–Subscription mapping to the semantic model to enable this, the model would need to be updated. Since the EID is delivered as a template app, it’s not possible to download (see screenshot) or modify the semantic model to include this mapping. Allowing this option would give us what we need to help our customers in most simple way.       OPTION 2  An alternative solution would be to let you add a customer/tenant filter directly to the report. Our preference, however, is to gain access = have to ability to click"Open" to both the semantic model and the report so we can customize them as needed. This would also allow us to share the report with our customers without manually applying filters and exporting it to PDF or PowerPoint for distribution.         ... View more

It would be great to have the option to use visual calculations in card visual reference labels ... View more