Please provide the ability in M query or DAX for a report to know it's context. That is; it knows its' Workspace ID or Report ID. If we had this, we can then enrich the report with context retrieved from Power BI REST API info (like the report's fabric Domain or other corporate governance info) ... View more

It would be great if we could specify a folder to create a new item in (such as a lakehouse). Right now it seems you can only create new items in the root folder of the workspace when using the REST APIs. ... 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

I wanted to share some feedback and a suggestion regarding the Purview glossary implementation, based on our experience at our organization. While we appreciate the capabilities that Purview offers for data governance, we've encountered significant challenges with setting up and maintaining the business glossary. Despite the ability to import terms rapidly, there is no automated way to link these terms to the items they represent. Each definition must be manually linked to a data item one at a time, across three screens with multiple user interactions per screen. Given that we have over 28,000 data items in our data warehouse alone, not to mention the additional measures and tables in our Power BI data sets, this manual approach is not feasible for us. The current process significantly hinders our ability to efficiently manage and utilize the business glossary. We believe that an automated feature to link Power BI descriptions to the Purview glossary would greatly enhance our ability to manage data governance and provide a more seamless experience for our users. If this feature is included in the new Purview integrated within Fabric, it would be a significant factor in hastening our move to an F64 capacity. We hope that Microsoft considers this suggestion, as it would be invaluable in addressing the challenges we face and improving the overall user experience. ... View more

Right now: In deployment pipeline (new version) to deploy from dev to test we have to click test then select the item from dev we want deployed and then deploy. (essentially pulling up from the lower stage versus pushing to the next) If we want to set rules we have to deploy first THEN set the rule which is counterintuitive and a time sink/waste of resources to then deploy again or manually change the parameters. The icon for deployment is a rocketship not a UFO with a tractorbeam so I think push is the intention not a pull. This imagery should convey what I mean when I say push (rocket propulsion) versus pull (UFO tractor beam)   Suggested change: Change from a pull deployment to a push deployment Change Deploy From to Deploy To. To deploy from dev to test, user should click on DEV and select report to deploy to test Before deploy user should be able to set any parameter and data source change rules. Remove rules from highest prod level, add rules to lowest dev level Then user can click deploy to have it moved/pushed/deployed up to test. All gateway settings and parameters should be settable through deployment pipeline and pipeline should tell if there is no gateway Add checkbox option to deployment - Refresh on deployment This option should be grayed out or fail without using resources if a gateway is not setup. When checked, after successful deployment, attempt to refresh the report without user having to go into the workspace to refresh it. Add global parameter rules as noted in separate idea Global Deployment Pipeline Rules - Microsoft Fabric Community   ... View more

As a capacity administrator, it would be extremely helpful to see all the scheduled notebooks/refreshes/dataflows/pipelines/etc in one place -- ideally with a perspective on what impact these jobs may have on the overall capacity of the workspace. Right now, anyone can set up a job to run whenever they want... and most everyone just leaves it at default -- which means twice a day (1am Pacific Time and India Time) my capacity gets dropped to its knees. Knowing what's scheduled (and who scheduled it) will enable me to mitigate this issue. ... View more

We need a single page overview where we can see a complete list of which users and security groups have item permissions on any Item in the workspace.   Today, we need to click on every single Item to see who has access to that item.   We need a complete overview to easily spot if someone has a permission that they should not have. ... View more

Description: Currently, Power BI requires users to have Build permissions on a semantic model to use the Analyze in Excel feature. However, this permission also grants users the ability to create new reports in Power BI based on the semantic model, which conflicts with governance models in organizations that maintain centralized reporting. Request: We propose introducing a separate permission that allows users to utilize Analyze in Excel without granting full Build rights. This would allow organizations to maintain strict control over report creation while enabling end users to perform ad-hoc analysis in Excel as needed. Business Case: Our organization follows a centralized reporting approach where only designated individuals or teams are responsible for building and maintaining reports to ensure data consistency and governance. At the same time, business users often require the ability to perform their own exploratory analysis using Excel. The current permission structure forces organizations to choose between either: Restricting Analyze in Excel, limiting business users' flexibility for self-service analysis. Granting Build permissions, which compromises governance by allowing users to create and share their own Power BI reports based on the semantic model. By decoupling Analyze in Excel from Build permissions, Microsoft would enable organizations to: Maintain a single source of truth by restricting report creation to approved users. Empower end users to leverage Analyze in Excel for ad-hoc analysis without jeopardizing data governance. Reduce reliance on workarounds, such as exporting static data, which can lead to inefficiencies and inconsistencies. Proposed Solution: Introduce a dedicated permission (e.g., "Analyze in Excel" Access) that allows users to connect to the semantic model in Excel without being able to create new Power BI reports. This permission could be managed separately in dataset security settings. This enhancement would strike a balance between governance and self-service analytics, benefiting both IT administrators and business users. We encourage the Power BI team to consider this enhancement and would love to hear feedback from other users who face similar challenges. ... View more

When listing and getting Fabric items through the Fabric REST API, tag information should be included in the response object.   https://learn.microsoft.com/en-us/fabric/governance/tags-overview     ... View more

It would be helpful to have a permission level between viewer and contributor that allowed users to create things like notebooks, pipelines, data flows, and add things to lakehouses, but not have the ability to create new environments.  We at Duke would like to be able to create shared environments with the approved libraries and spark settings for different size spark pools, without giving developers the ability to create their own environments, spark settings, or spark pools.  This would give us the ability to help control costs and reduce exposure to un-approved libraries. ... 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

Add customized fields to a workspace, report, data/semanitic model to help records additional fields for an item; for example business criticality of a report. ... View more

Vote up that have me speak about BI Governance at upcoming FedBiz App Summit in Reston, VA. ... View more

Right now everyone in a workspace can create and manage all the items. Already in Power BI this often results in a huge mess in large organisations since many business users are not trained properly. From a Governance point of view it would be great to be able to limit e.g. Data Factory elements to our group of Data Engineers and Notebooks/Lakehouses to our trained Data Scientists and limit Power BI elements to our group of BI Analysts. Give us the option to limit what employees can do based on Security Groups. ... View more

We'd like to be able to download pbix from using "Create button" in Power BI service where a semantic model is in another workspace. Please remove limitation from below.  "If you create a report by using the Create button in the Power BI service, and it's based on a semantic model in another workspace, you can't download it."  ... View more

The ask is to integrate something like Azure Monitor/Log analytics or a better solution to centralize the logs within Fabric. In particular, it must be possible for semantic model and Power BI report developers to see the individual queries (M, dax, or sql) executed by their artifact to purposefully evaluate its performance. ... View more

Please add the ability to see the lineage of the indivdual tables that are used from a semantic model into reports published on fabric. The lineage view is already super handy and helpful to determine what dashboard uses what sources. Adding the ability to see what tables are sued and in which reports is a mjaor win for governance to make sure everyone is on the same table and that the unused tables can be easily identified and removed for compliance and security. ... View more

For all Fabric items besides Power BI: Only item-level metadata and lineage will be captured, scanning metadata and lineage of sub-level items like Lakehouse tables or files isn't supported. In other words, currently, Purview does not support scanning sub-level artifacts such as tables and columns in Lakehouse KQL databases and Data warehouse. Data Products are usually composed of tables, not databases thus failure to register tables in the data map, and data catalog makes it impossible to manage Fabric data products in Purview. ... View more

Complete lineage view, including for example: across workspaces all Fabric items data which gets "pushed" (written) from an item to a destination data connections which are written in code (parameterized) etc. ... View more