During Lakehouse deletion operations in Microsoft Fabric, users may observe that the associated SQL Endpoint and Semantic Model are not automatically removed. These orphaned artifacts may cause downstream deployment errors or stale resource references.   There is one available API to remove it, but it is not very user friendly and also requires admin rights so developers cannot do this on their own. It is mentioned here: Solved: Can't delete orphaned lakehouse SQL analytics endo... - Microsoft Fabric Community   The idea is to make this option available in the UI or at least provide more user friendly ways to do it. ... View more

Considering the most powerful and versatile machines are being built on ARM processors and many developers preferring these machines due to the extended battery life, or performance per watt, I think it would be critical for Microsoft to start developing Power BI Desktop to be fully compatible with ARM64 processors. Windows ARM with a snapdragon processor is a great machine. It is where all machines are going. It's time for Power BI Desktop to get up to speed with everything else. ... View more

To fix inconsistencies in analytic settings, functionality needs to be enhanced to ensure they are on par with other visual component enhancements made for Cartesians, and additional settings for scatter charts is also necessary. Report creators will find it easier to format and customize settings to align with the overall look and feel of their reports. ... View more

Currently the only option for connecting to a lakehouse using a cloud connection is an organisational account. Adding in Service Principal as an option would avoid the reliance on single user accounts and would bring the lakehouse connector into parity with the warehouse connector. ... View more

The Specific Workflow: This request is about the "Publish" workflow from the Power BI Desktop application when a developer overwrites an existing dataset in the Power BI Service. The Business Goal for Enterprise Governance: As analytics leaders, we work to enforce strong governance by using secure, non-personal identities (Service Principals) for data source credentials. This is a best practice for ensuring security, compliance (e.g., SOX), and operational stability in our finance analytics environment. The Current Challenge: The current behavior in this specific workflow creates a significant challenge for this governance model. When a developer clicks "Publish" from Power BI Desktop to update an existing dataset, the service: Assigns dataset ownership to the human "publisher" (the user logged into Power BI Desktop). This ownership change often leads to the invalidation of the existing data source credentials, even if they were correctly configured to use a Service Principal. This then requires the developer to manually go to the Service, "take over" the dataset, and re-enter credentials. The Impact on Enterprise Adoption: This behavior creates friction for teams trying to follow best practices: Hinders Automation: A single manual publish from Desktop can disrupt scheduled refresh chains that rely on the Service Principal, causing data non aggiornati. Creates Compliance Friction: It inadvertently encourages developers to use their personal credentials (which are not invalidated on publish), simply to avoid this issue. This undermines the goal of using secure, governed Service Principals. Adds Operational Overhead: It adds a manual, error-prone step to what should be a simple update process. Suggested Enhancement: We would welcome a mechanism to decouple the Power BI Desktop publisher from the ownership of the data source credentials. Ideally, when a user clicks "Publish" from Power BI Desktop to an existing dataset, the service should: Detect that functional credentials (especially for a Service Principal) are already set. Preserve these existing credentials by default, allowing them to remain active. The publisher's identity should not automatically override the credential ownership. The Service Principal should remain the owner of its credentials. This enhancement would be a major step forward in aligning the core Power BI Desktop workflow with the enterprise-grade security and governance practices that Microsoft also champions. ... View more

It would be extremely helpful to have a built-in feature in Power BI that allows administrators to identify inactive users segmented by license type (Free, Pro, Premium Per User, Embedded, etc.). ... View more

Re: API Call for Workspace Contacts in Workspace S... - Microsoft Fabric Community   Retrieve workspace contacts from workspace settings via REST API Call   I need to Track Capacity backed workspace contacts across the organization in a Workspace catalog So that i can ensure each workspace is properly administered and managed       ... View more

Power BI Semantic Data Modeling - More than one relationship.  If this option is enabled, we can avoid creating more calcualted columns to define the key for establishing the relationship.  ... View more

Paginated reports - please make it available in Pro as well as Premium .. thank you ... View more

Description: Currently, only the connection owner can delete a Cloud Connection in Fabric / Power BI. Even tenant admins or Fabric capacity admins do not have permission to remove, reassign, or take ownership of connections they didn’t create. This limitation causes several operational and governance challenges: When a user leaves the organization, their personal cloud connections become orphaned and cannot be deleted. Admins cannot clean up unused or stale connections, leading to clutter and confusion. Governance policies cannot be fully enforced, as there’s no way to centrally manage ownership or lifecycle of connections. It increases dependency on individual users rather than service principals or admin accounts. Proposed Enhancement: Enable Fabric Admins / Power BI Tenant Admins to: View all cloud connections across the tenant, regardless of ownership. Delete or transfer ownership of connections to another user, group, or service principal. (Optional) Bulk manage connections via Admin APIs or the Fabric Admin Portal, including audit and export capabilities. These capabilities should align with existing admin rights for datasets, workspaces, and gateways, ensuring consistent governance control. Benefits: Prevent orphaned or stale connections. Simplify tenant clean-up and governance. Enhance compliance and lifecycle management. Reduce dependency on individual user accounts. Align Cloud Connections with the existing Power BI admin model (datasets, gateways, capacities). Category: Admin & Governance / Data Connectivity ... View more

Description: In Power BI Report (PBIR) metadata, every visual already has an isHidden property that controls its visibility. Today, however, this property can only be set manually in the UI (via the Selection pane). There is no way to drive this property dynamically using a DAX expression. This is a major limitation because one of the most common use cases for Bookmarks is to simulate conditional visibility (show/hide visuals depending on user selection or business logic). While bookmarks work, they are cumbersome, static, and hard to maintain at scale. Proposal: Enable a new “Visibility” binding for visuals in the format pane, where authors can assign a DAX measure (fx) returning TRUE/FALSE (or 0/1). If the measure evaluates to TRUE → visual is shown. If FALSE → visual is hidden (not rendered). Benefits: Much more flexibility for UX/UI design. Reduces dependency on complex bookmarks. Simplifies scenarios such as: Show a chart only if a slicer is selected. Hide detailed visuals until a KPI passes a threshold. Display different layouts per user role or context. Aligns with the existing isHidden property already in PBIR at visual level, making it available for dynamic scenarios. Why now Conditional visibility is a frequent request feature in the community. Users of other Microsoft data platform solutions, such as Power Apps, are accustomed to having the ability to modify this property. PBI developers already simulate this via workarounds (blank measures, bookmarks, overlaid shapes with managed transparency).   A native solution would make reports more dynamic, performant, and easier to maintain.   @Miguel_Myers  ... View more

Description: Currently, Fabric Pipelines connect to native Fabric Lakehouses and Warehouses using user-bound tokens that expire approximately every 90 days. When these tokens expire, pipelines that invoke Warehouse or Lakehouse activities fail with authentication errors. The only workaround today is to manually open and re-save each pipeline, which regenerates the token. This approach becomes impractical and error-prone as the number of pipelines and workspaces grows across enterprise environments. Impact: Pipelines fail unpredictably in production after token expiry. Requires manual intervention across dozens or hundreds of pipelines. Causes disruption to scheduled ETL/ELT workflows. Inconsistent behavior compared to external connectors, which already support Workspace Identity. Typical Error Message: ErrorCode=UserAuthFailedToGetToken Message=Failed to get User Auth access token. AADSTS700003: Device object was not found in the tenant directory. This occurs after token expiration and causes pipelines to fail until re-saved. Proposed Enhancement: Add support for Workspace Identity Authentication for native Fabric Lakehouse and Warehouse connections in Pipelines. This would allow Fabric pipelines to: Authenticate using the workspace’s managed identity (non-user-dependent). Automatically renew tokens without user re-login. Align authentication behavior with Dataflows Gen2, Notebooks, and other Fabric connectors that already support Workspace Identity. Business Justification: Enterprise tenants typically operate multiple Fabric workspaces and dozens of pipelines per domain. Removing token dependencies will: Ensure reliable, unattended execution of production data pipelines. Eliminate recurring manual maintenance. Improve operational scalability and governance consistency. ... View more

Current Problem Different departments create reports in separate workspaces (e.g., Sales, HR, Finance). Each report contains pages segmented by audience (executive, manager, operational). Current functionality doesn’t fully solve this scenario: Workspace App → allows audiences, but only within a single workspace. Org App → allows multiple apps per workspace, but cannot combine pages across workspaces. As a result, to build a corporate app (e.g., for the Board) that consolidates only executive-level pages from each department, we must either duplicate PBIX files or create separate versions of reports, leading to redundancy and maintenance overhead. Suggested Feature Introduce a new capability, for example: “Corporate App with Cross-Workspace Pages” or “Cross-Workspace Page Selector.” This feature would allow: Selecting specific report pages across multiple workspaces and aggregating them into a single Org App. Example: “Executive View – Sales” (Sales Workspace) + “Executive View – HR” (HR Workspace) → App “Board of Directors.” Defining page-level visibility rules by audience profile (without duplicating PBIX). Executives → see only executive summary pages. Managers → see management pages. Operational staff → see detailed tactical pages. Maintaining a single source of truth → updates to the original PBIX automatically flow into all apps where its pages are used. Benefits Reduced redundancy → no need for multiple PBIX files per audience. Centralized governance → reports remain in their original workspaces, respecting ownership and security. Personalized experiences → each audience gets a tailored app containing pages from different workspaces. Scalability → leadership can access a single consolidated app with executive views across all departments. Idea Summary 🔹Today: PBIX files must be duplicated or apps limited to a single workspace. 🔹With the new feature: build custom multi-workspace apps by selecting specific pages per audience, without duplication. -------------------------- PT/BR Proposta de Nova Funcionalidade para Power BI – "Cross-Workspace Page-Level Security nos Apps" Problema atual Departamentos diferentes produzem relatórios em workspaces distintos (ex.: Comercial, RH, Financeiro). Cada relatório possui páginas segmentadas por público (diretoria, gerência, operacional). As funcionalidades existentes não resolvem o cenário: Workspace App → permite um único app com audiências, mas só dentro de um mesmo workspace. Org App → permite múltiplos apps por workspace, mas ainda não mescla páginas/reportes entre workspaces. Resultado: para criar um app corporativo único (ex.: Diretoria) que agregue apenas páginas executivas de cada departamento, é preciso duplicar relatórios ou criar PBIX separados, gerando redundância, retrabalho e manutenção complexa. Sugestão de Funcionalidade Criar um recurso chamado, por exemplo: “App Corporativo com Páginas Cruzadas” ou “Cross-Workspace Page Selector”. Esse recurso permitiria: Selecionar páginas específicas de relatórios em diferentes workspaces e agregá-las em um único Org App. Exemplo: Página “Visão Executiva – Comercial” (Workspace Comercial) + Página “Visão Executiva – RH” (Workspace RH) → App “Diretoria”. Aplicar regras de visibilidade por perfil no nível de página, sem precisar duplicar PBIX. Diretores → veem apenas páginas executivas. Gerentes → veem suas páginas de gestão. Operacionais → veem suas páginas táticas. Manter a fonte única do relatório original → qualquer atualização no PBIX se reflete automaticamente em todos os apps que utilizam suas páginas. Benefícios Menos redundância → elimina necessidade de múltiplos PBIX por público. Governança centralizada → páginas continuam no workspace de origem, respeitando ownership e segurança. Experiência personalizada → cada perfil recebe um app customizado com páginas de diferentes workspaces. Escalabilidade → diretoria pode ter um app único consolidando visões executivas de todos os departamentos. Resumo da Ideia 🔹Hoje: ou duplicamos PBIX ou limitamos apps a um workspace. 🔹Com a nova funcionalidade: montar apps personalizados multi-workspace, selecionando páginas específicas por público, sem duplicar relatórios. ... View more

It would be very useful to have a centralized view for managing page properties, particularly filters. Instead of opening each page individually to configure or modify filters, users could manage all page filters and related settings in one place. This would save time, ensure consistency, and make report maintenance much more efficient. ... View more

The only step in my deployment for test and production switching that is still unsupported are DirectLake semantic model sources. I have been successful in some hacky fixes where I can parameterize the directlake source but it then breaks editing of the directlake semantic models.   Specifically toggling the url in the semantic model expression: expression 'DirectLake - kusa_accounting' = let Source = AzureStorage.DataLake("https://onelake.dfs.fabric.microsoft.com/workspaceid/lakehouseid", [HierarchicalNavigation=true]) in Source   If we could usue a parameter here, normal Deployment Pipeline rules could change this. Better would be detecting this data source and allowing for setting the url in a data source pipeline rule would save having to create a parameter myself.   Alternatively, I'm using Variable Libraries in my other areas of deployment, and if we could specify this url from the Variable Libraries would work. This would probably be better since I find Variable Libraries more flexible and usable even without Fabric Deployment Pipelines. ... View more

We would like to be able to use Fabric workspace (WS) management ID to connect to Sharepoint Online (SPO) folder (i.e. any Excel file located within the SPO site). Currently we can connect to and extract any SPO list using WS Managed Identity, but we cannot do the same for any file located within our SPO site, because apparently it's still not supported. Also, apparently using service principal to connect from a Fabric WS to Sharepoint Online folder is not supported either, which means we can only connect with either a service account or a user account, which is no nearly as secure or maintainable as WS Managed ID, because OAuth connectors will need updates every time the passwords expire . ... View more

Increase the supported unique value limit for slicers and parameters beyond 1,000. ... View more

Anyone who uses PowerBI long enough has had a PBIX with 50-60 measures and it has become time consuming and tedious to mantain. In Excel you can do a quick find/replace to edit several formulas - in PowerBI you need to select each one individually. An "excel-like" interface for editing measures would save a lot of time! This would take PowerBI to the next level regarding productivity. I've prepared a mockup for this as well as a DAX Editor. Let me know what you think. Mockup: https://i.imgur.com/z6TBOQb.png?1 ... 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