Please make a UI (user interface) option to schedule a Notebook to run in the user context (security context) of a Service Principal instead of my personal user. ... View more

Please make a UI (user interface) option to schedule a Data Pipeline to run in the user context (security context) of a Service Principal instead of my personal user.   This should also have the effect that any Notebooks within the Data Pipeline are run in the security context of that Service Principal. ... View more

The requirement would be to provide access to the below areas whilst not providing access to the other areas in the Admin portal:   Areas to provide access: -Tenant Settings (the only app permission provides to much access ('Tenant.ReadWrite.All' )) -Usage Metrics -Users -Premier Per User -Audit logs -Workloads ( api permissions grants access to all ) -workspaces   Whilst not providing access to the rest of the admin portal.     Currently Its not possible via custom roles as this is unsupported, and via API permissions they are not granualar enough, for example ( 'Tenant.ReadWrite.All' for tenant settings )   There is granular permissions in Fabric however to get access to all the required areas would mean granting Fabric admin which also grants access to areas that the users should not get access.   Ideally we need a way to more granually assign API permissions or enable the use of custom roles for Fabric.   ... View more

Currently the new Key Vault reference feature only allows to use a KV with public access from all networks.  However most customers cannot have Key Vaults open to public which makes this feature unusable at the moment.  Could you extend this to work with network-restricted Key Vaults? ... View more

I had difficulty solving the puzzles and couldn't create my free Fabric trail? I'd also be grateful if there were not so many puzzles to solve. Thank you. ... View more

Can we please make an improvement where you can export every user that has access to a Power BI report from the "manage permissions" section? I'd also love to have an upload template where i can mass upload users via excel. Another cool option would be to add a user, but then be able to multi select multiple reports in a workspace or workspaces you own.   Permissions are SO hard in Power BI and take so much time having to search every individual person. Also, searching for people whose names are First Name Middle Initital Last Name is so difficult and the Power BI search functionality exludes people if you don't perfectly get the middle initial in there.   Lastly, why aren't users who left an organization not automatically removed from the list? My company uses all Microsoft products. This kind of change should cascade.   Managing access should not be this difficult!! It wastes time when we should be focused on building insightful reports 🙂  ... View more

With the rising adoption of Multi-Factor Authentication (MFA) across our organization and industry best practices, we are seeking a more robust and streamlined authentication method for connecting Power BI to Snowflake. Currently, Power BI primarily relies on username/password or OAuth 2.0 via Microsoft Entra ID. While these methods are functional, they can become cumbersome and less secure in MFA-enabled environments. We propose the implementation of RSA key pair authentication for Snowflake connections within Power BI. ... View more

Our firewall has blocked the traffic to connect Fabric database, they only allow strict encrytion connection type in SSMS, but there is no such kind of option in Power BI Desktop, hope you can add it. ... View more

There should be a secure way to pass secrets or keys when making an API call (e.g. web.contents) in Power Query M.   Suggestions:   A) Make it possible to enter and edit secrets in Power Query, similar to how we enter and edit data source credentials in Power Query. Make these secrets encrypted and redacted. The secrets should be available to use as variables in the M code. When entering a secret, we would give it a name, which we can reference as a variable in the M code. We would only see the name, but the value would not be visible (the value would be redacted).   B) Make an Azure Key Vault connector for Power Query, that will make it possible to fetch secrets from AKV and assign the secret to a variable in the M query. This variable can be passed as part of the header in an API call.   C) Make it possible to redact some variables in M, so that we can use secret variables without the value being visible in the Power Query user interface.    The main point is that we want a way to use secured and hidden secrets as part of API calls in Power Query. ... View more

The Microsoft Fabric docs provide this guide to configuring Private Link access to a Fabric tenant. However, in testing this approach a provisioned endpoint could not be connect from a separate Azure tenant. The private endpoint could be created, but when attepting to approve the connection the following error resulted:           Upon consulting Microsoft Support they concluded that it is not supported to create Private Link endpoint connections to Fabric from a different Azure tenant, citing the following documented limitations: - Customers can't connect to Fabric resources in multiple tenants from a single virtual network, but rather only the last tenant to set up Private Link. - Each private endpoint can be connected to one tenant only. You can't set up a private link to be used by more than one tenant.   Private connectivty to Fabric from a separate tenant is a high priority for our customers who rely on our services to connect to their Fabric data sources, but have strict access requirements. Please consider enabling this functionality. You may contact me for a discussion on details and requirements, if desired.  ... View more

Our Situation Within our enterprise we want to expand the Microsoft Fabric Adoption by providing Semantic Models which are maintained by our IT Department (In the past, the IT Department only provided the Capacity Units; everything beyond was business managed n+1 times and not aligned between departments). Currently we have the IT-managed semantic models in a different Fabric Workspace than the IT-managed Lake- and Warehouses. Below a picture which visualizes this setup on an example data source:   Goal 1: All business users of our enterprise should be able to see the semantic model workspace and the names / description / endorsement of the semantic models they contain. Goal 2: Within the semantic model we want to control what data a user is able to see, e.g. through Column-level security (CLS). Goal 3: All business users should be able to create reports with semantic models they have access to, while they should not have access to the below whole Lake- or Warehouse (to maintain Goal 2). Goal 4: If a user has "Viewer"-Access to a workspace, he should be able to see all contained report names in the overview list.   Warehouse Workspace Permissions: Business User: Does not have any permissions assigned IT User: Has "Member"-Access assigned to workspace Semantic Model Workspace Permissions: Business User: Has "Viewer"-Permission assigned IT User: Has "Member"-Access assigned to workspace Semantic Model Direct access Permissions: Business User: Has "Build"-Permission assigned manually and automatically inherit's "Workspace Viewer"-Permission. IT User: Has All Permissions assigned Current Issues we face: 1. User is not able to see semantic model (direct lake SSO mode) if he has no access "Viewer"-Access to the Warehouse Workspace. This will result in the following UI-behavior: The default workspace view will show "There is nothing here yet" as text. If you switch to the Lineage-View with the button on the upper right side, the user is able to see the name of the semantic model as expected (Goal 1). ==> We think this is an UI Bug and should be fixed, in order that both views show the same data. In our example this would mean that both views show the name of the semantic model.   Besides the UI-Bug, we are not sure how to handle this one - maybe "direct lake fixed identity mode" could be an option (?). Besides this we could assign "Viewer"-Access to the workspace of the warehouse but would then bypass Goal 2. Happy to recieve some Ideas on this.   2. User is not able to see an existing report within a workspace if he has not the "Build"-Permission assigned to the used semantic model We would expect that while in the workspace overview, the user is able to see every report name the workspace contains if he has "Viewer"-Workspace-Permissions assigned. ==> The current behavior will give misleading information to the user   The Idea we have We believe that there are other enterprises as well which want to give the visibility over existing semantic models metadata (title, description, endorsement, etc.) to all their users, while the data access itself is handled differently. There should be an Microsoft Learn Article about the best-practicies to share semantic model metadata with the whole company while enabling users with data access to build custom reports as well.   In addition, the permission view of the semantic model UI should include those instructions as well. Maybe a diagram could be a good option as well to visualize who will have access.   Last words Our IT Department is still quite new to Microsoft Fabric Permission Management which is why a good documentation and helpfull UI hints are essential to fulfill our Goals 1-4. We want to enable our business to achieve the best results fast! ... View more

In our setup, we work with multiple environments (Dev, Test, and Prod), each represented by its own workspace. To streamline deployment via pipelines, we keep Lakehouses and Notebooks named identical across workspaces.   Previously, when opening a Notebook, we could clearly see which Lakehouse it was connected to, including the workspace name it belonged to.  This made it easy to identify if a Notebook was referencing, for example the Dev Lakehousem while working in the Prod workspace. We could then simply disconnect and re-add the correct reference.   However, with recent UI changes, only the Lakehouse name is visible, not the workspace it is contained in. This creates confusion when multiple Lakehouses share the same name across different workspaces. Even when adding a new source, the explorer does not clearly show which reference is from which workspace. This makes it far too easy to mistakenly remove or connect the wrong Lakehouse especially in production environments.   This seemingly small UI regression significantly affects productivity and introduces potential risks during deployment or debugging. Please consider restoring the visibility of workspace names to Lakehouse references in Notebooks.   Before: Screenshot from google E.g: Workspace Dev -LakehouseA -LakehouseB .... Workspace Prod -LakehouseA -LakehouseB ....   After:   Only lakehouse name   We use same lakehouse name in each workspace   ... View more

Promoting the idea for Microsoft Fabric to develop a native SaaS Key Vault item. Currently, there are plans and limited existing integration with PaaS Azure Key Vault, however this is promoting a Hybrid architecture. To fully realize a SaaS workload, we need a Fabric Native item to allow for the secure storage and retrieval (native integration with other items, Pipelines, Notebooks,ect.) of Secrets and Certificates. ... View more

Add functionality to Manage (Data Model Settings) Page Currently this just shows a grayed out >Data Source Credentials which cannot be maintained in the Power BI Service. Add functionality to manage gateway like PBIX Reports Add functionality to manage paramaters (see below for more detail) Ability to manage parameters in the Power BI Service for Power BI Report Builder Paginated Reports Currently paginated reports (.rdl) do not have the parameter flexibility like the standard power bi reports (.pbix) where parameters can be changed on the back end (e.g. pointing test to test and dev to dev database via a parameter used for the data source).   It would be awesome for both Internal paginated report parameters AND power query parameters to be managable from the power bi service in the manage screen.   Rename the Manage and Settings menu options in the Power BI Service (elipses options on RDL files) For RDL, Manage option appears to take user to a screen similar to PBIX Data Model 'settings' while Settings appears to take you to Report 'settings'. To make things easier to follow, simply rename Manage to Report Settings and Settings to Data Model Settings.   Workspace level setting Add functionality to set which roles can create, read, update, and/or delete ALL associated subscriptions rather than just the ones created by current user for. ... View more

I only want the end users to access what's in the report, not the entire semantic model.   Today, when sharing a report, we also share read permission to the entire semantic model (except for any RLS or OLS restrictions).   This is unintuitive and risky, because many people are not aware that they actually share the semantic model when sharing a report.   Instead, I only want the end users to access what's in the report, not the entire semantic model. ... 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

We heavily leverage Dynamic M365 groups at our organziation. When we want to share a semantic model, a M365 is allowed to share the model, however, if there is row level security on the model you can't use the M365 group. I have to then create a Dynamic security group with the same membership rule just to make the row level security to work. ... View more

Bring-Your-Own-Key aka. Customer-Managed Keys for encryption is a mandatory requirement in many companies to ensure compliance with GDPR and internal security regulations. As long as Fabric doesn't support BYOK, we can't use it's full potential. Key Vaults must be assignable on workspace-level or lower, e.g. per lakehouse, so that we can reduce the risk of a compromised key by decentralizing the key management. Defining one Key Vault per Workspace would imho be the best balance between decentralization and maintenance effort. ... View more

I have a workspace in my environment called "DataSources" with a number of lakehouses in it that use shortcuts to provide linkage (and Workspace Identity based access) to ADLS locations.  This works really well, and makes it very simple for my analysts to find the data they need. I have some upstream data providers that are now also exposing data via Lakehouses themselves, and it would be nice to be able to create a "Lakehouse Shortcut" inside the DataSources workspace that just redirects to the Lakehouse in their environment (instead of building my own lakehouse and creating shortcuts to their lakehouse tables).  This would make it so that I can provide a single location for my analysts to go to access/consume "blessed" datasets. ... View more