Make it possible to change owner on all Fabric items types. Both through API and in user interface (UI). Otherwise, we will get issues when the item owner leaves the organization. ... 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

Make the Workspace the owner of all the Fabric items inside the workspace. So we don't need to worry about what happens to the items when a user owning an item leaves the organization. ... View more

Allow recovery of artifacts that have been deleted from a workspace; dataflows, pipelines, notebooks, etc.. Have a recycle bin per workspace for quick navigation & recovery. ... View more

Make it possible to add multiple owners on all Fabric items types. Both through API and in user interface (UI). To decrease risk of item unavailability when a single item owner leaves the organization. ... View more

  Currently, colors are automatically assigned randomly.  It would be nice if your dev workspace was always blue, and your prod was always pink for example.  Then you'd have a good visual as to where you're working in. ... View more

Currently the .gitignore file is, well, ignored. Ideally we would have a way of using gitignore to avoid committing local developer objects e.g. sandbox lakehouses that developers use for testing out different load patterns. ... 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

Ability to take ownership of items as a Service Principal with the Fabric APIs. The functionality is available for Fabric data warehouses. ... View more

  The current inability to parameterize connections in pipeline activities means we need to use the same identity to run the pipeline activities across dev/test/prod environments.   This means the same identity needs to have write access to all environments dev/test/prod.   This creates a risk that code executed in dev writes data to prod, because the identity has write access to all environments.   Please make it possible to parameterize the connection of all pipeline activity types, so we can isolate the identities for dev/test/prod and make it physically impossible for a dev pipeline activity to write data to prod environment.   Here's an overview based on my trials and errors:   Activities that do have "Use dynamic content" option in connection:   - Copy activity  - Stored procedure  - Lookup - Get metadata - Script - Delete data  - KQL   Activities that do not have "Use dynamic content" option in connection:   - Semantic model refresh activity  - Copy job - Invoke pipeline - Web - Azure Databricks  - WebHook - Functions - Azure HDInsight  - Azure Batch  - Azure Machine Learning ... 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

I have three workspaces -- DEV, UAT, and Prod.  Within these workspaces, I have several independent projects - each with their own deployment schedule and processes. The current pipeline process makes it nearly impossible to deploy these projects independently of one another because a human being has to rebuild the pipeline for every deployment.  Not only that, but the difficulty in rebinding notebooks, semantic models, etc as part of the deployment makes the whole pipeline process a non-starter. It would make the deployment pipeline process much easier/better if I could: 1) specify what data pipelines, data flows, notebooks, semantic models, reports, environments, and lakehouses need to move between workspaces 2) specify what data within lakehouses needs to be copied 3) rebind any notebooks, semantic models, and reports In short, I want a pipeline package for each project that I can define within the source workspace(s) ... View more

One of the real potential benefits of this product is that it combines a set of otherwise separate tools. However, it is important that it doesn't end up looking like a set of separate tools cobbled together. Yet another area where this is apparent is where some tools use case-sensitive naming, others don't. I believe that case-sensitivity has absolutely no place in an analytic set of tools like this. It's simply never human-friendly. All case-sensitivity gives you is the ability to have two things in the same scope with the same name, only differing by case. That's never been a good idea, and is a result of lazy coding in the past, particularly from Unix/C backgrounds. https://blog.greglow.com/2018/12/04/opinion-case-sensitivity-is-a-pox-on-computing/ Case-preservation is critical (i.e. remember the case that something is defined with and always return that), but case-sensitivity should not be apparent to users. At present, there is a mix amongst the tools on how case-sensitivity is handled. This needs to be cleaned up. ... View more

The ability to have workspace-level parameters (similar to ADF) would be a nice way of standardizing naming conventions, share parameters between services, etc ... View more

I’d like to suggest adding the ability to configure quotas for Microsoft Fabric workspaces, applicable to both new and existing workspaces. This feature would allow administrators to set limits on compute capacity (CUs) and storage usage, helping organizations better manage resources, control costs, and prevent overconsumption. Having workspace-level quota controls—similar to those in other Azure services—would greatly enhance governance and operational efficiency across larger environments where multiple teams or departments share Fabric capacity. ... View more

A report or Admin API is required to provide details on capacity consumption by each workspace, enabling the distribution of billing to respective teams. If possibile, Microsoft should enhance the Fabric Capacity Metrics app by adding a visual that displays workspace-level capacity consumption alongside artifact-level consumption. This improvement would assist users managing different teams (Finance, Sales, etc.) in allocating billing based on actual usage rather than distributing costs equally across all teams, regardless of usage.   ... View more

We have complex RLS and audiences in our PBI/Fabric Apps.  We need to be able to login as a user to view their experience.  There is no worse-way to get user adoption then to send a user to a dashboard just to find out there is something missing with their permissioning and they get an error or a blank screen.   Executive adoption of PBI will never get off the ground if we can't ensure a seamless experience. I am sure this is the case for most organizations.   Even better, I would be able to login as them to view their "home page" experience to pin favorites and ensure they are easily routed to the right reports.   ... View more

we use whl files and create libraries to make configurations and common code accessible across all notebooks in our Data Engineering solution. But publishing these files to environment is not a great experience. I need to try multiple times publishing with no luck. It is hard to predict if publishing was successful or not. It would be helpful if can see the libraries, whl files etc available at cluster level. ... View more