2. Power BI guidelines

2.1.1 Workspace

To simplify workspace management in Power BI, we recommend using a single workspace for each product/area. This approach minimizes complexity by keeping everything within one workspace, enabling your team to focus on content creation and collaboration without needing to manage multiple workspaces for different environments.

In Solvay we recommend to use Development (DEV), Test (TEST), Pre-production (PREPROD) and Production (PROD) 

We name each workspace in this simple format [ProductName] | [Environment]

Example:

• Finantial | DEV
• Finantial | TEST
• Finantial | PREPROD
• Finantial (does not appear PROD because is the final stage and is ready to be consumed)

2.1.2 Report, App and Dashboard

Establishing consistent naming conventions for Power BI assets ensures clarity, traceability, and efficient collaboration among team members. By adopting a standardized naming format, stakeholders can quickly identify the purpose, stage, and environment of each item in the Power BI ecosystem.

The recommended naming format is [ProductName]_[PipelineItem]

Components of the Naming Convention

• ProductName:
  This is a short identifier for the product, project, or business domain the asset serves.
  • Examples:
    • Sales for Sales-related reports and dashboards.
    • HR for Human Resources content.
    • Finance for financial reporting.

• PilelineItem:
  Indicates the type or purpose of the Power BI item. Use the following terms to specify the pipeline stage:

  • Report (RPT): Refers to Power BI reports that include visualizations and insights from data models.
  • App (APP): Refers to Power BI apps, which are collections of reports and dashboards shared with users.
  • Dashboard (DSH): Refers to dashboards built for high-level summaries or key performance indicators (KPIs).

• Environment:
  Specifies the deployment environment to differentiate between development, testing, and production stages. Use the following abbreviations:

  • DEV: Development environment, where initial work and iteration happen.
  • TEST: Testing environment, where the content is validated by stakeholders.
  • PROD: Production environment, where the finalized content is published for end-users.

Naming Conventions for Each Power BI Component

Reports

Reports are detailed and interactive data visualizations designed for analysis. They should be named as:
[ProductName]_Report_[Environment]

• Examples:
  • Sales_Report_DEV: A sales report in the development environment.
  • Inventory_Report_TEST: An inventory report being tested.
  • HR_Report: A finalized HR report published for end-users.

Apps

Apps in Power BI are collections of reports and dashboards shared with a wider audience. They should be named as:
[ProductName]_App_[Environment]

• Examples:
  • Sales_App_DEV: A Sales app in development.
  • Inventory_App_TEST: An Inventory app in the testing phase.
  • Finance_App: A Finance app ready for production.

Dashboards

Dashboards are high-level summaries designed for monitoring KPIs and other critical metrics. They should be named as:
[ProductName]_Dashboard_[Environment]

• Examples:
  • Sales_Dashboard_DEV: A dashboard summarizing sales metrics in development.
  • HR_Dashboard_TEST: An HR dashboard in the testing phase.
  • Finance_Dashboard: A final Finance dashboard for executive reporting.

Best Practices for Naming Conventions

• Consistency Across Teams:
  Ensure all team members follow the same naming format to avoid confusion and improve collaboration. Document this standard in your organization’s guidelines.

• Abbreviation Standards:
  Use short and meaningful abbreviations for ProductName to keep names concise but informative. For example:

  • MKT for Marketing.
  • OPS for Operations.

• Avoid Special Characters:
  Stick to alphanumeric characters and underscores (_) for compatibility and clarity.

• Versioning (Optional):
  For iterative development, consider appending version numbers to distinguish between iterations:

  • Example: Sales_Report_DEV_v1, Sales_Report_DEV_v2.

• Use Descriptive Product Names (if necessary):
  For larger projects with subdomains, add more context to the ProductName:

  • Example: Sales_Europe_Report_DEV for a regional Sales report.

2.2. Access and Permissions 

In Power BI, access and permissions are managed at three levels—Semantic Model, App/Report, and Workspace. Each level represents a different layer of access control and functionality within Power BI.

2.3.1. Semantic Model (Data Model or Dataset Access)

The semantic model represents the underlying dataset in Power BI that defines the data structure, relationships, calculations (e.g., DAX measures), and data security.

Access Considerations:

• Dataset Access Permissions: Users can be given direct access to the dataset, which allows them to:
  • Build their own reports using the dataset;
  • View data as defined by the roles in Row-Level Security (RLS), if applied.
• Access Levels:
  • Viewer: Can connect to and view the dataset but cannot modify it.
  • Contributor/Builder: Can create reports or dashboards using the dataset.
  • Owner: Full control over the dataset, including the ability to share or modify it.

2.3.2. App/Report (Content Layer Access)

This level controls access to the specific reports and dashboards created from datasets. The content is typically shared with end-users via apps or direct links.

Access Considerations:

• Report/Dashboard Access: Access can be granted for specific reports or dashboards. Users may have:
  • View-Only Access: Can interact with the report or dashboard but cannot edit.
  • Edit Access: Can modify the report if permission is granted.
• App Access: Reports and dashboards can be bundled into a Power BI App for easier distribution.
  • Apps allow centralized access control for multiple reports and dashboards.
  • Access to the app does not inherently grant access to the underlying dataset unless explicitly shared.

2.3.3. Workspace (Collaboration Level Access)

Workspaces are the collaboration environments where datasets, reports, dashboards, and other content are created, shared, and managed. Access to a workspace governs overall permissions to its content.

Access Considerations:

• Roles in Workspace:
  • Admin: Full access to all workspace content and settings. Can manage members, settings, and permissions.
  • Member: Can create, edit, and delete content but cannot manage workspace settings or membership.
  • Contributor: Can create and edit content but cannot delete or manage workspace permissions.
  • Viewer: Can view content but cannot create or edit anything.
• Access at the workspace level provides access to all content in that workspace unless specific restrictions (e.g., RLS) are applied.

2.4. Row-Level Security (RLS)

Row-level security (RLS) controls access to specific rows in a database based on group membership or execution context, ensuring users only see data relevant to their role or department. It is commonly used in scenarios like restricting employees to their department's data or limiting customers to their own data in a multitenant setup.

RLS is enforced at the database level, applying restrictions every time data is accessed, ensuring security across all platforms, including Power BI. It simplifies security management and applies to queries on a Warehouse.

Implement & Manage Security Roles

Assign Security Roles

Reporting with security roles

2.5. Environment

In this scenario, content creators often collaborate in an additional, development workspace that contains the latest version of the solution.

The following diagram depicts a high-level example of how you might use separate environments with a development, test, and production workspace.

2.6. Power BI desktop installation

At now users will either have Power BI already installed on their desktops or will need to follow the instructions below to install it. First it depends if you have Company Portal or Software Center (starting June of 2025 users we will just have Company Portal).

• Go to search bar and write:  

• Inside the Company Portal/Software Center search for Power BI and click to install.

• Choose language and click Next

• Click Next

• Tick I accept the terms in the License Agreement and click Next

• Click Next

• Untick Create a desktop shortcut and click Install

• Untick Launch Microsoft Power BI Desktop and click Finish

2.7. License request (Content Creator and Report Viewers)

If you require a Power BI license, please follow these steps to request one:

1. Submit a Ticket: Start by creating a ticket through Service One portal. Provide all necessary details, including your business need for the license.

2. Data Visualization Team Review: Once the ticket is submitted, it will be routed to Data Visualization (Data Viz) team. They will evaluate the need for the license based on the business context and confirm alignment with organizational standards.

3. License Assignment: Upon approval from the Data Viz team, the ticket will be forwarded to the Entra ID/Office Automation Team, who will assign the Power BI license to your account.

2.8. New Workspace request

If you require a new Power BI workspace, please follow these steps to request one:

1. Submit a Ticket: Start by creating a ticket through Service One portal. Provide all necessary details, including your business need for theworkspace.

2. Data Visualization Team Review: Once the ticket is submitted, it will be routed to Data Visualization (Data Viz) team. They will evaluate the need for the new workspace based on the business context and confirm alignment with organizational standards.