Implementing Power BI Endorsed Dataset Promotion with Deployment Pipeline Stage Rules to Enforce a Governed Data Product Lifecycle Across Enterprise Workspaces

Introduction

Here's a scenario that plays out in almost every enterprise Power BI deployment: a business analyst builds a dataset in their personal workspace, shares it with a few colleagues, and within six months that dataset is driving quarterly board reports. Nobody knows who maintains it. Nobody knows if it's certified. The DAX measures were written by someone who left the company. The refresh schedule breaks every time the source database schema changes. Meanwhile, three other teams have built their own versions of "the revenue dataset" because they didn't know this one existed — or didn't trust it.

This is the data product lifecycle problem. And it doesn't get solved by governance policies written in PDFs that nobody reads. It gets solved by building the governance directly into the tooling — by making the right path the easy path, and making ungoverned sprawl structurally harder than following the process.

Power BI gives you two powerful, complementary mechanisms for doing this: endorsement (promoted and certified status on datasets) and deployment pipeline stage rules (parameter overrides and deployment gates that enforce environment-appropriate configurations). Used together, they let you build a genuine data product lifecycle where datasets graduate from development through testing to production with explicit quality gates, automatic configuration management, and discoverable trust signals that tell consumers exactly what they're working with.

By the end of this lesson, you'll be able to design and implement a full governed lifecycle for enterprise Power BI datasets.

What you'll learn:

• How the promoted and certified endorsement tiers work, and how to use them strategically at each pipeline stage
• How to configure deployment pipeline stage rules to enforce environment-specific parameters, data source connections, and workspace configurations
• How to integrate endorsement workflows with pipeline deployment gates so promotion and certification happen as formal checkpoints — not as afterthoughts
• How to use the Power BI REST API to automate endorsement state management across deployments
• How to build a dataset catalog that surfaces trust signals to consumers at discovery time

Prerequisites

You should already be comfortable with the basics of Power BI deployment pipelines — creating stages, assigning workspaces, and executing deployments. If you need a refresher, work through Power BI Deployment Pipelines: Building Dev, Test, and Production Workflows from Scratch before continuing here.

You'll also benefit from familiarity with Power BI Governance: Workspaces, Permissions, and Audit Logging, since this lesson extends those governance concepts into active enforcement rather than passive monitoring.

A Power BI Premium or Premium Per User (PPU) license is required. Deployment pipelines and certification endorsement are not available on Pro-only tenants.

---

Understanding the Data Product Lifecycle Problem

Before we write a single REST call or configure a single pipeline rule, we need to be precise about what we're trying to enforce. The "data product lifecycle" isn't just about having Dev, Test, and Prod workspaces — it's about enforcing the meaning of each stage.

In a well-governed environment, a dataset in Development means: this is experimental, it may break, do not build anything important on it. A dataset in Test means: this has passed technical validation, is connected to representative data, and is under review for accuracy and performance. A dataset in Production means: this is the authoritative version, it is certified by named data stewards, it refreshes reliably, and it should be the single source of truth for downstream report builders.

The problem is that without structural enforcement, these distinctions exist only in people's heads. Someone deploys directly to Prod because the test environment was slow. A report gets built against the Dev workspace dataset because the test workspace didn't have the right data. A dataset gets certified because someone clicked the button — not because it passed any actual quality review.

What we're building is a system where:

1. A dataset can only reach Certified status in Production, after passing through specific pipeline stages
2. Each pipeline stage enforces environment-appropriate data sources and parameters through stage rules
3. Promotion events are captured and trigger review workflows
4. Report builders see clear trust signals in the dataset catalog

Think of it like a software release process. You wouldn't ship code directly from a developer's laptop to production. The data product lifecycle should have the same rigor.

---

The Endorsement Model: Promoted vs. Certified

Power BI has two endorsement tiers, and understanding the distinction is critical before you start enforcing them.

Promoted is a lightweight signal that any workspace member with Contributor or higher access can apply. It means "this dataset is ready for broader use" — essentially, the team that owns it is vouching for it. Promoted datasets surface higher in search results and dataset discovery panes. The bar is low, and intentionally so: it's meant to be a self-service quality signal within a team or department.

Certified is a tenant-admin-controlled designation. Only users who have been explicitly granted certification authority by a Power BI admin can certify datasets. It means "this dataset meets the organization's standards for enterprise data products." Certified datasets get a badge in the Power BI service, appear at the top of search results, and — critically — report builders see the certification when they're selecting a dataset for a live connection.

In practice, here's how we map endorsement to pipeline stages:

Pipeline Stage	Endorsement State	Who Can Apply	Meaning
Development	None	—	Under construction, not for general use
Test	Promoted	Dataset owner or workspace admin	Validated, approved for testing and review
Production	Certified	Named data stewards only	Authoritative, enterprise-grade

This mapping isn't Power BI's default — you have to design and enforce it. Let's look at how.

---

Configuring Deployment Pipeline Stage Rules

Stage rules are the mechanism that make deployment pipelines smarter than a simple copy operation. Without stage rules, deploying from Dev to Test to Prod copies your dataset verbatim — same data source connection strings, same parameter values, same gateway bindings. In a real enterprise, each environment needs different configuration.

Setting Up a Three-Stage Pipeline

In the Power BI service, navigate to Deployment Pipelines in the left navigation and create a new pipeline. Name it something meaningful: "Sales Analytics — Governed Lifecycle" rather than just "Sales Pipeline." Assign your three workspaces:

• Sales_Analytics_DEV → Development stage
• Sales_Analytics_TEST → Test stage
• Sales_Analytics_PROD → Production stage

Each workspace should have capacity assigned (Premium or PPU) and a clear access model. Development might give Contributors access to a broader development team. Test should be more restricted — QA analysts and data stewards, not individual report builders. Production should be tightest — Member access to the dataset owner group only, with consumers accessing data through apps or certified dataset connections.

Configuring Stage Rules for Data Source Parameters

This is where the real environment enforcement happens. In your dataset, define parameters for your data source configuration:

// In Power Query, define these as parameters
ServerName = "dev-sqlserver.corp.internal" as text
DatabaseName = "SalesAnalytics_DEV" as text
EnvironmentTag = "Development" as text

Structure your data source query to use these parameters:

let
    Source = Sql.Database(ServerName, DatabaseName),
    SalesOrders = Source{[Schema="sales", Item="FactSalesOrder"]}[Data],
    // ... rest of transformation
    AddEnvironmentTag = Table.AddColumn(SalesOrders, "DataEnvironment", each EnvironmentTag)
in
    AddEnvironmentTag

Now, in the deployment pipeline, configure stage rules for the Test and Production stages. Select the Test stage, click "Deployment rules," and for your dataset add rules to override parameter values:

Test stage rules:

• ServerName → test-sqlserver.corp.internal
• DatabaseName → SalesAnalytics_TEST
• EnvironmentTag → Test

Production stage rules:

• ServerName → prod-sqlserver.corp.internal
• DatabaseName → SalesAnalytics_PROD
• EnvironmentTag → Production

When you deploy from Dev to Test, the pipeline applies these overrides automatically. The dataset in the Test workspace connects to the test database — no manual configuration, no risk of someone accidentally connecting a test dataset to a production data source.

Configuring Stage Rules for Gateway Bindings

If your data sources are on-premises or behind a corporate firewall, you're using an on-premises data gateway. Different pipeline stages should bind to different gateway clusters. Connecting Power BI to On-Premises Data Sources Using the On-Premises Data Gateway covers gateway setup in detail, but the deployment pipeline integration works as follows:

In the stage rules configuration, after setting parameter overrides, scroll to the "Data source" section. For each data source your dataset uses, you can specify which gateway data source connection it should use in that stage. This means:

• Dev connects to GW-DEV-Cluster / SalesAnalytics_DEV connection
• Test connects to GW-TEST-Cluster / SalesAnalytics_TEST connection
• Production connects to GW-PROD-Cluster / SalesAnalytics_PROD connection

This is critical for security isolation. Your Production gateway cluster should have credentials that access only the production database, with read-only service account permissions. Developers should not have access to those credentials.

Stage Rules for Scheduled Refresh

Stage rules also control scheduled refresh configuration. This matters because your Dev dataset probably shouldn't refresh every hour — that's just noise and capacity burn. But your Production dataset might need to.

In the stage rules, you can configure the refresh schedule that gets applied upon deployment. For Production, set the schedule to match your SLA. For Test, a daily refresh is typically sufficient. For Dev, consider leaving refresh on-demand only and letting developers trigger manual refreshes.

---

Enforcing Endorsement as a Pipeline Gate

Here's where most enterprise implementations stop short: they set up the pipeline stages, they configure stage rules, but endorsement is still a manual thing someone does whenever they remember. Let's fix that.

The strategy is to treat endorsement state transitions as formal checkpoints in the promotion workflow:

1. Dev → Test deployment: Triggers a Power Automate flow that notifies QA reviewers. When QA signs off, they apply Promoted status to the Test dataset. Only after Promoted status is applied can the dataset be deployed to Production.
2. Test → Prod deployment: Triggers a certification review. After data stewards certify the Production dataset, it's published to the enterprise data catalog.

Using the Power BI REST API for Endorsement Automation

The Power BI REST API exposes endpoints for reading and setting endorsement status. Here's the relevant endpoint structure:

PATCH https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}

With a request body to set endorsement:

{
  "endorsementDetails": {
    "endorsement": "Promoted"
  }
}

For Certified status, the endorsement value is "Certified". Note that the calling service principal must have certification authority granted by an admin for Certified status — Promoted can be set by any authenticated user with Contributor access to the workspace.

To read the current endorsement status of all datasets in a workspace:

GET https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/datasets

This returns dataset metadata including the endorsementDetails object. You can script a check like this in PowerShell as part of a deployment gate:

function Get-DatasetEndorsementStatus {
    param (
        [string]$WorkspaceId,
        [string]$DatasetId,
        [string]$AccessToken
    )
    
    $headers = @{
        "Authorization" = "Bearer $AccessToken"
        "Content-Type" = "application/json"
    }
    
    $uri = "https://api.powerbi.com/v1.0/myorg/groups/$WorkspaceId/datasets/$DatasetId"
    $response = Invoke-RestMethod -Uri $uri -Method GET -Headers $headers
    
    return $response.endorsementDetails.endorsement
}

function Assert-DatasetIsPromotedBeforeProduction {
    param (
        [string]$TestWorkspaceId,
        [string]$DatasetId,
        [string]$AccessToken
    )
    
    $endorsement = Get-DatasetEndorsementStatus -WorkspaceId $TestWorkspaceId `
        -DatasetId $DatasetId -AccessToken $AccessToken
    
    if ($endorsement -ne "Promoted" -and $endorsement -ne "Certified") {
        throw "Dataset $DatasetId in Test workspace does not have Promoted or Certified status. " +
              "Obtain team approval and apply Promoted status before deploying to Production."
    }
    
    Write-Host "✓ Dataset endorsement check passed. Status: $endorsement"
}

This script can be integrated into an Azure DevOps pipeline as a pre-deployment gate. Before the deployment to Production is executed, the gate runs, checks endorsement status in the Test workspace, and fails the pipeline if the dataset hasn't been promoted. For a deeper look at automation patterns like this, see Implementing Power BI Deployment Pipelines with Git Integration and Azure DevOps for Automated CI/CD of Enterprise Reports.

Automating Certification After Production Deployment

Once a dataset successfully deploys to Production and passes post-deployment validation, you want certification to happen — ideally without requiring a data steward to manually hunt down the dataset in the workspace.

Build a Power Automate flow triggered by a custom HTTP request (call it from your deployment script) that:

1. Sends a Teams notification to the data stewardship channel with a deep link to the Production dataset
2. Creates an approval task assigned to the named data steward for this dataset domain
3. On approval, calls the Power BI REST API to apply Certified status using a service principal that has been granted certification authority

The certification call looks like:

function Set-DatasetCertified {
    param (
        [string]$WorkspaceId,
        [string]$DatasetId,
        [string]$CertifiedBy,
        [string]$AccessToken  # Must be a service principal with certification authority
    )
    
    $headers = @{
        "Authorization" = "Bearer $AccessToken"
        "Content-Type" = "application/json"
    }
    
    $body = @{
        endorsementDetails = @{
            endorsement = "Certified"
            certifiedBy = $CertifiedBy
        }
    } | ConvertTo-Json
    
    $uri = "https://api.powerbi.com/v1.0/myorg/groups/$WorkspaceId/datasets/$DatasetId"
    Invoke-RestMethod -Uri $uri -Method PATCH -Headers $headers -Body $body
    
    Write-Host "✓ Dataset $DatasetId certified by $CertifiedBy"
}

---

Building the Dataset Discovery Experience

Governance only works if the people it's designed to protect can find and trust the right datasets. The certification badge is only valuable if report builders know to look for it — and know what it means.

Cross-Workspace Dataset Sharing

When a dataset is certified in Production, it should be discoverable and connectable from any workspace in the tenant. In Power BI Desktop, when a report builder selects "Power BI datasets" as a data source, they see the dataset catalog. Certified datasets appear with a gold badge and surface at the top of results.

But discoverability requires that the Production workspace has appropriate permissions configured. Report builders need at least Build permission on the dataset to create reports against it. You have two options:

• Grant Build permission directly to security groups of report builders
• Share the dataset using dataset sharing (from the dataset settings in the service)

For enterprise scale, security group-based Build permissions are far more manageable. Define groups like SalesAnalytics_ReportBuilders and grant them Build on the Production dataset. Members of that group can then find the certified dataset, see its description, lineage, and certification details, and build reports against it — all without needing workspace-level access.

This is the implementing Power BI dataset sharing and cross-workspace live connections pattern at its most powerful: the certified Production dataset becomes a genuine enterprise semantic layer that many teams build on top of.

Annotating Datasets for the Catalog

Certification means nothing if the dataset has no description, no owner listed, and no documentation of what it contains. As part of your endorsement workflow, enforce these metadata standards before certification is granted:

In the dataset settings (accessible from the workspace in the Power BI service, then dataset settings → Description), set:

• Description: What business domain does this cover? What time range? What data sources? What's excluded? Write this for a report builder who has never seen the dataset before.
• Endorsement: Set to Certified with the data steward's name
• Data sensitivity label: Apply the appropriate Microsoft Information Protection label

You can validate that these are populated before triggering the certification REST call:

function Validate-DatasetMetadata {
    param (
        [string]$WorkspaceId,
        [string]$DatasetId,
        [string]$AccessToken
    )
    
    $headers = @{ "Authorization" = "Bearer $AccessToken" }
    $uri = "https://api.powerbi.com/v1.0/myorg/groups/$WorkspaceId/datasets/$DatasetId"
    $dataset = Invoke-RestMethod -Uri $uri -Method GET -Headers $headers
    
    $issues = @()
    
    if ([string]::IsNullOrWhiteSpace($dataset.description)) {
        $issues += "Dataset description is missing"
    }
    
    if ($dataset.description.Length -lt 100) {
        $issues += "Dataset description is too short (under 100 chars) - add meaningful documentation"
    }
    
    if ($issues.Count -gt 0) {
        Write-Error "Dataset metadata validation failed:`n$($issues -join "`n")"
        return $false
    }
    
    Write-Host "✓ Dataset metadata validation passed"
    return $true
}

For a comprehensive look at how certification workflows fit into a broader data catalog strategy, see Implementing Power BI Dataset Certification and Endorsement Workflows to Establish a Trusted Enterprise Data Catalog.

---

Managing Endorsement State Through Deployments

One problem that trips up many implementations: when you deploy from Test to Production using the pipeline, the deployment creates or updates the Production dataset — but endorsement state is not automatically carried forward. A Certified Production dataset that gets redeployed loses its Certified status.

This is actually by design. Each deployment to Production is a change event, and certification should be re-validated after significant changes. But it means your deployment workflow needs to handle re-certification.

Here's the pattern:

1. Before deployment, capture the current endorsement state of the Production dataset
2. Execute the deployment
3. Run post-deployment validation (data row counts, measure spot-checks, refresh test)
4. If validation passes and the pre-deployment state was Certified, trigger the re-certification approval flow

function Invoke-GovernedProductionDeployment {
    param (
        [string]$PipelineId,
        [string]$ProdWorkspaceId,
        [string]$DatasetId,
        [string]$AccessToken,
        [string]$CertificationWebhookUrl
    )
    
    # Step 1: Capture pre-deployment endorsement state
    $priorEndorsement = Get-DatasetEndorsementStatus `
        -WorkspaceId $ProdWorkspaceId `
        -DatasetId $DatasetId `
        -AccessToken $AccessToken
    
    Write-Host "Pre-deployment endorsement state: $priorEndorsement"
    
    # Step 2: Execute deployment via REST API
    $deployBody = @{
        sourceStageOrder = 1  # Test stage
        options = @{
            allowPurgeData = $false
            allowOverwriteArtifact = $true
            allowCreateArtifact = $false  # Don't create net-new in Production automatically
        }
    } | ConvertTo-Json
    
    $deployHeaders = @{
        "Authorization" = "Bearer $AccessToken"
        "Content-Type" = "application/json"
    }
    
    $deployUri = "https://api.powerbi.com/v1.0/myorg/pipelines/$PipelineId/deploy"
    Invoke-RestMethod -Uri $deployUri -Method POST `
        -Headers $deployHeaders -Body $deployBody
    
    Write-Host "Deployment initiated. Waiting for completion..."
    Start-Sleep -Seconds 30  # In production, poll the operation status endpoint
    
    # Step 3: Trigger re-certification if previously certified
    if ($priorEndorsement -eq "Certified") {
        Write-Host "Dataset was previously Certified. Triggering re-certification workflow..."
        
        $webhookBody = @{
            datasetId = $DatasetId
            workspaceId = $ProdWorkspaceId
            priorStatus = $priorEndorsement
            deploymentTime = (Get-Date -Format "o")
        } | ConvertTo-Json
        
        Invoke-RestMethod -Uri $CertificationWebhookUrl -Method POST `
            -Headers @{ "Content-Type" = "application/json" } `
            -Body $webhookBody
        
        Write-Host "Re-certification workflow triggered via webhook"
    }
}

---

Row-Level Security and Endorsement

A certified dataset that has misconfigured row-level security is worse than no certified dataset — it implies trust where trust isn't warranted. RLS validation should be a required checkpoint before certification is approved.

Your deployment pipeline stage rules don't directly validate RLS correctness, but your pre-certification checklist should include it. For each RLS role defined in the dataset:

1. Verify the role filter DAX expressions are syntactically valid
2. Spot-check with test users that each role sees the expected data
3. Confirm that users who should NOT have access to certain rows cannot access them

You can use the "Test as role" feature in Power BI Desktop during the development stage, and the "View as" feature in the service during the test stage. But for enterprise certification, document the expected behavior and have a QA analyst or data steward verify it explicitly.

For detailed guidance on RLS patterns in enterprise datasets, see Row-Level Security in Power BI. If your dataset also implements column or table-level restrictions, Implementing Object-Level Security in Power BI to Restrict Table and Column Access for Sensitive Enterprise Data covers the additional steps.

---

Monitoring and Drift Detection

After you've built this system, you need to maintain it. Drift happens: a dataset loses its Certified status after a deployment and nobody notices for two weeks. A stage rule gets manually overridden by someone with admin access. A gateway binding changes.

Audit Logging for Endorsement Events

The Power BI activity log captures endorsement events. Query it through the admin API:

function Get-EndorsementAuditLog {
    param (
        [string]$StartDate,  # Format: "2024-01-01"
        [string]$AccessToken
    )
    
    $headers = @{ "Authorization" = "Bearer $AccessToken" }
    $uri = "https://api.powerbi.com/v1.0/myorg/admin/activityevents" +
           "?startDateTime='${StartDate}T00:00:00'&endDateTime='${StartDate}T23:59:59'" +
           "&`$filter=Activity eq 'SetDatasetEndorsement'"
    
    $response = Invoke-RestMethod -Uri $uri -Method GET -Headers $headers
    return $response.activityEventEntities
}

Schedule this to run daily and feed results into your governance reporting dataset (which should itself be certified, naturally).

Endorsement Health Dashboard

Build a simple monitoring report over the activity log data that shows:

• Currently certified datasets by workspace
• Datasets that lost certification in the last 30 days and were not re-certified
• Datasets with Promoted status in Production (should not exist — Prod should be Certified or nothing)
• Average time from Promoted to Certified (a proxy for stewardship velocity)

This gives your data governance team a health dashboard for the lifecycle itself — not just the data products, but the process.

---

Hands-On Exercise

Let's put all of this together with a concrete implementation exercise. You'll build a governed lifecycle for a fictional "HR Headcount" dataset.

Setup: Create three workspaces: HR_Headcount_DEV, HR_Headcount_TEST, HR_Headcount_PROD. Create a deployment pipeline and assign them to Development, Test, and Production stages.

Step 1: Build the parameterized dataset

In Power BI Desktop, create a dataset with these parameters defined in the Power Query parameter manager:

• SourceServer (Text, current value: dev-sql.hr.corp)
• SourceDatabase (Text, current value: HR_DEV)
• MaxHistoryYears (Whole Number, current value: 2)

Build a simplified data model with a FactHeadcount table, a DimDepartment table, and a DimDate table. Use SourceServer and SourceDatabase in your data source configuration. Use MaxHistoryYears in a filter step to limit how far back you load historical data (in Dev, 2 years keeps the model fast; in Production, you might load 10 years).

Step 2: Configure stage rules

In the deployment pipeline, configure Test stage rules:

• SourceServer → test-sql.hr.corp
• SourceDatabase → HR_TEST
• MaxHistoryYears → 5

Configure Production stage rules:

• SourceServer → prod-sql.hr.corp
• SourceDatabase → HR_PROD
• MaxHistoryYears → 10

Step 3: Deploy to Test and apply Promoted status

Deploy the dataset from Dev to Test. Verify the stage rules applied correctly by checking the dataset settings in the Test workspace — it should show the test server connection. Then, in the Test workspace, navigate to the dataset, click the three-dot menu, and select "Endorse." Choose "Promoted" and save.

Step 4: Run the endorsement gate check

Using the PowerShell function from earlier in this lesson, run Assert-DatasetIsPromotedBeforeProduction. Pass your Test workspace ID and dataset ID. It should return a passing message.

Step 5: Deploy to Production and trigger certification

Deploy from Test to Production. Navigate to the Production dataset, verify it's connected to the Production server (check dataset settings → Data source credentials). Then trigger the certification: in the Power BI service, navigate to the dataset's three-dot menu, select Endorse, and choose Certified. Note the "Certified by" field — enter your name as the data steward.

Step 6: Verify the consumer experience

Open Power BI Desktop with a different user account (or ask a colleague). Select "Power BI datasets" as the data source. Search for "HR Headcount." The certified Production dataset should appear with a gold badge at the top of results, with your certification details visible.

Step 7: Simulate a redeployment and check drift

Make a minor change to the dataset in Dev (add a calculated column to any table). Deploy through the pipeline again. In the Production workspace, verify that the Certified status has been removed. This confirms the re-certification workflow trigger is needed — and motivates you to build the automation.

---

Common Mistakes & Troubleshooting

Stage rules don't apply after deployment

This usually means the parameter names in the stage rules don't exactly match the parameter names in the dataset. Parameter names are case-sensitive in stage rules. Open the dataset in Power BI Desktop, go to Home → Manage Parameters, and copy the parameter names exactly. Even a trailing space will cause a rule to silently not apply.

Certified status disappears but nobody deployed

Check the audit log for SetDatasetEndorsement events. If the endorsement was cleared but no deployment happened, someone manually removed it. Your governance model should restrict who can modify endorsement status — typically this means removing the Contributor role from people who shouldn't be able to apply or remove endorsements on Production datasets.

Dataset shows in search but report builders can't connect

They're missing Build permission on the dataset. Being able to see a dataset in search doesn't grant the ability to build reports against it. Navigate to the Production workspace, find the dataset, click the three-dot menu → Manage permissions, and add the relevant security group with Build permission.

Stage rules cause refresh failures after deployment

If the stage rule overrides a parameter to point at a data source that has a different schema (column names changed between Dev and Prod databases), the refresh will fail. This is a data source management problem, not a pipeline problem — your environments need schema parity. If they diverge, you need Query folding-safe transformations that handle missing columns gracefully, or a data source that keeps environments in sync.

Promoted status in Production workspace

This is a configuration drift signal. It means someone promoted the Production dataset without going through the full lifecycle, or a deployment happened without re-certification and the dataset ended up in a state where only Promoted was applied. Your monitoring dashboard should alert on this condition. The remediation is either immediate certification (if the dataset genuinely is Production-grade) or investigation into how it got there.

The REST API returns 403 on certification calls

The service principal or user account making the certification call hasn't been granted certification authority. A Power BI admin needs to go to Admin portal → Tenant settings → "Certification" and add the service principal's security group to the list of users who can certify datasets. This is a deliberate control — guard it carefully.

---

Summary & Next Steps

You've now built the framework for a genuinely governed data product lifecycle in Power BI. Let's review what you've implemented:

• Stage rules that enforce environment-appropriate data sources, parameters, and gateway bindings at each pipeline stage — making misconfiguration structurally difficult
• Endorsement mapping that assigns Promoted status as a test-stage checkpoint and Certified status as a production-stage designation, with named data stewards accountable for each
• REST API automation that validates endorsement state before deployment and triggers re-certification after Production deployments
• Consumer-facing discoverability through certified dataset catalog entries with meaningful descriptions and security group-based Build permissions
• Drift monitoring through activity log queries that detect endorsement state changes and surface them in a governance health dashboard

The next layer of maturity from here is integrating this lifecycle with your version control strategy. When your dataset source is managed in Git using TMDL, you can tie endorsement events to tagged commits — so "this dataset is certified" maps to a specific, immutable version of the semantic model definition. That's covered in Implementing Power BI Semantic Model Version Control with TMDL and Git for Enterprise Dataset Lifecycle Management.

You should also think about lineage. A certified dataset that gets used by 40 reports — what happens when you need to modify it? Implementing Power BI Workspace-Level Lineage and Impact Analysis to Manage Dataset Dependencies Across the Enterprise walks through how to map those dependencies before you make a breaking change.

Finally, if your organization uses sensitivity labels to classify data, the certification workflow should be coordinating with label assignment. A Certified dataset with no sensitivity label is an incomplete governance story — see Implementing Power BI Tenant Settings and Sensitivity Labels for Enterprise Data Protection and Compliance for how to close that gap.

The governance system you've built here isn't bureaucracy for its own sake. It's the infrastructure that lets your organization trust its data — and trust is what turns a collection of datasets into a genuine enterprise analytics capability.