---
title: Why HubSpot problems are architecture problems
description: "Why reports disagree and automations collide in HubSpot: the cause is usually the portal's architecture, not the tool. Start with the data model."
image: https://crmotive.com/hubfs/raw_assets/public/crmotive/images/og-image.png
---
[Skip to content](https://crmotive.com/blog/why-hubspot-problems-are-architecture-problems#top)
[](https://crmotive.com/)
[Services](https://crmotive.com/services) [Case studies](https://crmotive.com/case-studies) [Reviews](https://crmotive.com/reviews) [Blog](https://crmotive.com/blog) [About](https://crmotive.com/about) [FAQ](https://crmotive.com/help) [Book a call](https://crmotive.com/meeting)
[عربي](https://crmotive.com/ar-eg/blog/why-hubspot-problems-are-architecture-problems) [Book a call](https://crmotive.com/meeting)
[All posts](https://crmotive.com/blog)
# Why HubSpot problems are architecture problems
ArchitectureNov 13, 2026, 6:29:42 PMKareem
Why reports disagree and automations collide in HubSpot: the cause is usually the portal's architecture, not the tool. Start with the data model.
Two dashboards show different pipeline totals. A workflow assigns a lead that another workflow reassigned an hour earlier. Nobody is sure which deal property the forecast reads. When this happens, most teams look for the bug: a setting, a filter, a person who clicked the wrong thing.
In most portals we look at, there is no single bug. The portal grew one request at a time, and each request made sense on its own. After a few years, the parts no longer fit together. That is an architecture problem, and no amount of clicking inside the tool fixes it.
## What we mean by architecture
Architecture is the set of decisions about how your business is described inside HubSpot: what each record means, what facts you store about it, what stages a deal passes through, which automations act on what, and how you measure the result. Good architecture is boring. People can predict what will happen when they change something.
It has five layers, and each one depends on the one below it.
1. The data model: objects and how they connect.
2. Properties: the facts you store.
3. Pipelines and stages: how work moves.
4. Automation: what happens without a person.
5. Reporting: what you can trust the numbers to say.
Problems you see at the top, in reports and workflows, almost always start lower down. Let us take the layers in order.
## Layer 1: the data model
HubSpot gives you contacts, companies, deals and tickets, and on higher plans custom objects. Each one should answer one question. A contact is a person. A company is an organization. A deal is a sales opportunity. A ticket is a service request. The trouble starts when a team bends one object to carry something it was not built for.
A common example is storing a company name as text on the contact instead of creating a company record. It works for a month. Then you want to see all the people at one company, or report revenue by company, and you cannot. One of the portals we rebuilt had exactly this, along with a lead status field carrying jobs it was never designed for. Read how we fixed it in the Coursinity case study.
Questions to ask about your model:
- Can I name the one question each object answers?
- Is every person linked to the company they work for?
- Are deals linked to a company and a contact, so a report can follow the money?
- Are tickets linked to the same company record that sales uses?
## Layer 2: properties
Every property is a promise that someone will fill it in and someone else will use it. If neither is true, the property is clutter, and clutter has a cost: people cannot find the useful fields, and duplicate fields quietly split your data. Three habits keep properties healthy.
- **Name with intent.** The label is what people see, but the internal name cannot be changed after you create a property, so choose it carefully.
- **Prefer a list to free text.** A dropdown gives you clean groups to report on. Free text gives you twelve spellings of the same answer.
- **Give each property an owner and a group.** Someone should be able to say why it exists and who maintains it.
## Layer 3: pipelines and stages
A stage should describe a change in what is true about the deal, not a task someone has to do. If a rep cannot tell the difference between two neighbouring stages, the stages are doing no work, and the data in them will be wrong.
One portal we worked on, Ejari, ran more than 15 deal stages, and sales and qualification teams were working on the same deal object with no clear handoff. Leads fell through the cracks and progress reports were not accurate. We added a separate lead prospecting module so leads were managed in one place, away from deals, with a clear owner. We then cut the number of stages and replaced some with custom fields that act as gates a deal must pass. The full story is in the Ejari case study.
You can often use required properties on a stage so a deal cannot move forward until the facts are in. That turns your process into something the tool enforces, not something people are asked to remember.
## Layer 4: automation
Automation multiplies whatever it sits on. On a clean model, one workflow saves hours every week. On a messy one, it creates problems faster than anyone can fix them. In a portal we audited, over-automated ticket creation had produced more than 280,000 tickets and buried the support team. The automation was not broken. It did exactly what it was told, on a structure that could not support it.
- Give each workflow one job and a name that says what it does.
- Write down the trigger and who owns the workflow.
- Check what else changes the same property before you add another workflow that does.
## Layer 5: reporting
Reports are the last layer, and they inherit every weakness underneath. If two teams define a lead differently, or a deal can be created three ways, then two reports will disagree and both will be right. Fix the model, the properties and the stages first, and the dashboards mostly sort themselves out.
## Where to start
You do not need a rebuild to begin. Spend one hour with the people who use the portal and draw a single page: your objects and how they connect, the ten properties that matter most, your pipeline stages with the fact that must be true to enter each one, and your five most important workflows. Wherever the page is hard to draw or people disagree, you have found your architecture problem.
If that page shows more questions than answers, that is what a portal audit is for. Tell us what is broken and we will tell you where the structure is failing.
## Keep reading
- [Our HubSpot services](https://crmotive.com/services)
- [Case study: MyTable](https://crmotive.com/case-studies/mytable)
In this article
## Book a diagnostic call about your HubSpot portal
Tell us what is going wrong, such as reports that disagree or workflows that collide. We will tell you where to start.
[Book a diagnostic call](https://crmotive.com/meeting)
Architecting Systems. Accelerating Revenue.
[Book a call](https://crmotive.com/meeting)
- [kareem@crmotive.com](mailto:kareem@crmotive.com)
- [crmotive.com](https://crmotive.com)
- [LinkedIn](https://www.linkedin.com/company/crmotive)
- [Services](https://crmotive.com/services)
- [Case studies](https://crmotive.com/case-studies)
- [Reviews](https://crmotive.com/reviews)
- [Blog](https://crmotive.com/blog)
- [About](https://crmotive.com/about)
© 2026 CRMotive HubSpot, Odoo, lemlist, MigrateMyCRM and Coefficient are trademarks of their owners.
[Book a call](https://crmotive.com/meeting)
```json
{
"@context" : "https://schema.org",
"@id" : "https://crmotive.com/#org",
"@type" : [ "Organization", "ProfessionalService" ],
"address" : {
"@type" : "PostalAddress",
"addressCountry" : "EG",
"addressLocality" : "Alexandria"
},
"areaServed" : "Worldwide",
"email" : "kareem@crmotive.com",
"image" : "//47990825.fs1.hubspotusercontent-na1.net/hubfs/47990825/raw_assets/public/crmotive/images/og-image.png",
"knowsLanguage" : [ "en", "ar" ],
"logo" : "//47990825.fs1.hubspotusercontent-na1.net/hubfs/47990825/raw_assets/public/crmotive/images/crmotive-mark-color.svg",
"name" : "CRMotive",
"sameAs" : [ "https://www.linkedin.com/company/crmotive", "https://ecosystem.hubspot.com/marketplace/solutions/crmotive" ],
"url" : "https://crmotive.com/"
}
```
```json
{
"@context" : "https://schema.org",
"@id" : "https://crmotive.com/#website",
"@type" : "WebSite",
"inLanguage" : [ "en", "ar" ],
"name" : "CRMotive",
"publisher" : {
"@id" : "https://crmotive.com/#org"
},
"url" : "https://crmotive.com/"
}
```
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Kareem",
"url" : "https://crmotive.com/blog/author/kareem"
},
"dateModified" : "2026-11-13T18:29:42.655Z",
"datePublished" : "2026-11-13T18:29:42.000Z",
"headline" : "Why HubSpot problems are architecture problems",
"mainEntityOfPage" : {
"@id" : "https://crmotive.com/blog/why-hubspot-problems-are-architecture-problems",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject",
"url" : "https://crmotive.com/hubfs/__hs-marketplace__/CRMotive-logo-01-1-1-1-1-1-1.png"
},
"name" : "CR Motive Integrated Solutions"
}
}
```
```json
{
"@context" : "https://schema.org",
"@type" : "Organization",
"name" : "CRMotive",
"url" : "https://crmotive.com"
}
```
```json
{
"@context" : "https://schema.org",
"@id" : "https://crmotive.com/blog/why-hubspot-problems-are-architecture-problems#article",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Kareem"
},
"dateModified" : "2026-11-13",
"datePublished" : "2026-11-13",
"description" : "Why reports disagree and automations collide in HubSpot: the cause is usually the portal's architecture, not the tool. Start with the data model.",
"headline" : "Why HubSpot problems are architecture problems",
"image" : "//47990825.fs1.hubspotusercontent-na1.net/hubfs/47990825/raw_assets/public/crmotive/images/og-image.png",
"inLanguage" : "en",
"isPartOf" : {
"@id" : "https://crmotive.com/#website"
},
"mainEntityOfPage" : "https://crmotive.com/blog/why-hubspot-problems-are-architecture-problems",
"publisher" : {
"@id" : "https://crmotive.com/#org"
}
}
```
```json
{
"@context" : "https://schema.org",
"@id" : "https://crmotive.com/blog/why-hubspot-problems-are-architecture-problems#breadcrumb",
"@type" : "BreadcrumbList",
"itemListElement" : [ {
"@type" : "ListItem",
"item" : "https://crmotive.com/",
"name" : "Home",
"position" : 1
}, {
"@type" : "ListItem",
"item" : "https://crmotive.com/blog",
"name" : "Blog",
"position" : 2
}, {
"@type" : "ListItem",
"item" : "https://crmotive.com/blog/why-hubspot-problems-are-architecture-problems",
"name" : "Why HubSpot problems are architecture problems",
"position" : 3
} ]
}
```