How to Define Your Data Model in HubSpot

Most CRM projects start in the wrong place. Someone opens HubSpot, starts adding fields, and begins entering data — before anyone has asked the most important question: how is this business actually structured?

That question is what a data model answers. And it's the one decision in a CRM setup you can't easily take back. Fields can be edited. Reports can be rebuilt. But the core structure — the kinds of records you keep and how they relate — is effectively permanent. Get it right and every later step gets easier. Get it wrong and you're not editing your CRM later, you're rebuilding it.

Here's what defining a data model actually means, why it matters more than it looks, and where we've learned to focus.

What a data model actually is

Strip away the jargon and a data model is just two things: the things you track, and how they connect.

Every CRM starts with a few universal building blocks — the people you deal with, and the organizations they belong to. Most businesses run on those plus the relationships between them. But most businesses also have something else at the center of how they operate: subscriptions, properties, partners, projects, accounts of different types. The data model is where you decide how each of those is represented, and how each one links to the others.

The connections are where the real value lives. It's not enough to know that two records exist — you need to know how they relate. Consider a business that keeps company records but, for every client company, also needs to know who that company's accountant is. That single requirement tells you two things: you need a way to distinguish a client company from an accountant company, and you need a defined relationship — an association — that links the two. Get that right and the CRM mirrors how the business actually works. Get it wrong and you're forcing your business to think the way the software happens to default to.

Why this is the foundation, not a formality

When your data model is defined properly before anything else, the payoff compounds across the whole platform:

• Your reports are accurate because the data is organized the way your business actually operates
• Automations have clean, reliable relationships to act on
• Segmentation is precise, because the distinctions you care about are built into the structure
• New objects and use cases slot in cleanly later, instead of forcing a painful re-architecture
• Everyone on your team reads the CRM the same way, because it reflects a shared model of the business

The reason this matters more than it looks: almost every other step in an implementation inherits the data model. Fixing a shaky foundation after you've built on top of it is one of the most expensive things you can do in a CRM. An hour of clear thinking here saves weeks of rework later.

Where teams go wrong

Modeling the tool instead of the business. The temptation is to accept the default building blocks as-is and pour the business into them. Sometimes that fits. Often it doesn't — and the mismatch shows up as awkward workarounds for years.

Ignoring the relationships. Teams will carefully list their records and completely skip how those records connect. But the associations — who relates to whom, and in what role — are usually where the business's real complexity lives, and where a good model earns its keep.

Naming things you can't rename. The internal names behind records and relationships are permanent, and relationships already in use can't simply be deleted. Deciding the full list up front — rather than inventing it as you go — is the difference between a clean model and one you're stuck with.

How we approach it

We treat the data model as a strategy step, not a configuration task. Before touching the platform, we map your world with you: the things you track, the different types within them, and how they all connect. We draw that as a clear, plain-language map you can actually read — and we refine it with you until it's right and you've adopted it.

Only then do we build it. We lean on the standard building blocks wherever they'll do the job, name your relationships deliberately, and reserve custom structures for the cases that truly warrant them. When we're done, your model isn't buried in settings — it's something you can see and edit yourself, so you own the foundation your CRM stands on.

The goal isn't a configured platform. It's a structure solid enough that everything you build on top of it just works.

Common questions

What's the difference between the data model and our fields/properties? The data model is the structure — the kinds of records you keep and how they relate. Fields (properties) are the details you store on those records. Structure comes first; the fields hang off it. We handle them as separate steps, in that order, on purpose.

We track something unusual — do we need a custom record type for it? Maybe, but often not. If the thing has its own life cycle and reporting needs, a custom record type can be the right call. If it's really just a different kind of company or person, it's usually cleaner to use a standard record and name the relationship. We'll help you tell the difference — over-building is a common and costly mistake.

Can we change the data model later if we get it wrong? Some parts, yes — but the core choices (the record types themselves and the names behind them) are effectively permanent. That's exactly why we invest in getting the map right and adopted before anything is built.

Get your data model right

Helpful HubSpot Articles

• Define your data model with recommendations
• Use the data model builder