A deployment pipeline copies Power BI content from one workspace to the next, typically Development to Test to Production, so you can test changes before your users see them. To create one you need to be an admin of a workspace. Every workspace in the pipeline must also sit on a capacity that supports pipelines: a Fabric F capacity or trial, Premium Per User, a Power BI Premium P capacity, or an A or EM SKU (Power BI Embedded's legacy capacity tiers). A workspace on Pro alone cannot be used. Then you go to Workspaces > Deployment pipelines > Create pipeline, name your stages and assign one workspace to each.

What a deployment pipeline does

Each stage of a pipeline is a workspace. When you deploy, Fabric copies the selected items from the source stage to the target stage and overwrites the matching items there.

Pipelines do three things well:

• Separate environments. Developers work in Development, testers review in Test, and business users only ever see Production.

• Change settings per stage. Deployment rules point the same semantic model at a test database in Test and the production database in Production.

• Show what changed. You can compare two stages before deploying and see the deployment history for each stage.

What pipelines do not do is version control. There is no rollback to an earlier version. For that, use Fabric's Git integration alongside the pipeline.

Prerequisites

If you use PPU workspaces, only other PPU users can open the content. For a large Production audience, an F64 or larger capacity is usually the better home for the last stage. Our Power BI license guide explains why.

Step 1: Create the pipeline

1. In the Fabric portal, open the Workspaces flyout and select Deployment pipelines.

2. Select Create pipeline or + New pipeline.

3. Enter a name and a description, then select Next.

You can also start from inside a workspace you administer, by selecting Create deployment pipeline. That workspace is assigned to the pipeline automatically.

Step 2: Define the stages

The pipeline starts with three stages: Development, Test and Production. While you are setting it up, you can rename them, add stages or remove them, from 2 up to 10.

Decide carefully. Once you select Create, the number of stages is fixed. You can still rename stages later.

Step 3: Assign a workspace to each stage

Assign an existing workspace to a stage. You can assign one workspace and deploy it forward to create the others, or assign a different existing workspace to each stage.

When you assign a workspace, Fabric pairs its items with the matching items in the neighboring stage. Paired items overwrite each other on deployment. Items that are not paired, even if they have the same name, create a duplicate instead. This is the most common surprise in pipelines. Assign workspaces before you add content where you can, and check that items show on the same line in the pipeline view.

Step 4: Deploy content

Select the source stage and choose one of three options:

• Full deployment: deploy everything in the stage.

• Selective deployment: pick the items to deploy. Select a report together with its semantic model if both changed.

• Backward deployment: deploy from a later stage to an earlier one. This only works when the target stage is empty.

Review the comparison, add a note, and select Deploy.

Step 5: Add deployment rules

Rules let each stage keep its own settings. The most common rule changes a semantic model's data source or parameter in Test and Production, so Development queries sample data and Production queries the full database.

To create one, open the target stage, select the semantic model, and define the rule. Rules apply on the next deployment. You must be the owner of the semantic model to configure its rules.

Automate it

Pipelines have REST APIs, so you can trigger deployments from Azure DevOps or GitHub Actions after your checks pass. Start manually until the process is stable, then automate the Test to Production step.

Common problems

• A deployment created duplicates. The items were not paired. See Step 3.

• A semantic model fails to deploy. Check that it uses enhanced metadata, and that DirectQuery or composite models do not contain auto date/time tables. Pipelines do not support those.

• A newly deployed semantic model is empty. Deployment copies item definitions, not data. Refresh the semantic model in the target stage after its first deployment.

• Rules did not apply. Rules take effect on the next deployment, and only if you own the semantic model.

For how workspaces, roles and apps fit together around a pipeline, see our guide to Power BI workspaces and apps. If you are deciding whether to move to Fabric capacity at the same time, read Why choose Microsoft Fabric.

FAQs

Do I need Power BI Premium for deployment pipelines?

You need a capacity or license type that supports them: a Fabric F capacity or trial, PPU, a P capacity, or an A or EM SKU. Pro alone is not enough. Because Microsoft is retiring P SKUs, new setups normally use an F capacity or PPU.

How many stages can a pipeline have?

From 2 to 10. The default is three: Development, Test and Production. The number cannot change after you create the pipeline, but you can rename stages.

Can I roll back a deployment?

Not directly. Pipelines keep a deployment history, but not previous versions to restore. Connect the Development workspace to Git, restore the earlier version from the repository, and deploy it forward again.

Do deployment pipelines refresh data?

No. They copy item definitions, not data. Refresh a semantic model in the target stage after it is deployed there for the first time, and after any change that needs a refresh.

Sources

• Overview of Fabric deployment pipelines - Microsoft Learn

• Get started with deployment pipelines - Microsoft Learn

• Fabric lifecycle management FAQ - Microsoft Learn