HubSpot is simplifying its pipeline limits, giving customers more flexibility across deals, tickets, leads, custom objects, and other pipeline-enabled records.
Beginning September 3, 2026—or sooner for accounts that opt into the public beta—each HubSpot portal will have one shared pipeline limit across all object types. That limit will be based on the account’s highest subscription tier:
This is a welcome change. HubSpot’s previous limits varied by object type, subscription tier, and Hub, making it unnecessarily difficult to determine how many pipelines an account could create.
But—and this is important—more available pipelines do not mean your business needs more pipelines.
Pipeline sprawl is one of the most common HubSpot problems I’m called in to clean up. Before creating a new pipeline, I recommend coming back to one simple rule:
Pipeline = Process
A pipeline should represent a distinct business process, not simply a different team, region, product, branch, or reporting category.
A HubSpot pipeline is the series of stages a record moves through as a process progresses.
Depending on the object, that process might be:
Each stage should represent a meaningful milestone in that process. And the most common usage in HubSpot pipelines is tracking sales opportunities, for example, a new business deal pipeline might include:
The pipeline helps the team understand where each opportunity stands, what needs to happen next, and how effectively opportunities are progressing.
That is why the underlying process—not the team using the pipeline, the product you're selling, the region your team is working in, or team they are on—should determine whether you need another one.
Create a separate pipeline when records follow a materially different process.
As above, the new business and renewals are a good example. A new business process might include:
A renewal process might instead include:
These motions have different starting points, stages, timelines, automation, and outcomes. Trying to force both into one pipeline would create irrelevant stages and muddy important metrics such as conversion rates and pipeline velocity.
Separate pipelines make sense here because the processes are actually different.
Other reasons to consider a separate pipeline include:
The important phrase is materially different. A small naming preference or reporting distinction usually is not enough to justify another pipeline.
You probably do not need another pipeline when the process is the same but the records belong to different categories.
Common examples include:
Imagine your North American and European sales teams both follow the same stages:
Those teams can generally share one pipeline. A property such as Sales Region can distinguish North American opportunities from European opportunities.
From there, HubSpot views, filters, permissions, dashboards, and reports can give each team the information it needs without duplicating the pipeline.
The same goes for products. If Product A and Product B follow the same sales process, use a Product or Service property to categorize the deals. You do not automatically need a pipeline for each product.
A request to “see our records separately” is usually a filtering or reporting requirement—not a new pipeline requirement.
This distinction solves a surprising number of HubSpot architecture problems:
For example, if your East Coast and West Coast teams follow the same sales process, create a Region property and filtered views for each team.
If one team handles complex enterprise sales involving discovery, procurement, security reviews, and contract negotiations while another handles straightforward transactional purchases, separate pipelines may be warranted. In that case, the sales processes—not the teams themselves—are what justify the split.
There is another distinction that matters just as much:
Not every process belongs in a deal pipeline.
Because deal pipelines are flexible and familiar, there is a temptation to use them for almost everything. I regularly find portals with “deal” pipelines for:
These may all be legitimate processes that need stages, owners, automation, and reporting. That does not make them deals.
A deal should represent a revenue opportunity or revenue-related commercial motion. That can include new business, renewals, expansions, and upsells. If there is no potential or committed revenue to track, a deal is probably not the right record.
Making everything a deal can distort:
It also fills the deal record with information it was not designed to hold. Teams may start entering placeholder amounts, artificial close dates, or fake closed-won outcomes simply because the system requires deal fields that do not make sense for the process.
That is usually a sign that the process belongs somewhere else.
Depending on what you are managing, the better option may be:
A custom object should not necessarily be the first answer, either. Start by asking whether one of HubSpot’s existing objects was designed for the process. Custom objects are most useful when the record represents a distinct business entity with its own properties, associations, workflows, and reporting needs.
The goal is not to find a way to turn every process into a deal. It is to choose the object that best represents what the record actually is.
Pipeline sprawl usually begins innocently. A new team, product, or market is introduced, and creating another pipeline feels like the fastest way to organize it.
Over time, a portal might accumulate pipelines such as:
Then someone has to report across all of them.
The result is not more organization. It is more administration and less reliable data.
When similar opportunities are spread across multiple pipelines, every report has to account for every variation. Comparing conversion rates, forecasting revenue, or calculating total pipeline value becomes more complicated than it needs to be.
Stage-based workflows, notifications, required properties, task creation, and internal handoffs may need to be rebuilt for each pipeline. When the process changes, someone has to remember to update every version.
One pipeline uses “Proposal Sent,” another uses “Proposal Delivered,” and a third uses “Pricing Shared”—even though all three mean the same thing. That inconsistency makes cross-pipeline reporting less dependable.
Before creating a record, users have to determine which pipeline it belongs in. If the differences are unclear, records end up in the wrong place or teams create their own workarounds outside HubSpot.
Every pipeline introduces more stages, automation, permissions, documentation, and reporting logic to maintain. Flexibility is helpful. Unnecessary complexity is not.
Before adding another pipeline, ask:
These questions help separate three decisions that are often mistakenly treated as one:
Answer them in that order.
Under HubSpot’s simplified model, an account’s highest subscription tier will determine the total number of pipelines it can create across all object types.
For example, an account with Marketing Hub Professional and Sales Hub Starter would receive the Professional limit of 100 shared pipelines.
HubSpot is also removing the previous Hub requirements for deal and ticket pipelines. All Hubs will have access to pipelines for supported object types, making pipeline access more consistent across the platform.
To manage pipelines in HubSpot, go to:
Settings → Data Management → Objects → Select an object → Pipelines
To review your account’s total pipeline usage, go to:
Data Model → Limits → Pipelines
The new limits provide welcome flexibility, particularly for organizations managing several legitimate sales, service, and operational processes. But the number available should be treated as a limit, not a goal.
An Enterprise account may be allowed to create 350 pipelines. That does not mean anyone should be aiming for pipeline number 350.
Good HubSpot architecture should make the portal easier to use, report on, and maintain.
Before building a pipeline, document the process it needs to support:
Once those questions are answered, the correct pipeline and object structure usually becomes much clearer.
Start with the fewest pipelines needed to represent the real processes. Use properties, views, filters, and reports to accommodate different teams and categories. Use deals for revenue motions and select a more appropriate object for everything else.
HubSpot’s simpler pipeline limits are a positive change. Customers will have clearer rules and more room to build the processes their businesses need.
Just remember:
Pipeline = Process. But not every process = Deal.
If the process is different, consider a separate pipeline. If the process is the same, use your data structure to create the separation you need. And if the process is not revenue-related, think twice before putting it on the deal object.
Beginning September 3, 2026, HubSpot’s shared pipeline limits are 15 pipelines for Starter accounts, 100 for Professional accounts, and 350 for Enterprise accounts. Free accounts cannot create custom pipelines. The limit is shared across all object types and is based on the portal’s highest subscription tier.
No, absolutely not. Teams should share a pipeline when they follow the same sales process. Properties, saved views, filters, dashboards, and permissions can separate each team’s records without duplicating the pipeline.
Again, no—unless those regions follow materially different processes. If they use the same stages, create a Region property and use filtered views and reports instead.
New business and renewals should use separate pipelines when they have different stages, timelines, automation, requirements, and outcomes. Because managing a renewal typically differs from acquiring a new customer, separate pipelines are often appropriate.
No. The deal can represent the sale, while the onboarding process is managed through a project, service, ticket, or custom object. Keeping those records associated allows teams to connect the sale with the resulting work without distorting deal and revenue reporting.
Technically, it can—but that does not mean it should. Using deals for non-revenue processes can distort forecasting, win rates, average deal size, velocity, and other sales metrics. A ticket, project, service, lead, or custom object will usually provide a cleaner data model.
Yes. If the products follow the same sales process, they can share a pipeline and be identified through a Product or Service property. Separate pipelines are appropriate only when the products require materially different sales processes.
Pipeline sprawl occurs when an account creates more pipelines than its business processes require. It can lead to fragmented reporting, duplicated automation, inconsistent stages, user confusion, and unnecessary administrative work.