Differentiating identically named reports across deployment pipeline stages

[Rchark0]

Our team is using the Power BI deployment pipelines to promote content through Dev, Test (UAT), and Production stages. We have a solid process using the pipeline, but we've run into a significant usability challenge for our developers and testers.

The core issue: The pipeline requires that reports and datasets have identical names across stages to maintain pairing. While this is necessary for the pipeline's functionality, it causes confusion in the workspace view. When a developer has access to multiple workspaces, the list of reports shows identical names for the same report across different environments, making it more difficult to find and open the correct version quickly. It would be fantastic if there were the ability to organize workspaces and their artifacts into a nested folder structure, similar to a file explorer. This would solve the issue of having similarly named reports appear right next to each other, making everything much cleaner and easier to navigate

We are seeking feedback on best practices for a solution and are curious if the community has found any scalable methods to handle this. Formatting the 

Our initial research has led to a few partial solutions:

• Strict Workspace Naming: We use clear naming conventions, such as Project X [DEV], Project X [TEST], and Project X [PROD], to organize content. However, this relies on developers navigating to the correct workspace first rather than using the universal search.
• Parameter-Driven Visual Indicators: Implement a parameter in our reports that changes a visual banner's color and text based on the environment (e.g., a yellow banner for Test, a green banner for Prod). This provides a reliable visual cue inside the report but doesn't help with browsing the list view.
• App Renaming via API: For end-users and UAT testers, we use a separate app for each environment. We plan to use the Power BI REST API to automatically rename the app after a pipeline deployment, adding a suffix like (UAT) or removing it for production. This should improve searching for consumers, but not creators, as the app is a separate artifact from the reports/datasets and is not part of the pipeline's pairing logic.

Specific questions for the community:

• Is there a recommended best practice for differentiating identically named reports in the list view that we may be overlooking?
• Have other users found a method to customize the display name of artifacts in the Power BI list view without breaking the deployment pipeline?
• Are there any other tools or integration strategies (e.g., with Azure DevOps) that can provide a better solution for differentiating reports for internal users?

We appreciate any insights or alternative approaches the community has discovered. Thanks for your help!

[Rchark0]

Thank you, Dinesh. 

Through the use of APIs to add tags to artifact names and by leveraging security groups I believe we can make an almost foolproof experience to prevent human error from resulting in the wrong version of insight data being used for decision making.

[v-dineshya · Accepted solution]

Hi @Rchark0 ,

Thank you for reaching out to the Microsoft Community Forum.

Please try below things.

1. Use Power BI Project (PBIP) format, it breaks down .pbix files into source-controlled components. It enables version control via Git. Automated deployments using Azure DevOps pipelines. Environment-specific parameters for data sources and visuals.

Azure DevOps build pipeline integration with Power BI Desktop projects - Power BI | Microsoft Learn

Note: You can integrate this with deployment pipelines or replace them entirely with Azure DevOps release pipelines.

2. Power BI requires identical names for pairing, you can temporarily append environment tags like Sales Report [DEV] during development. Rename them via REST API before promotion to maintain pairing.

PowerBI report in Azure - Microsoft Q&A

Note: This can be automated using Power BI REST APIs in your CI/CD pipeline.

3. Power BI does not support nested folders, Create separate apps for each environment. Group reports logically within each app. Use naming conventions or sections to simulate folders.

4. Limit workspace access based on roles, Developers --> Access to [DEV] and [TEST]. Testers --> Access to [TEST] only. Consumers --> Access to [PROD] via apps.

Note: Use Tabular Editor and Best Practice Analyzer to Integrate into Azure DevOps pipelines to validate semantic models before deployment. And use Power BI REST API to Automate renaming, publishing, and parameter updates. And use Azure Key Vault and Service Principals for Secure credentials and automate deployments.

Please refer below links.

Solved: How to customize the default list view in workspac... - Microsoft Fabric Community

Rename dashboards, reports, workspaces, report pages, semantic models - Power BI | Microsoft Learn

I hope this information helps. Please do let us know if you have any further queries.

Regards,

Dinesh