Multiple pipelines let one CRM run separate sales processes side by side — typically new business, renewals and partner-sourced deals. In Treepie Flow each pipeline has its own stages, stage probabilities and required fields, while every pipeline reads the same companies, contacts and activity. One customer can have an expansion deal and a renewal open at the same time, and the forecast weights each by its own odds.
A single pipeline forced to serve several motions ends up with stages that mean different things to different teams. Renewals do not have a discovery stage. Partner deals do not qualify the same way. Bending one pipeline to fit all of them is how stage names stop meaning anything.
Separate pipelines for separate sales motions — new business, renewals, partner-sourced — each with its own stages, probabilities and required fields, all reading the same customer records underneath.
Each pipeline defines its own stages, entry criteria and probability weighting. A customer can have deals in more than one at once — a renewal and an expansion — without either being duplicated, because both point at the same company record.

A company runs three: new business with a six-stage qualification path, renewals with three stages and no discovery, and partner-sourced deals that enter already qualified. Kanaka Foods has a deal in two of them at once. Both point at the same company record, so the renewal knows about the expansion and support load is visible to whoever is working either.
Separate pipelines will not fix a team that disagrees about what a stage means — they will localise the disagreement, which is usually enough to resolve it. Splitting a pipeline for every product line tends to produce forecasts nobody can combine; two or three motions is the range most companies actually need.
Forecasts can be read per pipeline or combined. Because the underlying customer is shared, a renewal deal knows the support load and open invoices on that account without anyone joining two reports.
| One pipeline for everything | A separate tool per team | Treepie Flow | |
|---|---|---|---|
| Stages | Every stage for every motion, most skipped | Right stages, different systems | Right stages per pipeline, one system |
| Probabilities | One set for all deals | Separate, but never combined | Per pipeline, combined correctly |
| Customer record | One, but cluttered | Duplicated in each tool | One record read by every pipeline |
| Forecast | Under- or over-weights renewals | Added up by hand | Weighted per pipeline, totalled automatically |
| Moving a deal | No structure to move between | Re-typed into the other tool | Moved with its history intact |
Unlimited per account, with up to twenty stages each.
Yes, and the move is recorded. Stage mapping is chosen at the point of the move rather than guessed.
It can have one, and they roll up. Reading them separately is usually more useful because the motions convert at different rates.
One per genuinely different way of selling — usually new business, renewals and, if you have them, partner deals. Splitting by team or region is better handled with filters and permissions.
Yes. Stage names, order, entry criteria and probabilities are all set per pipeline.
Yes. A rep sees every pipeline they have access to, and can view their deals across all of them at once.
Existing reports keep working and gain a pipeline filter. Combined reports weight each pipeline by its own probabilities.
Yes. Stage automations belong to a pipeline’s stages, so a won renewal can raise an invoice while a won new-business deal opens a project.
No. Pipelines hold deals; companies and contacts are shared, so a company appears once however many pipelines it is in.
Yes. A partner pipeline can require the partner, a renewals pipeline the contract end date, without forcing those fields on anyone else.
No. They are part of Flow; the pricing page lists which plan includes each feature.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.