---
title: "How do I create a pipeline?"
slug: "how-do-i-create-a-pipeline-in-admin-portal"
updated: 2026-10-16T12:42:27Z
published: 2026-10-16T12:42:27Z
canonical: "support.lusid.com/how-do-i-create-a-pipeline-in-admin-portal"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.lusid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How do I create a pipeline?

A pipeline is a named route to production for a single [target state definition](/v1/docs/how-do-i-create-a-target-state-definition-in-admin-portal): stages you name yourself, such as Dev, UAT and Production, in the order you want them, each holding its own domains.

Once you have created a pipeline, promoting a definition from development to test to production becomes a sequence of reviewed, approved steps you can follow on a single board.

> [!NOTE]
> **Note**: Pipelines are optional. You can [deploy a definition directly](/v1/docs/how-do-i-raise-a-deployment-request-in-admin-portal) to any domain without one. A pipeline adds the sequencing and the single board that shows how far a definition has travelled.

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/image-4I29OC9T.png?sv=2026-02-06&spr=https&st=2026-11-09T06%3A50%3A30Z&se=2026-11-09T07%3A50%3A30Z&sr=c&sp=r&sig=7w8fZn9syJeJ3v5AXI4ata91tIRfD9WNCt9HJdA5Fno%3D)

## Prerequisites

- A target state definition stored in a registered source. A pipeline promotes exactly one definition. [See how to create a definition](/v1/docs/how-do-i-create-a-target-state-definition-in-admin-portal).
- Access to the domains you want to include. Domains are listed by the cell that owns them, and you only see cells you have access to.
- The entitlement to request deployments. If you can see **Pipelines** under **Configuration Management** but the **New pipeline** button is missing, you have read-only access.

## Method

### Step 1: Open the pipeline editor

1. Navigate to **Configuration Management > Pipelines**.
2. Select **New pipeline**.

The editor opens with one stage already named **Development**, so the draft is valid straight away. Rename it if you want.

### Step 2: Name the pipeline and choose its definition

1. Enter a **Pipeline name**, for example `Config promotion`. Names must be unique among your pipelines, ignoring case.
2. In **Definition source**, choose the source that holds the definition. Sources that need attention are marked with a warning icon.
3. In **Target State Definition**, choose the definition this pipeline promotes. The list shows each definition's `scope/code` and title.
4. Optionally add a **Description**.

Changing the source clears the chosen definition, because a definition belongs to the source it was picked from.

### Step 3: Arrange the stages

Each stage is a step on the route. Configuration travels through them left to right on the board, in the order you set here.

For each stage:

1. Enter a **Stage name**, such as `Development`, `UAT` or `Production`. Every stage needs a name.
2. Pick a **Stage colour** from the seven swatches. The colour tints the stage's column on the board and helps you tell stages apart at a glance.
3. Optionally add a **Description**. It appears above the domains on the board.
4. Use **Add domain** to add each domain that belongs to this stage. Domains are grouped by cell. Within a stage, domains are deployed in the order listed. Use the up and down arrows beside a domain to reorder, or the cross to remove it.

To add another stage, select **Add stage** below the last one. Use **Move stage earlier** and **Move stage later** (the arrow buttons) to reorder, or **Remove stage** to delete one.

A few rules to know:

- A domain can appear in only one stage per pipeline. Domains already placed are removed from the **Add domain** list.
- A stage with no domains is allowed. This is how you plan a route before the domains exist. The board offers to add domains later.
- A pipeline can hold up to 20 stages and up to 100 domains in total.

### Step 4: Save

Select **Create pipeline**. The editor opens the new pipeline's board.

Saving a pipeline never deploys anything. It only records the route.

If you leave the editor with unsaved changes, Admin Portal asks whether to **Leave the editor** or **Stay here**.

[See how to raise a deployment request](/v1/docs/how-do-i-raise-a-deployment-request-in-admin-portal).

## Reading the pipeline board

The board shows one column per stage, joined by arrows. Each domain appears as a node showing:

- the revision of the definition last applied there, or **no revision**;
- a status chip: **Succeeded**, **Failed**, **Deploying now**, **Awaiting approval**, **Approved · ready**, **Behind latest** or **Never deployed**;
- change counts, labelled **applied** for what the last run did, or **expected** for what the next run would do. Expected counts are not read automatically. Select **Show expected changes** to compute them for every waiting domain on the board in one go.

Each stage column has a **Promote** button when any of its domains is behind the latest revision. Promoting raises one deployment request per domain that is behind, and each request still needs approval before it can be deployed.

## Linking and cloning a pipeline

Both actions appear on a pipeline's card in the list and in the board header. Both open the editor pre-filled, and nothing is saved until you select **Create pipeline**.

### Link: share one structure across several definitions

Use **Link** when you want to promote a different definition along exactly the same route, and keep the two routes in step. A linked pipeline inherits its stages, colours, descriptions and domains from the original. Any change to the original's structure applies to the linked pipeline immediately.

1. On the pipeline whose structure you want to reuse, select **Link**.
2. The editor opens titled **Linked pipeline** with a read-only **Inherited structure** panel. Give the pipeline a name (the suggested name is the original's name followed by `· linked`), choose the source and the **Target State Definition** to promote, and add a description if you like.
3. Select **Create pipeline**.

On the linked pipeline you can edit only the name, description and definition. To change the stages or domains, edit the original. The board shows a banner **Structure linked to [original]** with a link to it.

To break the link later, select **Detach** on that banner. The pipeline keeps a copy of the structure as it stands and stops following the original. Detaching deploys nothing and undeploys nothing.

### Clone: start from a copy you can change freely

Use **Clone** when you want a similar route that will diverge from the original.

1. On the pipeline you want to copy, select **Clone**.
2. The editor opens titled **Clone pipeline** with the stages, colours, descriptions, domains and definition copied in. The suggested name is the original's name followed by `(copy)`. Change whatever you need, including the definition.
3. Select **Create pipeline**.

A clone is independent. Later changes to the original do not reach it, and no run history is carried over.

|  | Link | Clone |
| --- | --- | --- |
| Structure | Inherited live from the original | Copied once |
| Changes to the original later | Apply to this pipeline too | Do not apply |
| What you can edit | Name, description, definition | Everything |
| Undo | **Detach** keeps a copy and breaks the link | Not needed |

## Editing and deleting a pipeline

- **Edit pipeline** on the board opens the editor. Saving replaces the whole route with what the editor shows. If other pipelines are linked to this one, the editor warns that your structure changes apply to them too.
- **Delete** on the board, or the bin icon on the card, removes the route. Nothing is undeployed: every domain keeps the configuration it has, and the deployments and their history stay under **Deployments**. Any pipelines linked to this one are detached and keep a copy of the structure.

## Monitoring

The pipeline board polls the runs it shows, so status chips and progress bars advance without a refresh. For run logs and full history, select a domain's name on the board to open its deployment detail page, or use the **Activity** and **History** tabs under **Configuration Management > Deployments**.

The **Pipelines** list can be narrowed with the search box and the filter chips **Has failures**, **Awaiting approval**, **Deploying now**, **Behind latest** and **Fully on latest**. The **Sort** menu offers **Needs attention first**, which brings failed and waiting pipelines to the top.

## FAQs

**Can I add an approval gate or a manual pause to one stage?** There is no per-stage setting, because every promotion already requires a second person to approve each request before it can be deployed. To hold configuration at a stage while you test, do not promote it further until you are ready.

**Can I promote out of order?** Yes. If an earlier stage is not on the latest revision, the **Promote** button for a later one is de-emphasised and its tooltip says the promotion skips a step, but it is still allowed. Every request is planned and approved on its own.

**Can one definition have several pipelines?** Yes. There is no limit. **Link** and **Clone** are the quickest way to make a second route for the same or a different definition.

**Can a pipeline mix domains from different cells?** Yes. The editor lets you pick domains from any cell you can see, and each domain's request is planned and approved on its own.

**What happens to runs in progress if I delete the pipeline?** They continue. Their history stays under **Deployments**, and the domain's **Deployed via** column reads **Deployed directly** once the pipeline is gone.

## Appendix: Limits

| Item | Limit |
| --- | --- |
| Stages per pipeline | 20 |
| Domains per pipeline | 100 across all stages |
| Definitions per pipeline | Exactly 1 |