Power BI Governance: Workspace Architecture and Access Control

Ungoverned Power BI deployments follow a predictable trajectory. It starts with enthusiasm: departments adopt Power BI organically, creating workspaces, building reports, and connecting to data sources. Within a year, the organization has 200 workspaces with inconsistent naming, 500 reports with conflicting metrics, and no one knows which dashboard has the "right" revenue number. Data literacy increases, but data trust decreases.

Governance is the antidote. A well-designed governance framework does not slow down self-service analytics --- it accelerates it by providing guardrails, standards, and trust signals. Users create reports faster because they know which datasets are certified. Executives trust the numbers because definitions are standardized. IT sleeps better because sensitive data is classified and access-controlled.

This guide provides a complete governance framework covering workspace architecture, content lifecycle, access control, endorsement, sensitivity labels, admin portal configuration, and usage monitoring. It is based on patterns ECOSIRE has implemented across organizations ranging from 50 to 5,000 Power BI users.

---

Key Takeaways

• Workspace naming conventions (e.g., DEPT-PURPOSE-ENV) are the foundation of governance --- they make workspaces discoverable, auditable, and manageable at scale
• The three-workspace pattern (Development, Test, Production) with deployment pipelines prevents untested changes from reaching end users
• Power BI apps are the recommended distribution mechanism for consumers --- they provide a curated experience without exposing the workspace
• Content endorsement (Promoted and Certified) creates a trust hierarchy that helps users find authoritative datasets and reports
• Sensitivity labels from Microsoft Purview classify and protect Power BI content, with automatic downstream inheritance to exports
• The Power BI admin portal has over 50 tenant settings that control who can create workspaces, share content, export data, embed reports, and use AI features
• Usage metrics and the activity log provide visibility into adoption patterns, enabling data-driven decisions about governance adjustments

---

Workspace Architecture

The Purpose of Workspaces

A Power BI workspace is a container for datasets, reports, dashboards, dataflows, and paginated reports. It serves three purposes:

1. Collaboration: Workspace members collaborate on building and maintaining content
2. Security boundary: Workspace roles (Admin, Member, Contributor, Viewer) control who can do what
3. Deployment unit: Workspaces are the unit of deployment pipelines and app publishing

Workspace Naming Conventions

Without naming conventions, workspaces accumulate names like "Sales Dashboard," "Sales Reports v2," "John's Test," and "Q4 Revenue Final FINAL." Naming conventions eliminate ambiguity.

Recommended naming pattern:

{Department}-{Subject}-{Environment}

Examples:

Naming rules:

• Use UPPERCASE for department abbreviation (max 5 characters)
• Use PascalCase for subject (max 20 characters)
• Use UPPERCASE for environment suffix
• No special characters except hyphens
• No personal names (workspaces belong to teams, not individuals)

Workspace-per-Dataset vs Workspace-per-Department

Workspace-per-department groups all of a department's content in one workspace. This is simpler to manage but creates permission challenges when multiple teams within a department need different access levels.

Workspace-per-dataset creates a separate workspace for each major dataset and its associated reports. This provides granular access control but creates more workspaces to manage.

Recommended approach: Workspace-per-subject-area. Group related datasets and reports by business subject (Revenue, Pipeline, Inventory) rather than by department. This reflects how data is consumed (cross-functionally) rather than how it is produced (within departments).

The Three-Environment Pattern

Production workspaces should never be modified directly. Use the three-environment pattern with Power BI deployment pipelines:

Development workspace — Where analysts and developers build and iterate on reports and datasets. Only the BI team has access. Changes are frequent and experimental.

Test workspace — Where business stakeholders review and validate changes. Content is deployed from Development via the deployment pipeline. Stakeholders verify data accuracy, visual layout, and business logic before approving.

Production workspace — The only workspace end users access (via apps). Content is deployed from Test after stakeholder approval. Changes are controlled and auditable.

Deployment pipeline setup:

1. In Power BI Service, create a deployment pipeline (Settings, then Deployment pipelines)
2. Assign the three workspaces to the Development, Test, and Production stages
3. Configure deployment rules (e.g., change data source from DEV database to PROD database during the Test-to-Production deployment)
4. Grant the BI team access to deploy across stages
5. Grant stakeholders access to approve Test-to-Production deployments

This pattern ensures that:

• End users never see broken or in-progress reports
• Changes are reviewed before reaching production
• The deployment history provides an audit trail
• Data source connections switch automatically between environments

---

Content Distribution: Apps vs Direct Access

Power BI Apps

Apps are the recommended way to distribute content to end users. An app is a read-only, curated view of a workspace's content.

Benefits of apps:

• Users see a clean, organized interface (not the workspace's full content list)
• Content can be organized into sections with custom navigation
• App permissions are separate from workspace permissions
• Apps can be distributed to security groups, the entire organization, or specific users
• App updates are explicitly published --- users do not see work-in-progress changes

Configuring an App

1. Open the production workspace
2. Click "Create app" or "Update app"
3. Configure the app sections and navigation order
4. Set the audience (specific users, security groups, or the entire organization)
5. Configure permissions:
   • Allow users to copy reports: Yes/No (No for governed environments)
   • Allow users to build content with datasets: Yes/No (Yes for self-service)
   • Allow users to share the app: Yes/No
6. Publish the app

When to Use Direct Workspace Access

Direct workspace access (not through an app) is appropriate for:

• BI team members who need to edit content
• Power users who create their own reports on shared datasets
• Development and test workspaces (not for end users)

For all other users, apps provide a better experience with more control.

---

Roles and Permissions

Workspace Roles

Critical note: Viewers and Contributors are subject to row-level security (RLS). Members and Admins bypass RLS and see all data. Never assign Member or Admin roles to users who should be subject to data restrictions.

Permission Matrix

Map organizational roles to Power BI roles:

Microsoft 365 Groups

Every Power BI workspace is backed by a Microsoft 365 group. When you create a workspace, a corresponding M365 group is created. You can:

• Add M365 group members to the workspace automatically
• Use existing M365 groups (security groups or distribution lists) for workspace membership
• Manage workspace access through Azure AD group management instead of Power BI

Best practice: Use Azure AD security groups for workspace access. Create groups like "PBI-FIN-Revenue-Contributors" and "PBI-FIN-Revenue-Viewers." Manage membership through your IAM process rather than ad-hoc Power BI assignments.

---

Content Endorsement: Promoted and Certified

Endorsement is Power BI's trust signal system. It helps users distinguish between authoritative content and ad-hoc reports.

Endorsement Levels

Setting Up Certification

1. In the Power BI admin portal, go to Tenant Settings
2. Find "Certification" under "Content pack and app settings"
3. Enable certification
4. Specify who can certify content (recommended: a small group of BI leads and data stewards)
5. Provide a link to your certification documentation (criteria for certification)

Certification Criteria

Create a certification checklist that content must pass before receiving the certified badge:

Data quality:

• Data source is an approved enterprise source (not a personal Excel file)
• Refresh schedule is configured and succeeding reliably
• Data validation checks pass (row counts, total reconciliation)
• Historical data is complete (no gaps or duplications)

Model quality:

• Star schema design (fact tables + dimension tables)
• Date table properly configured and marked
• Relationships are correct and performant
• No bidirectional cross-filters unless explicitly justified
• Measures have clear names and formatting

Business logic:

• Metric definitions match the organization's data dictionary
• Calculations are reviewed by a business stakeholder
• Edge cases are handled (division by zero, null values, future dates)

Security:

• Row-level security is implemented where required
• Sensitivity labels are applied
• No hardcoded credentials or sensitive data in Power Query steps

Documentation:

• Report includes a documentation page or tooltip descriptions
• Measure descriptions are populated in the model
• Change log is maintained

Certification Workflow

1. Content creator promotes content (self-service)
2. Creator requests certification by notifying the BI governance team
3. Governance team reviews against the certification checklist
4. If approved, a designated certifier certifies the content
5. Certification is reviewed quarterly (or when major changes are deployed)

---

Sensitivity Labels

Sensitivity labels from Microsoft Purview (formerly Microsoft Information Protection) classify and protect Power BI content. They persist across exports --- a "Confidential" report exported to Excel carries the "Confidential" label to the Excel file.

Label Taxonomy

Define sensitivity labels that align with your data classification policy:

Applying Labels

Labels can be applied at the dataset, report, and dashboard level:

1. Open the dataset or report settings
2. Under "Sensitivity label," select the appropriate label
3. The label persists across the content lifecycle

Automatic Labeling

Configure default sensitivity labels in the Power BI admin portal:

• Default label for new content: Set to "General" so all new workspaces start with a baseline classification
• Mandatory labeling: Require users to apply a label before publishing
• Downstream inheritance: When a dataset has a label, reports built on it automatically inherit the label

Label-Based Protection

For "Confidential" and "Highly Confidential" labels, configure protection actions:

• Restrict who can export data (block CSV/Excel export for Highly Confidential)
• Restrict who can print reports
• Restrict external sharing
• Apply Azure Information Protection encryption to exported files
• Audit label downgrades (e.g., changing from Confidential to General requires justification)

---

Admin Portal Configuration

The Power BI admin portal contains over 50 tenant settings that govern organizational behavior. Here are the most impactful settings for governance.

Workspace Settings

Export and Sharing Settings

Developer Settings

AI and Copilot Settings

Audit and Compliance

---

Usage Metrics and Adoption Monitoring

Built-In Usage Metrics

Power BI provides usage metrics reports for each workspace. These reports show:

• Number of views per report (daily, weekly, monthly)
• Unique viewers per report
• Most popular reports
• Report performance (average load time)
• Distribution method (direct access vs app vs embedding)
• Platform (web, desktop, mobile)

Access usage metrics by clicking "Usage metrics" on any report in the workspace.

Power BI Activity Log

The activity log records every action taken in Power BI Service. It is available through:

• Microsoft 365 audit log (Compliance center)
• Power BI REST API (Get-PowerBIActivityEvent cmdlet)
• Azure Log Analytics (if configured)

Key events to monitor:

Adoption Dashboard

Build an internal adoption dashboard using the activity log data. Key metrics:

Monthly Active Users =
DISTINCTCOUNT(ActivityLog[UserEmail])

Adoption Rate =
DIVIDE(
    [Monthly Active Users],
    [Total Licensed Users]
)

Reports Per User =
DIVIDE(
    COUNTROWS(FILTER(ActivityLog, ActivityLog[Activity] = "ViewReport")),
    [Monthly Active Users]
)

Self-Service Ratio =
DIVIDE(
    CALCULATE(COUNTROWS(ActivityLog), ActivityLog[Activity] = "CreateReport"),
    CALCULATE(COUNTROWS(ActivityLog), ActivityLog[Activity] = "ViewReport")
)

The adoption dashboard helps governance teams:

• Identify departments with low adoption (need training)
• Find heavily used reports that should be certified
• Detect reports that are never viewed (candidates for retirement)
• Track governance KPIs over time (certified content %, labeled content %)

---

Lineage and Impact Analysis

Data Lineage View

Power BI's lineage view shows the dependency chain from data source to dataset to report to dashboard. Access it from the workspace menu (three dots, then Lineage view).

The lineage view answers:

• "Which reports use this dataset?" (impact analysis for dataset changes)
• "Where does this report's data come from?" (source traceability)
• "Are there orphaned datasets with no reports?" (cleanup candidates)
• "Which datasets connect to the gateway?" (gateway dependency mapping)

Impact Analysis

Before changing a dataset (modifying a table, renaming a column, changing a relationship), use impact analysis to understand downstream effects:

1. In lineage view, select the dataset
2. Click "Impact analysis"
3. Power BI shows all reports, dashboards, and apps that depend on the dataset
4. Review the list and notify report owners before making breaking changes

This prevents the common scenario where a well-intentioned schema change breaks 15 reports across 3 departments.

Data Catalog Integration

For organizations with Microsoft Purview (formerly Azure Data Catalog), Power BI datasets can be registered in the data catalog. This provides:

• Cross-platform data discovery (find Power BI datasets alongside SQL tables, Synapse views, etc.)
• Business glossary integration (link Power BI measures to standard business definitions)
• Data stewardship (assign data owners and stewards in the catalog)
• Compliance tracking (view sensitivity labels and classifications across all data assets)

---

Governance Policies Document

Every organization should maintain a Power BI governance document. Below is a template structure.

Section 1: Scope and Objectives

• Define what "governance" means for your organization (not bureaucracy, but enablement)
• State the objectives: data trust, regulatory compliance, cost control, adoption acceleration
• Define who the governance framework applies to (all Power BI users, specific departments, etc.)

Section 2: Roles and Responsibilities

Section 3: Standards

• Workspace naming conventions (as defined above)
• Dataset naming conventions (e.g., DS_Revenue_Sales, DS_Headcount_HR)
• Measure naming conventions (e.g., "Revenue YTD" not "RevYTD" or "ytd_revenue")
• Report naming conventions (e.g., RPT_Executive_Sales_Monthly)
• Color palette standards (align with corporate brand)
• Visualization guidelines (which chart type for which data type)

Section 4: Processes

• Content lifecycle: create, promote, certify, retire
• Change management: how to request changes to certified content
• Access request process: how users request workspace or app access
• Incident response: what to do when a data breach or governance violation is detected
• Review cadence: quarterly certification reviews, annual policy updates

Section 5: Compliance

• Data classification requirements (which sensitivity labels are mandatory)
• Regulatory requirements (GDPR, HIPAA, SOC 2, industry-specific)
• Data retention policies (how long to keep historical data in datasets)
• Export restrictions (who can export what data types)

Section 6: Training

• Onboarding training for new Power BI users (self-service, 2 hours)
• Advanced training for report authors (instructor-led, 1 day)
• Governance training for data stewards and admins (instructor-led, half day)
• Annual refresher training for all users (self-service, 1 hour)

For organizations implementing governance from scratch, ECOSIRE's Power BI implementation service includes a governance workshop that produces a customized governance document, workspace architecture, and certification process tailored to your organization's size and industry.

---

Scaling Governance

Small Organizations (Under 100 Users)

Keep governance lightweight:

• 5-10 workspaces with clear naming
• One or two certified "golden" datasets per department
• Sensitivity labels optional (start with simple workspace access control)
• Quarterly governance review meetings
• One Power BI admin who doubles as data steward

Medium Organizations (100-1,000 Users)

Add structure:

• 20-50 workspaces with naming conventions enforced
• Deployment pipelines for all production content
• Mandatory sensitivity labels on datasets
• Content certification with a formal checklist
• Monthly governance review meetings
• Dedicated BI team (2-5 people) with admin and steward roles

Large Organizations (1,000+ Users)

Full governance program:

• 100+ workspaces managed by a central admin team
• Center of Excellence (CoE) providing standards, training, and support
• Automated governance monitoring (Power BI REST API + custom dashboards)
• Integration with Microsoft Purview for enterprise data catalog
• Dedicated compliance officer reviewing audit logs
• Quarterly business reviews with governance KPIs
• Formal change advisory board for breaking changes to certified content

Center of Excellence Model

A Power BI Center of Excellence (CoE) is a cross-functional team that owns governance, standards, training, and support. The CoE does not build reports for every department --- it enables departments to build their own reports within governance guardrails.

CoE responsibilities:

1. Define and maintain governance policies
2. Build and certify shared datasets (the "golden" data layer)
3. Manage the data gateway and infrastructure
4. Provide training and office hours for self-service users
5. Review and certify departmental content
6. Monitor adoption and usage metrics
7. Evaluate new Power BI features and capabilities
8. Coordinate with IT on security, compliance, and licensing

CoE sizing:

---

FAQ

How many workspaces should my organization have?

There is no universal answer, but a useful guideline is one production workspace per major subject area (Revenue, Pipeline, Inventory, Workforce, etc.) plus development and test workspaces for each. A 500-person organization typically has 15-30 workspaces. The key metric is not the number of workspaces but whether each workspace has a clear owner, purpose, and naming convention. Orphaned workspaces with no clear ownership are a governance risk.

Should we restrict who can create workspaces?

Yes. Unrestricted workspace creation leads to sprawl. In the admin portal, limit workspace creation to the BI team or designated power users. Other users can request workspaces through a simple form or ticketing process. The request should include: workspace name (following naming conventions), purpose, owner, expected audience, and data sources. This adds a small amount of friction that prevents workspace proliferation while ensuring every workspace has accountability.

What is the difference between a workspace and an app?

A workspace is the collaboration environment where BI developers build and maintain content (datasets, reports, dashboards). An app is a read-only, curated package of that content distributed to end users. Think of the workspace as the kitchen and the app as the restaurant menu. Diners (end users) see the menu (app) and choose what to consume. Chefs (BI developers) work in the kitchen (workspace) to prepare and iterate on the offerings. The separation ensures users always see polished, validated content.

How do we handle sensitive data in Power BI?

Layer your protections: (1) Use row-level security to restrict which rows each user can see. (2) Use object-level security to hide sensitive columns (e.g., salary) from unauthorized roles. (3) Apply sensitivity labels to classify content and control exports. (4) Restrict export permissions in the admin portal for highly confidential content. (5) Use Azure AD Conditional Access to require managed devices and MFA for accessing Power BI. (6) Monitor the activity log for unusual data access patterns. No single measure is sufficient --- defense in depth is essential.

How do we measure the success of our governance program?

Track these governance KPIs monthly: (1) Percentage of production datasets that are certified (target: 80%+). (2) Percentage of content with sensitivity labels applied (target: 100%). (3) Number of orphaned workspaces with no activity in 90 days (target: zero). (4) Mean time to certify new content (target: under 5 business days). (5) User adoption rate (monthly active users divided by licensed users, target: 70%+). (6) Number of governance violations detected in audit logs (target: declining trend). (7) Self-service ratio (reports created by business users vs IT-built, target: increasing). Build an internal governance dashboard to track these metrics and review them in monthly governance meetings.