Deployment pipelines

What it does

A pipeline is a chain of workspaces — typically development, test and production — with a deploy button between each pair. You assign a workspace to a stage, Fabric works out which items match across stages, and deployment copies content forwards, overwriting the matched item in the target.

Key facts

A pipeline has between two and ten stages. Three is the default and covers most clients.
Pairing is the mechanism that decides whether a deployment overwrites or duplicates. Items pair when you assign a workspace to a stage, or when unpaired content is deployed forwards for the first time. Paired items stay paired even if you rename them, so pairs can have different names in different stages.
Items added to a workspace after it was assigned to a pipeline aren't automatically paired. Same name, same type, same folder — still a duplicate on first deploy.
Deployment is forwards-only through the stages you configured, and you must select at least one item. Items that exist in the target but not the source are left alone.
Folder hierarchy is carried across on deployment. The default view only lets you select items within a single folder level; flat list view lets you select across folders.
The Power BI item types (report, semantic model, dashboard, dataflow, paginated report, org app) are currently listed as preview in the supported-items table, alongside a long list of Fabric items. Semantic models must originate from a .pbix and not be push datasets.
From 12 February 2026, pipelines stopped supporting semantic models that hadn't been upgraded to Enhanced Metadata. Old models sitting in a pipeline are a migration job, not a warning.
The pipeline itself needs a capacity behind it. Microsoft lists Deployment Pipelines as available both per-user (PPU) and per-capacity; a workspace on plain Pro shared capacity doesn't get them.
There's a REST API surface for pipelines, so you can drive deployment from Azure DevOps or GitHub Actions rather than clicking.
The redesigned pipeline UI is in preview as of the December 2025 revision of the docs, and has to be turned on.

When to use / skip

If the client has more than one person touching reports and any notion of "we shouldn't test in production", set this up on day one — it's an afternoon's work and it removes the single most common cause of embarrassing incidents. It's the cheapest ALM you can give a Power BI team.

Skip it if the client is genuinely one analyst publishing to one workspace, or if they already have a proper Git-plus-CI/CD story and pipelines would be a second, competing path to production. Running both without a documented rule about which one is authoritative is worse than running either.

Configuration decisions

How many stages, and whether "test" means UAT by the business or a technical smoke test. Three stages with an unused middle one is theatre.
Whether deployment is manual by a named release owner or automated through the REST API from a build pipeline. Pick one and take the button away from everyone else.
Where the semantic models live relative to the reports. Splitting model and report workspaces changes what each pipeline actually deploys and is worth settling before you assign anything.
Who holds workspace admin in each stage, because that's what actually controls who can deploy.
Whether pipelines or Git integration is the source of truth for the production definition. Both can be right; both being right simultaneously is not.

Gotchas

Pairing is where the day goes. Someone creates a report directly in test, someone else creates the "same" report in dev, first deploy produces two reports with identical names and nobody can tell which one the app points at.
Not all item properties travel. Schedules, permissions and some settings stay behind in the target stage by design — read the "item properties that are not copied" list before promising that a deployment reproduces the environment.
Data source connections do not change by themselves. Without deployment rules your production report will happily deploy pointing at the dev database.
The preview labelling on Power BI item types trips up governance reviews. It's been in production use for years; you may still have to explain the label to a risk officer.

Consultant notes

Sell it as the guardrail, not the automation. Clients hear "pipeline" and expect CI/CD; what they're getting is a controlled copy with a comparison view.
Set the deployment rules at the same sitting you build the pipeline. Every project that defers this ships dev connection strings to production at least once.
Get the workspace-to-stage mapping into the design doc. Reassigning a workspace to a different stage later has real consequences for pairing.
If the client's ambition is genuinely CI/CD with code review and branch policies, pipelines alone won't get them there — pair the conversation with Git integration and PBIP.

Worth a re-read whenever the new pipeline UI leaves preview, or the supported-items list changes again