A pipeline in HubSpot is the set of stages a record moves through from start to finish — and getting those stages right is one of the highest-leverage things you'll do in your portal. A good pipeline mirrors how work actually moves through your business, so every record's stage tells the truth and your reporting can be trusted. A bad one invents stages nobody uses, leaving deals stuck in limbo and reports that mislead. Here's the practitioner's read on setting up and managing object pipelines so they stay honest.
What is an object pipeline, and which objects can have one?
A pipeline is a sequence of stages that a record passes through, and in HubSpot you can build pipelines for deals, tickets, and custom objects. Deals move through a sales pipeline (from new to closed). Tickets move through a support pipeline (from received to resolved). Custom objects — anything specific to your business, like applications, orders, or onboarding projects — can have their own pipelines too. Each pipeline is just a defined path with stages, and each record sits in exactly one stage at a time. Worked example: a company runs one deal pipeline for new business and a separate one for renewals, because those two motions genuinely move through different steps.
How do you design stages that reflect reality?
Map the stages to how work actually progresses, not how you wish it did — every stage should mark a real, observable change in status. The most common mistake is too many stages, or stages that don't correspond to anything a person actually does. A stage should answer "what changed to get here" with a concrete answer: a meeting happened, a proposal was sent, a contract was signed. If two stages always get skipped together, they're really one. If reps can't tell which stage a deal belongs in, the stages aren't clear enough. Worked example: a team replaces a vague "in progress" stage with two precise ones — "demo completed" and "proposal sent" — and suddenly the pipeline shows exactly where deals stall.
How do you keep pipelines clean once they're live?
Define entry and exit criteria for each stage, and review the pipeline regularly so records don't rot in place. The setup is only half the job; the management is what keeps reporting trustworthy. Agree on what has to be true for a record to enter or leave each stage, so everyone moves records consistently. Then review on a cadence — deals with no recent activity, records stuck in one stage too long, anything with a close date in the past. A pipeline left unmanaged drifts within a quarter: stages get used inconsistently, old records pile up, and the reports built on them quietly stop being true. Required properties at key stages help enforce the discipline automatically.
When should you create a new pipeline versus add a stage?
Create a new pipeline when the work genuinely moves through a different path; add a stage only when there's a real new step in the existing one. Different motions deserve different pipelines — new business versus renewals, or sales deals versus a custom onboarding process. But resist spinning up pipelines for small variations; too many pipelines fragment your reporting and confuse your team. The same restraint applies to stages: more isn't better. This is exactly the order we set up with clients: map how work really flows first, build the minimum pipelines and stages that capture it honestly, then add complexity only when a real new path or step appears.
The IV-Lead take
Pipelines are the backbone of trustworthy reporting, and most portals get them slightly wrong in ways that compound. The fix is discipline, not features: design stages that mark real changes, set clear criteria for moving between them, and review the pipeline so records don't rot. Keep the number of pipelines and stages as small as the truth allows. Do that, and every report built on top — forecast, velocity, win rate — inherits the honesty. Skip it, and you'll spend more time arguing about whether the numbers are real than acting on them.
Pipeline stages that don't match how you actually work? Book a 30-minute portal audit — we'll look at your pipelines and stages and show you where they're costing you trustworthy reporting. For the bigger picture, see how we approach HubSpot implementation and optimization.
Frequently asked questions
How many stages should a HubSpot pipeline have?
As few as honestly capture how work moves — usually five to seven for a sales pipeline. Each stage should mark a real, observable change in status. If reps can't tell which stage a record belongs in, or two stages always get skipped together, you have too many.
Can I have more than one pipeline for the same object?
Yes. Deals, tickets, and custom objects can each have multiple pipelines — for example, separate deal pipelines for new business and renewals. Create a new pipeline only when the work genuinely moves through a different path, not for minor variations.
What's the difference between a deal pipeline and a custom object pipeline?
A deal pipeline tracks sales opportunities through closing. A custom object pipeline tracks any other process specific to your business — applications, orders, onboarding — through its own stages. Both work the same way: a defined path of stages, with each record in one stage at a time.
How do I stop deals from getting stuck in a pipeline?
Define clear entry and exit criteria for each stage, set required properties at key stages, and review the pipeline regularly for records with no recent activity or past-due close dates. Pipelines stay clean through management, not just good setup.
