Dynamic ADLS-Gen2 path input for Spark Jobs Main definition file
I would like the ability to add a dynamic input box on a spark job definition's "Main Definition File" "ADLS-Gen2 path". this would be useful to set base and variable paths across all spark jobs. and have them set in a library folder so if I have 50 definitions, and instead of making a change to all 50 files i can just make a single change on the variable. and it would be consistent across workspaces on other environments.
Support Native SQL LIKE / NOT LIKE Wildcard Filtering Across Power BI Reports
Description Currently, Power BI does not provide a native way for report consumers to perform dynamic SQL-style wildcard filtering using patterns such as LIKE '____' - Above return all values with exactly four characters LIKE '__A_' - Return all four-character values where the third character is "A" Many enterprise reporting scenarios require users to enter dynamic search patterns similar to SQL LIKE and NOT LIKE functionality. While workarounds using DAX, calculated columns, custom visuals, or custom logic may be possible for individual fields, these approaches are not scalable when reports contain hundreds of filterable columns. Current Limitation After engagement with Microsoft Support, Advisory, and Architecture teams (Case #2606220040001996), it was confirmed that: Power BI currently has no native runtime implementation of SQL LIKE / NOT LIKE filtering. Existing alternatives do not adequately support large-scale implementations with hundreds of columns. Third-party visuals such as Smart Filter do not fully support SQL-style wildcard matching (for example _ as a single-character wildcard). This has been identified as a current product limitation. Suggested Enhancement Provide native filtering capabilities that support standard SQL wildcard expressions within Power BI report filters and slicers, including: % for multi-character matching _ for single-character matching LIKE and NOT LIKE style filtering behavior User-entered runtime pattern matching Consistent functionality across all text columns without requiring custom DAX or calculated columns Example Scenarios User Input Expected Result ____ Return all values with exactly 4 characters __A_ Return all 4-character values where the third character is A %ABC% Return values containing ABC A% Return values starting with A %XYZ Return values ending with XYZ Business Impact This enhancement would provide significant value for organizations with large-scale enterprise reporting environments by: Reducing reliance on custom DAX and calculated columns Improving report usability for business users familiar with SQL-style searches Enabling dynamic filtering across hundreds of columns without additional development effort Improving scalability, maintainability, and performance of enterprise Power BI solutions Supporting Information Microsoft Support has confirmed that there is currently no supported native Power BI solution for dynamic SQL LIKE wildcard filtering at scale and recommended submitting this requirement through the Microsoft Fabric Ideas portal for product team evaluation.
Display Delta table and column descriptions in Fabric Lakehouse Explorer/ Fabric on Browser
Microsoft Fabric Lakehouse should provide a visible and editable description field for Delta tables and columns in Lakehouse Explorer. Delta table metadata, such as comments or custom description properties, can be stored through Spark, but this information is not clearly displayed to users browsing the Lakehouse. Please add support for: Displaying table descriptions in Lakehouse Explorer/ Fabric on Browser Displaying descriptions as tooltips or in a table details panel Displaying column descriptions in table previews and schema views Editing table and column descriptions directly from the Fabric interface Reading existing Delta comments and description properties Exposing descriptions consistently through the Lakehouse SQL analytics endpoint Making descriptions available to Microsoft Purview and Copilot This would improve data discovery, self-service analytics, governance, and semantic understanding without requiring users to maintain separate documentation. Data engineers can identify tables from technical names, but report developers, analysts, and business users need descriptions to understand their intended purpose. Keeping descriptions directly with the Lakehouse object reduces separate documentation, ambiguity, and incorrect table usage.
Amazon Redshift Connector - Power query
Amazon Redshift is a supported connector within Power Query and supports Microsoft Entra ID (Azure AD) Single Sign-On (SSO) scenarios through Power BI Service and Power BI semantic models. Documentation for the Amazon Redshift connector explicitly references support for Microsoft Entra ID SSO in the Power BI ecosystem. However, Amazon Redshift is not currently listed as a supported native connector in Excel Power Query. The current Excel Power Query connector matrix includes many database connectors but does not include Amazon Redshift. This creates a capability gap between Power Query experiences across Microsoft products. Customers that use Amazon Redshift and Microsoft Entra ID authentication can leverage modern authentication and SSO in Power BI, but must adopt alternative architectures or workarounds when Excel is their primary data consumption tool Requested enhancement: Add native Amazon Redshift connector support to Excel Power Query, including support for Microsoft Entra ID/OAuth authentication methods and SSO capabilities where available. Current Workarounds: Power BI semantic models Dataflow Gen1/Gen2 Generic ODBC connectivity
This is a genuine feature request for Power BI Table and Matrix visuals.
Problem: Currently, Table and Matrix visuals do not have a built-in "Corner Radius" option in the General format settings. To create rounded corners, we have to use a Shape as a workaround behind the table. Why this is needed: 1. The shape workaround makes the PBIX file heavier and harder to maintain. 2. We cannot have Cards and Buttons with rounded corners, but not Tables. It looks inconsistent. 3. Modern dashboard design needs this feature for a professional look like in Figma and Canva. Request: Please add a "Corner Radius" slider under General > Properties for Table and Matrix visuals, just like we have for Buttons, Cards, and Slicers. This will help all Power BI developers create clean and modern dashboards easily.Add Corner Radius for Table and Matrix Visuals
Problem: Currently, Table and Matrix visuals do not have a built-in "Corner Radius" option in the General format settings. To create rounded corners, we have to use a Shape as a workaround behind the table. Why this is needed: 1. The shape workaround makes the PBIX file heavier and harder to maintain. 2. We cannot have Cards and Buttons with rounded corners, but not Tables. It looks inconsistent. 3. Modern dashboard design needs this feature for a professional look like in Figma and Canva. Request: Please add a "Corner Radius" slider under General > Properties for Table and Matrix visuals, just like we have for Buttons, Cards, and Slicers. This will help all Power BI developers create clean and modern dashboards easily.
Workspace Sharing
In the past Power BI Admins had the ability to share a workspace as a whole with an external user to then initiate the invite email. After accessing their external account on our tenant, they could then access any residing report based on RLS security set on the external account. This functionality is no longer available for new Power BI workspaces, and can only be done on individual reports within the workspace. This is time consuming when RLS security is in place and protects against unwanted data access based on the report the external user is viewing. The ability to invite external users to newly created workspaces should be brought back to then help minimize the time spent having to invite external users to individual reports when RLS security is set and manages data viewing access.Fabric Workspace Operator Role for Pipeline Monitoring and Rerun Operations
Many organizations have dedicated production support and operations teams responsible for monitoring Microsoft Fabric pipelines and responding to failures. Currently, the available workspace roles are Admin, Member, Contributor, and Viewer. While Viewers can monitor content, they cannot rerun failed pipelines. Contributors can rerun pipelines, but they also have permissions to modify pipeline definitions and other workspace artifacts. This creates a governance gap for enterprises that require segregation of duties between development and operations teams. Proposed Solution Introduce a new built-in Operator workspace role with permissions such as: Allowed View pipeline definitions Monitor pipeline runs and run history View execution logs and error details Manually trigger pipeline execution Rerun failed pipeline runs Cancel running pipeline executions Access workspace monitoring capabilities Not Allowed Create, edit, or delete pipelines Create, edit, or delete Fabric artifacts Modify notebooks, lakehouses, warehouses, or dataflows Manage workspace access or permissions Change workspace settings Connect/disconnect Git repositories Business Value This role would: Support enterprise segregation of duties requirements. Enable production support teams to resolve operational issues without granting development permissions. Reduce the risk of accidental changes in production workspaces. Improve governance and compliance. Align Microsoft Fabric with operational models commonly used in enterprise data platforms. Many organizations need a role that sits between Viewer and Contributor, providing operational control without development privileges. An Operator role would significantly improve security, governance, and supportability for Fabric Data Factory workloads. Use Case: Production support team monitors Fabric pipelines, investigates failures, and reruns failed executions, but should not be able to modify pipeline definitions or other workspace assets.
Microsoft fabric CI/CD deployment using Azure DevOps
Scenario: We are planning to migrate Microsoft Fabric artifacts across tenants using Azure DevOps. I would like to understand the feasibility of this approach and identify which Microsoft Fabric artifacts can be migrated using an Azure DevOps pipeline. Migration Approach: We have two Azure tenants: Tenant 1 and Tenant 2. Tenant 2 has its own Azure DevOps Services environment. The requirement is to migrate Microsoft Fabric items from a workspace in Tenant 1 to a Microsoft Fabric workspace in Tenant 2. To achieve this, I am planning to: Configure Git Integration for the Fabric workspace in Tenant 1 using a Service Principal. Commit the Fabric artifacts to an Azure DevOps repository in a dedicated folder (for example, Fabric Artifacts) within a repository branch. Create an Azure DevOps YAML pipeline along with a Python script that dynamically deploys the artifacts from the repository into the target Fabric workspace in Tenant 2. Use the attached Python script to automate the deployment process. We currently have the following artifact types in the source Microsoft Fabric workspace. I would like to understand whether there are any limitations with this approach and if all of these artifacts can be migrated successfully using an Azure DevOps pipeline. Artifact Types Activator CopyJob DataflowFabric Environment EventStream GraphQL KustoDatabase KustoEventHouse Lakehouse MLExperiment MountedRelationalDatabase Pipeline SQLDbNative SynapseNotebook User Data Functions Variables Warehouse Dataset OrgApp PaginatedReport Report
Dashboard to see the Copilot Usage in Power BI
I would like to propose the development of a centralized dashboard within Microsoft Fabric that provides a comprehensive view of Microsoft Copilot usage across all users within a tenant. Currently, organizations often need to gather usage insights from multiple locations and reports, which can make monitoring adoption, engagement, and utilization more complex and time-consuming. A unified dashboard would simplify this process by consolidating all relevant Copilot usage metrics into a single, easy-to-navigate interface. Key Benefits: Centralized visibility of Copilot adoption and usage across the tenant. Improved user experience by eliminating the need to navigate multiple reporting sources. Easier tracking of user engagement and licensing utilization. Better support for customer discussions regarding Copilot value, adoption, and ROI. Consistent and aligned reporting for administrators, support teams, and stakeholders. Such a dashboard would help organizations quickly understand how Copilot is being used across their environment while providing a more efficient and streamlined reporting experience.
