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.
8 Comments
- alecomjolNew MemberExcelent ideia!
- PerdigaoNew Membermuito boa ideia, seria o ideal mesmo
- LuizHermogengesNew MemberÓtima ideia, vai ser muito bom !!!!
- lukz129Regular VisitorAmazing idea! It could reduce most work 😁😎 Analyse this topic Microsoft please 🙌
- tiffwalkNew MemberThis would be very helpful and would eliminate the need for the rebuild of some departmental reports just to be included within an app!
- tiffwalkNew MemberThis would be very helpful and would eliminate the need for the rebuild of some departmental reports just to be included within an app!
- nathalya_lealRegular VisitorÉ essa atualização que precisamos para os aplicativos.
- leyreRegular VisitorHi, Sayurivalente, I think this is the same idea as this one: https://community.fabric.microsoft.com/t5/Fabric-Ideas/Page-Level-security-in-reports/idc-p/4615905#M159591
Recent ideas
Allow Excluding Specific Tables or Columns from Automatic Relationship Detection
Power BI automatically detects and creates relationships between tables when data is loaded. While this is useful, there are scenarios where certain tables or columns are intentionally designed to re...MohamedFowzan14 hours agoSuper UserNew6Views0likes0CommentsHave a DIRECT way to reach the *Transform Data Button* from any menu.
Hi. Currently (2026), in PowerBI you have to go click the HOME menu, than click the Transform Data button, each time you want to reach the Query editor menu. Please either create a dedicated button /...MOFabric5 hours agoRegular VisitorNew6Views0likes0CommentsShow clickable links to dependent objects, aka a usable lineage
I have say 12 reports connected to a semantic model which I have just changed so I need to check if anything has broken. This use to be easy, just click the semantic model to see dependents but this ...skiwii7 hours agoAdvocate INew6Views0likes0CommentsexecuteDaxQueries-like API call with effectiveUserName on SSO-enabled model with Service Principal
Please provide a way for a service principal to execute DAX - with an effective user name - against an SSO-enabled directlake semantic model and get per-user results that respect lakehouse OneLake Se...sean_cochran9 hours agoResolver INew4Views0likes0Comments