Project pipelines are separate from sales pipelines. Build one that reflects how your team actually delivers work.
5 min read
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 it's cleaner on day one.
The default pipeline auto-assigns to any project created without one.
1
Create a pipeline
Start with one pipeline per delivery model.
1Go to Settings → Project Pipelines.
2Click New pipeline and name it (e.g. "Delivery", "Consulting", "Support").
3Mark one pipeline as default: new projects without a pipeline land here.
2
Define stages
Stages describe the project's journey from start to finish.
1From the pipeline detail, click Add stage.
2Give the stage a name (Design, Build, QA, Deploy) and pick a color.
3Drag stages to reorder them. The board shows them in the order you set.
4Save. The stage now appears as a column on the project board.
3
Move projects through the pipeline
Day-to-day the team moves projects via the kanban board.
1Open the Projects board.
2Switch between pipelines with the tab selector at the top.
3Drag a project card between stages, or use the stage selector on the project page.
4
Retire a pipeline safely
When a delivery model changes, move projects before removing the pipeline.
1Decide which pipeline the remaining projects should move to.
2Open Settings → Project Pipelines and click Delete on the old pipeline.
3Choose the target pipeline and stage when prompted, and all projects are reassigned.
4The 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, so there's no need to recreate it.
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.
Essential cookies and privacy-friendly traffic analytics (Cloudflare) run by default. With your consent, we additionally use Microsoft Clarity to record anonymised sessions on this page so we can improve it. Clarity is never used inside the signed-in CRM app.
Learn more in our Privacy Policy.
