A pipeline is an ordered sequence of a project's connections that represents a deployment path, for example the route changes take through Development, Test, and Production. Pipelines live on a project's Pipelines tab.

What are connections in this context?

A pipeline is built entirely from connections that already belong to the project. Connections cannot be pulled in from a different project.

• Order is explicit. You set it when you build the pipeline, and it does not follow the connections' environment sort order.

• A connection can belong to multiple pipelines at once, with an independent position in each, but it can appear only once within a single pipeline.

• A pipeline can include any subset of the project's connections, including multiple connections from the same environment (for example, two Production connections, or a clone alongside Production), and it can skip environments entirely.

• Removing a connection from one pipeline does not affect its membership in any other pipeline, or in the project itself.

• Each connection's environment is shown alongside it in the pipeline, but does not constrain its position.

How pipelines relate to the Deployment Status Matrix

The Deployment Status Matrix can be scoped to a single pipeline. Its pipeline selector limits the matrix to that pipeline's connections, shown in the pipeline's order. A connection that belongs to the project but to no pipeline does not appear in any Deployment Status Matrix until it is added to one.

Who can create and change a pipeline

Seeing a project means seeing its pipelines. Anyone who can view a project sees that project's pipelines, the pipeline selector, and the Deployment Status Matrix scoped to a pipeline. There is no separate permission for viewing a pipeline.

Creating a pipeline, renaming it, reordering its connections, adding or removing connections, and deleting or restoring it are governed together, because reshaping a promotion path is one act. The Customer Admin and Platform/DevOps Engineer templates carry those permissions. Application Developer, DBA, and Security Reviewer see a project's pipelines but cannot change them, so a team that needs a new promotion path asks whoever holds one of the first two.

Note: Access is granted against a workspace or a project, never against a single pipeline. A pipeline cannot be named as the target of an assignment, and it cannot be granted or denied on its own.

A pipeline is never hidden because its connections are out of scope. Someone whose access is scoped to particular connections still sees every pipeline in the project and every connection in the selected pipeline, so the project's deployment picture stays intact. Their access decides which connections they can open from there, not which ones they can see.

Why use pipelines?

Pipelines let you model more than one deployment path within the same project, for example a standard release path through every environment alongside a hotfix path that skips straight from Development to Production. Scoping the matrix to one pipeline keeps it focused on the path you care about, instead of every connection in the project.