Guides
HubSpot Smart CRM and its data model explained
The HubSpot Smart CRM is the shared database that sits under every Hub. Its data model is built from objects (contacts, companies, deals, tickets, plus custom objects on higher tiers), the properties that hold each record's data, and the associations that link records together. A clean, well-designed model keeps reporting, automation and imports reliable, and prevents the mess that often forces a costly rebuild later.
The HubSpot Smart CRM is the shared database that sits underneath every Hub, and its data model is simply how that database is put together. Get the model right and reporting, automation and imports all just behave. Get it wrong and you will spend the next two years fighting your own setup, wondering why nothing quite adds up. I have seen both, and the difference is enormous.
What the Smart CRM actually is
HubSpot rebranded the underlying CRM as the Smart CRM. It is not a separate product you buy, and you cannot turn it off. It is the single foundation that Marketing Hub, Sales Hub, Service Hub, Content Hub and Operations Hub all stand on. When a form fills in on your website, when a rep logs a call, when a support ticket closes, all of it lands in the same place. Every Hub reads from and writes to the same set of records.
That matters because it gives you one version of the truth. You are not syncing a marketing database to a separate sales database and quietly praying they agree, which is the arrangement I have spent a fair chunk of my career untangling for people. The contact your marketing team nurtured is the same contact your sales team closes and your service team later supports. The “Smart” part is the AI and automation layered on top, and that gets the headlines, but the older idea underneath is the one that actually matters: one shared CRM for the whole business.
The building blocks of the data model
The HubSpot data model has four pieces. Learn these four and the rest of the platform stops feeling arbitrary and starts making sense.
Objects
Objects are the types of thing you store. The easiest way to picture each one is as a table. Every HubSpot account ships with four core CRM objects by default:
- Contacts are people, individual humans, with the email address acting as the unique identifier.
- Companies are organisations, the businesses those people work for.
- Deals are revenue opportunities: a potential or actual sale moving through your pipeline.
- Tickets are support or service requests, the things that need resolving.
On top of those, HubSpot bolts on objects like products, line items, quotes and, depending on your plan, leads. On Professional and Enterprise tiers you can also build custom objects, which let you model something specific to your business that genuinely does not fit the standard four: a membership, a vehicle, a property, a subscription, a course. Anything you need to report on and automate against that is not a person, a company, a deal or a ticket. The key word there is genuinely. More on that later, because reaching for custom objects too soon is one of the more common ways people tie themselves in knots.
Records
A record is a single entry within an object. One specific contact. One specific company. If the object is the table, each individual record is a row in it. That is the whole concept. It is not complicated, but it trips people up because the words get used loosely.
Properties
Properties are the fields that hold the data on each record. First name, lifecycle stage and original source are all contact properties. Deal amount and close date are deal properties. HubSpot ships with a generous set of default properties, and you can create custom ones to capture whatever your business actually needs to track. This is where a surprising amount of the design work lives, and where a lot of portals quietly go wrong. Every property you add is something that then has to be filled in, kept clean and reported on, forever. A property created on a whim is a small tax you pay every day after. Add them deliberately, not because you can.
Associations
Associations are the relationships that link records together. A contact is associated with the company they work for. A deal is associated with the contacts and the company involved. Associations in HubSpot are always two-way, so link a contact to a company and the company is automatically linked back to that contact. No need to do it twice. On Professional and Enterprise plans you can add association labels to describe the relationship, such as tagging one contact as the decision maker and another as the billing contact, which is genuinely useful once your deals involve more than one person.
Associations are what turn a flat list of names into a connected picture of your business. They are also, in my experience, exactly where badly planned setups come apart. Once the relationships are wrong, every report built on top of them inherits the same wrongness, and you end up not trusting numbers that are technically just doing what you told them to.
Why a clean data model matters
Almost every problem I get called in to fix traces back to the data model. Reporting that does not add up. Automation firing on the wrong records. Duplicate contacts breeding in the corners. Deals attached to the wrong company. These are hardly ever platform bugs, whatever the person who built it tells themselves. They are nearly always a model that was never properly designed in the first place, just assembled.
A well-designed model hands you a few things that are painful to retrofit later. Reporting works because the numbers live where the reports go looking for them. Automation behaves because your workflows enrol the right records on the right triggers. Imports stay clean because your spreadsheet columns map neatly onto real properties. And, crucially, your team trusts the system, which is the thing that actually drives adoption. A CRM nobody trusts is just an expensive address book.
The reverse is just as true, and rather more common. Properties created on a whim. Free-text fields where a dropdown belonged. Deals that should obviously have been tickets. Custom objects bolted on to paper over a structural gap nobody wanted to confront. Each shortcut feels harmless in the moment. Stack enough of them together and you get a portal nobody believes, where the fix is a full rebuild rather than a quick tidy-up. Death by a thousand reasonable-seeming decisions.
Getting the model right early
The cheapest time to design your data model is before a single record goes into it. Decisions about which objects you need, what your properties should be, how records associate and which fields are required cost almost nothing while the portal is empty. The very same decisions cost a fortune once you have hundreds of thousands of records, live workflows and reports the leadership team checks every Monday morning. Empty is cheap. Populated is expensive. Plan when it is empty.
This is exactly why a proper HubSpot CRM setup starts with the model, not with the buttons and the pretty bits. Map the objects to how your business genuinely works, define your properties with reporting firmly in mind, plan the associations, then build. If your portal is already live and starting to creak under you, a HubSpot audit and health check will surface where the model has drifted and what it would take to put it right, and more often than you would expect that is a fix rather than a full rebuild.
Moving from another system? The same thinking applies, just in reverse. A clean HubSpot migration is mostly an exercise in mapping your old data onto a sensible new model. The temptation is to copy everything across as-is, which is how you faithfully import all your old problems into a shiny new home.
Frequently asked questions
Is the HubSpot Smart CRM a separate product I have to buy?
No. The Smart CRM is the shared foundation that sits under every Hub, and the core CRM is free to start with. You pay for the Hubs and the tier of functionality you need on top, but the underlying CRM and its data model are the same for everyone, whether you are on the free plan or spending a fortune. The foundation does not change. What you build on it does.
What is the difference between an object and a property?
An object is a type of record, such as a contact or a deal. A property is a single field of data on that record, such as a contact’s email address or a deal’s amount. The spreadsheet analogy holds nicely here: objects are the tables, properties are the columns, and individual records are the rows. Keep those three straight and most of HubSpot clicks into place.
Do I need custom objects?
Probably not, and certainly not as early as you think. The four standard objects cover most businesses perfectly well, and custom objects are only available on Professional and Enterprise plans anyway. They earn their place when you genuinely need to track something that is not a person, company, deal or ticket, and not before. Reaching for a custom object too soon is one of the quickest ways I know to overcomplicate a setup that a well-named property would have handled fine.
A quick word before you build
If you are setting up a new portal, untangling an existing one, or simply not sure whether your model is the thing quietly holding you back, get a second opinion before the data piles up and the fix gets expensive. Get in touch and we can talk through what you are actually working with. The conversation is a lot cheaper than the rebuild.
Sources: