Set up project pipelines

Why a separate project pipeline

A deal closes when money is committed. A project closes when value is delivered. Jamming both workflows into the same stages forces one of them to be wrong. Project pipelines solve that by giving delivery its own stages, independent from the sales pipeline.

Multiple pipelines per tenant (e.g. "Delivery" vs "Consulting")
Custom stages with display order and color
Kanban board on /projects shows the active pipeline
Every project belongs to exactly one pipeline at a time

Estimated setup time: 10 minutes for the first pipeline.

Before you begin

Admin access is required to create and edit pipelines or stages.
Plan the stages on paper first — changing them later is easy, but cleaner on day one.
The default pipeline auto-assigns to any project created without one.

Create a pipeline

Start with one pipeline per delivery model.

1 Go to Settings → Project Pipelines.
2 Click New pipeline and name it (e.g. "Delivery", "Consulting", "Support").
3 Mark one pipeline as default — new projects without a pipeline land here.

Define stages

Stages describe the project's journey from start to finish.

1 From the pipeline detail, click Add stage.
2 Give the stage a name (Design, Build, QA, Deploy) and pick a color.
3 Drag stages to reorder them — the board shows them in the order you set.
4 Save — the stage now appears as a column on the project board.

Move projects through the pipeline

Day-to-day the team moves projects via the kanban board.

1 Open the Projects board.
2 Switch between pipelines with the tab selector at the top.
3 Drag a project card between stages — or use the stage selector on the project page.

Retire a pipeline safely

When a delivery model changes, move projects before removing the pipeline.

1 Decide which pipeline the remaining projects should move to.
2 Open Settings → Project Pipelines and click Delete on the old pipeline.
3 Choose the target pipeline and stage when prompted — all projects are reassigned.
4 The old pipeline and its stages are removed; project history stays intact.

Tips & best practices

Keep stage counts low — 4 to 6 is the sweet spot. More stages mean more admin friction.
Use colors that match urgency: cool for early stages, warm for at-risk stages.
Use a separate pipeline per business unit if work structures really differ — don't force a universal pipeline.
Closed / won-back / cancelled stages are useful at the end — they keep the board tidy without losing history.
Renaming a stage is fine and updates everywhere — no need to recreate.

Need help?

If a pipeline doesn't appear on the project board, check that it has at least one stage — a pipeline without stages is hidden by design.

Contact support

Design a delivery workflow for projects