Removing Orphan Fabric Deployment Pipelines

Learn how to remove orphan Fabric Deployment Pipelines step by step. From grabbing a token in your browser to using admin-scoped APIs in Postman, this guide shows how to reclaim access, reassign admins, and clean up workspaces.

Removing Orphan Fabric Deployment Pipelines

Introduction

When working with Fabric, you might face a frustrating situation: an orphan Deployment Pipelines.

This happens when a pipeline was created without assigning admin rights to others, if the creator leaves the company or their account is deactivated, nobody can manage or delete that pipeline anymore, and it get even worse when there's a workspace assigned to any of its stages, because to delete a workspace, you first need to remove it from its pipeline 😬 ... If you don’t have admin access to the pipeline, you’re blocked 😒.

Many answers online simply say “use the Fabric Admin API”, without providing implementation details such as how to get an access token to interact with the API, which endpoints (Resource URI+HTTP method) to use, what permissions are required, etc., in this article, we’ll go step-by-step through the process and also explain how to interact with the Fabric Admin API 😉.

Setting the stage

Imagine you’re cleaning up workspaces in your tenant and you try to remove one that’s no longer needed, and you get the following error message...

Error message "This workspace is included in a deployment pipeline. Before deleting the workspace here, you must first remove it from the pipeline. Learn more"

This means that, the workspace is assigned to a stage within a deployment pipeline, like this ...

The good news is: you can fix this using the Fabric Admin API.


Pre-requisites

Before moving to the solution, make sure:

  • Have Fabric Admin permissions - I created this quick article to assist you
How to grant Fabric Admin permission?
Learn how to grant Microsoft Fabric Admin permissions step by step. This quick guide shows you where to go in the Microsoft 365 Admin Center, what prerequisites you need, and how to assign the role so you can manage Fabric capacities, deployment pipelines, and governance features.
  • Have Postman ready to make API calls - Offers an API platform for developers to design, build, test, and collaborate on APIs
🤔
Why Postman? By using Postman to send raw calls, you get a feel for the exact endpoints, headers, and tokens involved. Once you understand that, it becomes much easier to wrap it in PowerShell, Python, or any other scripting language later. Think of this as a hands-on learning exercise that builds the foundation for automation.

Solution

Before jumping in, let me point out something important: I could easily create a PowerShell script that automates this end-to-end — getting the token, calling the Fabric Admin API endpoints, cleaning up orphan pipelines. But in this article, I’m intentionally walking through the process manually. The goal is to help you see how the API works under the hood.

Step 1: Getting the Access Token

In this walkthrough we’ll use a signed‑in user account (not an app registration). I’ll grab the same token the browser uses when you’re in the Fabric portal and reuse it in Postman. This respects MFA and conditional access because you authenticate interactively in the browser first.

🤓
Every request must include an access token that proves who you are and what you’re allowed to do. The token carries your tenant, user identity, and granted permissions (e.g., Fabric Admin). No valid token → no API access.

Go to https://app.fabric.microsoft.com (or your Fabric portal URL) and sign in with the user account that has Fabric Admin rights, using your Web browser of choice, open its Developer tools and then go to Console and type powerBIAccessToken

Copy the token (string), I use the option Copy string contents 1️⃣

🛡️
Security note: Treat tokens like passwords. They usually expire within ~1 hour. Never commit them to Git or paste them in chats.

Step 2. Configure Postman Authorization

Open the Postman application and create/select a collection and Add Request 1️⃣, click on the Auth tab 2️⃣, from the Auth Type 3️⃣ select option Bearer Token 4️⃣ and copy/paste the token generated previously 5️⃣

Step 3. Identify the orphan pipeline

Now that you’re authenticated, invoke the Admin - Pipelines GetPipelinesAsAdmin endpoint to find the orphan 1️⃣ and copy the Id of the pipeline we want to remove 2️⃣

GET 
https://api.powerbi.com/v1.0/myorg/admin/pipelines
🤓
Microsoft Fabric’s REST APIs span multiple service domains; typically, user‑scoped endpoints let you list and manage only those pipelines you have access to, however, to locate orphaned deployment pipelines—those where no current user is assigned—administrators must use the admin group. The Pipelines.GetPipelinesAsAdmin endpoint returns all pipelines in the tenant, regardless of current access. After identifying the orphaned pipelines, the Pipelines.UpdateUserAsAdmin endpoint allows you to reassign administrative access and reclaim control—ensuring no pipeline remains inaccessible.

Step 3. Granting admin access to the pipeline

We need to grant ourselves admin access right to the pipeline first via another admin endpoint Admin - Pipelines UpdateUserAsAdmin

POST 
https://api.powerbi.com/v1.0/myorg/admin/pipelines/{pipelineId}/users

According to the documentation, in this case, you need to provide the endpoint 1️⃣ and a Body 2️⃣ and 3 key/value pairs 3️⃣, after invoking the endpoint, make sure you receive a 200 OK response code 4️⃣.

Step 4. Removing the Pipeline

Now we have all the pieces of this puzzle, we can now proceed to remove the pipeline invoking Delete Deployment Pipeline

DELETE https://api.fabric.microsoft.com/v1/deploymentPipelines/{deploymentPipelineId}

Step 5: Cleaning Up Workspaces

Once the pipeline is gone, you can safely manage the workspace 😅

  • Delete it if it’s no longer needed.
  • Or reassign it to another pipeline

Conclusion

Orphan pipelines are a common byproduct of people leaving organizations without reassigning ownership. They block workspace clean-up, add clutter, and pose governance risks.

It’s also important to understand the distinction between core and admin‑scoped endpoints. While the core API shows only the pipelines you personally have access to, the admin group provides tenant‑wide visibility. Endpoints such as Pipelines.GetPipelinesAsAdmin let you see all deployment pipelines in your environment, even those with no active admins. From there, Pipelines.UpdateUserAsAdmin enables you to reassign administrative access, effectively reclaiming orphaned pipelines without needing to delete them.

In other words, using the admin‑scoped APIs not only solves the orphan pipeline issue but also gives administrators governance tools to ensure no pipeline remains inaccessible in the future.


Call to Action

👉 Would you like me to share a full automation script that scans and removes orphan pipelines in bulk using PowerShell? Drop me a comment and let me know!