How to Customize Your Data Model and CRM Objects in HubSpot
Start by mapping how your business actually works — the things you track and how they connect — then shape the record experience around it, because this structure is permanent and everything else you build inherits it.
A surprising number of HubSpot problems trace back to a decision made in the first week: how the CRM was structured. Teams rush past it, start adding fields and pipelines, and only later discover that records don't connect the way the business actually works, reps can't find anything, and reports don't add up. The fix is almost always a rebuild, because the deepest layer of a CRM — its objects and how they relate — is permanent.
Customizing your data model and CRM objects is the step that prevents all of that. It's less about settings and more about translating how your business operates into a structure the platform can run on, then making the day-to-day experience of your records match how your teams actually work.
What your "data model" actually is
Your data model is the shape of your CRM: the core "things" you track and the relationships between them.
Most businesses run on the four standard objects HubSpot provides — Contacts (people), Companies (organizations), Deals (revenue opportunities), and Tickets (support requests). The real work is deciding which of these you use, and how records connect: a contact to a company, a company to its parent company, one company to another as its accountant or referral partner. Those connections are what turn a pile of records into a map of your business.
Occasionally a business tracks something that genuinely isn't a person, company, deal, or ticket — a subscription, a property, a partner program with its own lifecycle. HubSpot can model that with a custom object, but it's the exception, not the default, and it's available only on higher tiers. Far more often, what looks like "we need a new object" is really "we track two different kinds of company," which is solved cleanly with a label on the relationship rather than a whole new object.
Why relationships deserve real attention
Linking two records tells you they're related. A relationship label tells you how — this contact is the "Decision Maker," that company is the "Accountant," these two companies are "Parent" and "Child."
That distinction matters more than it first appears. Labeled relationships are what let your automation and reporting get smart later: routing the right message to the right contact, showing which roles were involved in your won deals versus your lost ones, rolling child companies up to a parent. The catch is that this taxonomy is effectively permanent — once a label is in use you can't simply delete it — so it's worth deciding the full set deliberately, once, up front. HubSpot's own guidance on association labels and parent/child companies is a good reference for the mechanics.
Making records usable, not just correct
A correct structure that reps hate is still a failure. The second half of this work is the record experience: what someone sees and does when they open a record or scan a list.
That means tailoring the fields prompted when a rep creates a record by hand, the layout of the open record so the right information and cards sit up top, the preview that appears when a company shows up on a contact, and the columns, filters, and saved views that make your lists match how each team triages its day. A sales rep and a support agent need very different views of the same company — and when each team sees exactly what it needs and nothing it doesn't, adoption and data quality both climb. HubSpot supports team-specific record views on higher tiers, which is worth knowing when you plan this.
Why this is the foundation, not busywork
When your data model and records are set up properly, the payoff shows up everywhere downstream:
Everything you build next — properties, pipelines, automation, reporting, AI — snaps onto a structure that mirrors your business instead of fighting it. Your relationships carry meaning, so later automation and reporting can act on them. Your team can navigate records without friction, so they actually keep the data current. And because the hardest-to-change layer is done right the first time, you avoid the expensive rebuild that catches teams who skipped it.
How we approach it
We treat this as a strategy step, not a settings task. Before touching the platform we map your model — the things you track and how they connect — and walk you through that map until it's right and you've adopted it. Only then do we configure the objects, create the relationship labels, and confirm it all in HubSpot's data model tool so you can see and maintain it. Then we build the record experience around how your teams actually work, and validate the whole thing before it's final.
We keep the ceremony proportional to you. Some teams love sitting inside a data model; others just want it done. Either way the rigor is the same — the structure is permanent, so we get it right once.
Common questions
Do we need a custom object? Usually not. Most needs are met by the standard objects plus relationship labels. A custom object is worth it only when you track something with its own lifecycle and reporting, and it requires a higher HubSpot tier — so we test that need carefully before adding one.
Can't we change the structure later if we get it wrong? Some things, yes. But object types and internal names are permanent, and relationship labels can't be deleted once they're in use. That's exactly why we map and approve the structure before building on it.
Where do the actual fields come in? Defining and building your properties — the fields on your records — is its own step. This one sets up the objects, relationships, and record experience those fields live inside.
Get your data model right
If you want to learn more about how to get your data model right in HubSpot, contact The Gist.