Why Your HubSpot Portal Keeps Getting More Complex (And Never Simpler)

Last month I was auditing a HubSpot portal for a B2B SaaS company. About 120 employees. Series B. The kind of company where HubSpot is genuinely central to revenue operations.

They needed a new property to track whether prospects had attended their latest webinar series. Reasonable request. The marketing team created webinar_attended_q1_2026 as a single checkbox on the Contact object.

What they didn't do was search for existing properties first. When I ran the audit, I found three properties already tracking event attendance: event_attendance, webinar_attendee (created by a former marketing manager in 2024), and has_attended_event (created by an integration that had since been replaced). Different data types. Fill rates below 15%, all of them. Now there were four.

This portal had 437 custom properties. The team actively used about 90 of them. In the portal's entire history, not a single property had been deleted. No workflow had been archived. No pipeline stage removed. Everything was additive. The portal was a museum of every operational decision the company had ever made, including the ones that didn't work.

I've seen this pattern in every HubSpot portal I've analysed. The details differ. The direction never does: complexity only increases.

This isn't a HubSpot problem. It's a human problem.

The psychology: why we always add and never subtract

In 2021, researchers at the University of Virginia published a study in Nature that helps explain what's happening in every bloated CRM.

Across eight experiments, Gabrielle Adams and colleagues found that people overwhelmingly chose to add new elements rather than subtract existing ones, even when subtraction was clearly the better solution. Participants redesigned Lego structures by adding bricks when removing them would have been simpler. They improved essays by adding sentences when cutting would have improved clarity. They "fixed" itineraries by adding activities when removing one would have solved the scheduling conflict.

The finding wasn't that people couldn't think of subtractive solutions. It was that additive solutions came to mind first, automatically, with less cognitive effort. As the Harvard Business Review put it: "Our research shows that people systematically default to searching for additive transformations and consequently overlook subtractive transformations."

How addition bias plays out in CRM

Someone encounters a problem in HubSpot. A missing data point. An incomplete workflow. A gap in the pipeline. The instinctive response is to add something: a new property, a new workflow, a new stage. The question "could we solve this by removing something?" takes effort, and that effort rarely gets invested.

Three forces amplify the bias in CRM environments:

1. Loss aversion. Deleting a property feels risky. "What if we need it later?" Adding feels safe because it doesn't threaten anything that exists. The asymmetry isn't rational (unused properties are actively harmful), but it's powerful.

2. Complexity-as-status. A portal with 50 workflows and 400 properties looks more sophisticated than one with 15 workflows and 80 properties. Teams unconsciously equate complexity with maturity. But RevOps maturity is measured by how well what you've built works, not how much of it there is.

3. Sunk cost. "We spent three weeks building that workflow. We can't just delete it." Yes, you can. The time is spent regardless. The question is whether the workflow earns its continued existence or whether removing it makes the system better.

Where it shows up in HubSpot portals

The bias doesn't announce itself. It accumulates. Here's where I see it compound most.

Property sprawl

The average HubSpot portal I analyse has 300-500 custom properties across Contact, Company, Deal, and Ticket objects. Enterprise portals routinely exceed 1,000. The problem isn't the number. It's that only 30-40% are actively used.

Industry-wide, less than 30% of custom fields contain data in more than 10% of records. The fields exist. Nobody fills them. Nobody deletes them either, because "we might need them for reporting."

The accumulation follows a predictable pattern. A new campaign needs a tracking property, so one gets created. A departing employee's custom fields get left behind. An integration syncs 15 fields, three of which are useful. A sales manager adds qualification properties for a new outbound motion, and when the motion ends, the properties stay.

Each individual property seems harmless. Collectively, they turn the CRM into a maze that new team members can't navigate and experienced ones learn to ignore.

Workflow accumulation

I've audited HubSpot portals with 200+ active workflows where the team could confidently explain maybe 60 of them. The rest were built by former employees, created during a crisis that had long since passed, or designed to fix a problem that was later solved differently.

Nobody deletes workflows because nobody knows what depends on them. The CRM becomes a Jenga tower. Touch any piece and something downstream might collapse. So the team builds around the fragile parts instead. Another workflow on top.

The addition bias is especially visible here. When a workflow produces incorrect results, the instinct is to build a corrective workflow rather than fix or remove the original. I've seen chains of four workflows where the first created a data problem, the second attempted to correct it, the third handled the cases the second missed, and the fourth sent an alert when all three failed. Deleting the first workflow and addressing the root cause never occurred to anyone.

Pipeline stage inflation

Deal pipelines start clean. Four stages, maybe five. Clear criteria for progression. Then someone asks for a "Negotiation" stage between "Proposal Sent" and "Closed Won." Then a "Legal Review" stage. Then "Verbal Commit." Then separate stages for different product lines.

Within 18 months, a four-stage pipeline becomes eight or nine. Each stage was added for a reasonable purpose. But reps skip stages that add friction without adding value. Data entry increases. Reporting becomes inconsistent because deals don't follow the intended sequence. The granularity that was supposed to improve forecasting actually degrades it, because reps game the system or ignore it.

Salesforce's State of Sales research consistently finds that reps spend only 28% of their time actually selling. The remaining 72% goes to administrative work, data entry, and process compliance. Every unnecessary pipeline stage and redundant property contributes to that 72%.

Integration and custom object creep

Every new tool integration adds fields to HubSpot. Every new business model spawns custom objects. The additive logic feels inevitable: we need this data, so we need these fields.

But when you replaced Tool A with Tool B, did you also remove Tool A's synced fields? Almost certainly not. The old integration's properties linger, empty and confusing, while new integrations layer on top.

Custom objects follow the same pattern. Created for a specific use case, they persist long after that use case has evolved. Nobody deletes a custom object because the migration cost feels prohibitive. So the schema grows in one direction only.

The organisational amplifiers

Addition bias is a cognitive tendency. Organisations make it worse through three structural patterns.

Stakeholder appeasement. Every department needs properties in the CRM. Marketing wants campaign attribution fields. Sales wants deal qualification criteria. Customer success wants health indicators. Finance wants revenue recognition fields. Each request is individually reasonable. Nobody asks "can we reuse an existing field?" because each team frames their need as unique. You end up with overlapping properties that fragment the same data across multiple fields, and no single field that gives you a clean answer.

Turnover-created debt. A new CRM admin inherits a portal with 400 properties and 150 workflows. They can't tell which ones matter. They don't know the history. The documentation, if it exists, is outdated. The safest move isn't to clean up. It's to leave everything untouched and build new structures on top. Addition bias compounded by institutional knowledge loss.

Exception permanence. "Just add a custom property for this one customer segment." "Just build a temporary workflow for this campaign." "Just add a pipeline stage for enterprise deals." Each "just" is a permanent addition that never gets a sunset date. One-time exceptions become permanent infrastructure because nobody remembers they were supposed to be temporary, and nobody's job description includes removing them.

What CRM complexity actually costs

The damage from unchecked complexity is real, but most of it is invisible. That's why it persists.

That Salesforce statistic about reps spending 28% of their time selling? Most of that lost time isn't data entry. It's navigating a system that's harder to use than it needs to be. When reps face 300+ properties on a contact record, they waste time finding the right fields, entering data in the wrong ones, and working around a system that should be working for them.

A new hire's first week in HubSpot should build confidence. Instead, they encounter hundreds of properties they don't understand, workflow notifications they can't trace, and pipeline stages that don't match the sales process they were taught in training. The CRM teaches them, immediately, that the system isn't worth trusting.

When the same data lives in three slightly different properties, like those three event attendance fields, no single field tells the whole truth. Reporting becomes a matter of "which field do we use?" rather than "what does the data say?" Stakeholders lose trust in dashboards. RevOps loses credibility.

And then there's AI. Tools like HubSpot's Breeze, predictive scoring, and automated outreach all depend on clean, consistent, complete data. When your properties are sparse and duplicated, AI trained on that data produces confidently wrong outputs. Addition bias creates complexity for humans and degrades the data foundation that AI needs to work.

Every unnecessary property is a decision point for reps, a potential filter in reports, a field that integrations must map. Every redundant workflow is a maintenance liability and a potential source of data corruption. The marginal cost of one extra property is near zero. The cumulative cost of 200 extra properties is enormous, and nearly impossible to quantify until you start removing them.

How to reverse it

Addition bias can't be overcome by willpower alone. You need structural changes that make subtraction the default.

1. Audit before you add

Before creating any property, workflow, or pipeline stage, search for existing ones that serve the same purpose. Make this a gate in your governance process, not a suggestion. A simple search takes 30 seconds and prevents the slow accumulation that turns a clean portal into a cluttered one.

This is the single highest-leverage change. Most of the property sprawl I see exists because nobody checked whether a field already existed before creating a new one.

2. One in, one out

Every new property requires identifying one existing property to archive. Every new workflow requires reviewing one existing workflow for retirement. The ratio doesn't need to be exact. The point is to force the subtraction question into every addition decision.

This rule feels awkward at first. It becomes natural within a quarter. Teams start seeing archival candidates they'd previously ignored.

3. Sunset dates on exceptions

Every "temporary" or "one-time" workflow, property, or pipeline stage gets a review date. Write it in the property description or workflow name: [REVIEW: 2026-06-01]. If nobody renews the exception at review time, it gets archived.

Most exceptions don't get renewed. The ones that do earn their continued existence through explicit re-justification, which is exactly how governance should work.

4. The comprehension test

Can a new hire understand your CRM structure within their first week? Can they find the right properties, follow the deal pipeline logic, and understand which workflows affect their records?

If not, the system is too complex. Not "could be simpler," but actively too complex to serve its users. Use new hire confusion as a signal, not a training problem.

5. Fill rate as a kill signal

Properties below 10% fill rate for 90+ days are candidates for archival, not improvement. If nobody is filling a field after three months, the problem isn't adoption. The field doesn't serve a real workflow.

A data quality audit quantifies this across your entire portal. The numbers make the archival conversation objective rather than political.

6. Quarterly subtraction reviews

Dedicate one session per quarter specifically to removing things. Not adding. Not improving. Removing. Review unused properties, stalled workflows, and redundant pipeline stages with one question: "Does this earn its continued existence?"

Make subtraction a KPI. Track properties archived, workflows retired, stages consolidated. Celebrate simplification the way you celebrate new features. The team that treats removal as progress, not loss, builds a CRM that actually scales.

You can't subtract what you can't see

The subtraction framework works, but only if you know what's there. In a portal with 400 properties and 150 workflows, nobody has complete visibility.

Manual audits happen quarterly at best. In a growing company, the CRM changes daily. Fifty people modify records, create properties, run imports, adjust workflows. By the time the next audit happens, three months of additive drift have accumulated.

This is the gap that HubHorizon fills. It identifies unused properties, measures fill rates, maps workflow dependencies, and scores data quality across six dimensions. It gives you the data you need to make confident subtraction decisions: which properties are safe to archive, which workflows have no downstream dependencies, where complexity is accumulating fastest.

A composite health score shows whether your portal is getting simpler or more complex over time. Whether your governance practices are working, or whether addition bias is winning.

The tool doesn't make the subtraction decisions for you. It makes them possible by replacing "I think this is unused" with "this property has a 3% fill rate, isn't referenced in any workflow, and hasn't been updated in 8 months."

Start by removing one thing

You don't need to simplify your entire CRM at once. That kind of ambition is itself a form of addition bias: adding a massive cleanup project to an already overloaded RevOps backlog.

Pick one category instead. Properties, workflows, or pipeline stages. Run an audit. Find the five lowest-value items. The worst fill rates, the least activity, the most confusion. Archive them. Wait two weeks. See if anyone notices.

In my experience, the answer is almost always: nobody does. The CRM gets a little cleaner. Reps have slightly less noise to navigate. Reports become slightly more reliable. And the team starts to internalise something that addition bias makes hard to believe: removing things is progress.

The most useful work you can do in your HubSpot portal this quarter might not be building something new. It might be taking something away.

Frequently Asked Questions

What is addition bias in CRM management?

Addition bias is the cognitive tendency — documented by University of Virginia researchers — to solve problems by adding things rather than removing them, even when subtraction would be more effective. In CRM management it manifests as the instinct to create a new property instead of repurposing an existing one, add a new pipeline stage instead of clarifying an ambiguous existing stage, or build a new workflow instead of auditing whether existing automation still fires correctly. The bias is not a character flaw; it's a feature of how human cognition evaluates solutions, which means counteracting it requires deliberate structural habits rather than individual willpower.

How does property sprawl happen in HubSpot?

Property sprawl happens through the accumulative effect of individual decisions that each seem reasonable in isolation. A new campaign needs a tracking field; a new integration needs somewhere to store its data; a new reporting requirement needs a property that doesn't exist yet. None of these decisions are wrong individually. The problem is that HubSpot's property creation is frictionless, and there is no corresponding pressure to archive or remove properties when they become redundant. Over two or three years, a portal that started with 50 custom contact properties will commonly have 300 or more — most of which are empty, duplicated, or no longer connected to any active workflow or report.

How many custom properties should a HubSpot portal have?

There is no universal number, but fill rate is a more useful measure than count. If more than 40% of your custom properties have fill rates below 20%, your portal has more properties than your team can maintain. The practical test is whether your reps can find the fields they need without searching, and whether your reports use real data or mostly show blanks. Data quality audits surface fill rates across your full property set and identify which properties are genuinely used versus which are occupying space.

How do you simplify an overcomplicated HubSpot portal?

Start with a single category — properties, workflows, or pipeline stages — rather than attempting a full portal overhaul simultaneously. Within that category, identify the five lowest-value items by objective criteria: lowest fill rates for properties, least-triggered or highest-error workflows, stages with the highest average time-in-stage and no clear exit criterion. Archive those five. Wait two weeks. If nobody notices and nothing breaks, archive five more. The goal is to build organisational confidence that removal is safe, which counteracts the addition bias that created the complexity in the first place. A portal health check gives you the data to make these decisions with confidence rather than guesswork.

Start your free portal health check at hubhorizon.io — see which properties, workflows, and CRM structures are candidates for removal. View pricing plans for continuous monitoring that tracks whether your portal is getting simpler or more complex over time.

---

Peter Sterkenburg is the founder of HubHorizon, a HubSpot portal health and optimization platform. He's spent years in scale-up RevOps — building the systems, fighting the fires, and eventually building the tool he wished he'd had.