Custom Object or Custom Property? How to Model Data the Right Way in HubSpot

Custom Object or Custom Property? How to Model Data the Right Way in HubSpot

One of the most important — and most misunderstood — decisions in building a clean, scalable CRM system in HubSpot is when to use a custom property, and when it’s time to introduce a custom object. It’s easy to start by adding a few fields to a contact or company record, but over time, poor data modeling choices can lead to cluttered records, duplicate information, broken workflows, and reporting that’s almost impossible to trust.

There’s a simple rule of thumb I’ve always followed:

If you find yourself creating fields like “Child 1,” “Child 2,” “Child 3” — you’re doing it wrong. That’s a strong signal you’re trying to store a one-to-many relationship using a flat list of fields, when what you really need is an object-based structure.

HubSpot gives you three primary tools for structuring your data: custom properties, custom objects, and now, with recent updates, associations with labels — including same-object associations. Each has a role to play depending on your use case, but choosing the right one can have lasting consequences.

Custom Properties: Best for Singular, Replaceable Values

Custom properties are the default tool for capturing individual data points. If a record will only ever need to store a single value for a given attribute — and if it’s perfectly fine for that value to be updated or replaced over time — a property is the right tool for the job.

For example, if you’re asking, “How many pets do you have?”, the contact record could simply store a number in a property called number_of_pets. That number might change — someone adopts a new dog, or a pet passes away — and it’s not critical to track the full history of that change. You're just interested in the latest state.

The benefit of using properties is their simplicity. They’re easy to segment on, easy to filter, and easy to report — assuming your data model doesn’t demand more complexity than a single field can offer.

Custom Objects: Built for Complexity and Context

Things get more complicated when you need to store multiple related entries for a single record. This is where custom objects come in.

Let’s say instead of asking “How many pets do you have?”, you want to know “What are the names and types of your pets?” That’s no longer a simple property. You can’t capture three dogs and a parrot using fields like pet_name_1, pet_name_2, pet_name_3 — at least, not without creating a messy, brittle structure that breaks the moment someone gets a fourth pet.

In this case, you’d create a custom object called Pet, with fields like Name, Species, and Adoption Date. You’d then associate one or more pet records to the contact who owns them. This gives you clean, repeatable records that can grow without limit — and lets you track changes over time, without ever overwriting past data.

The guiding principle here is context. If you need to retain history, store multiple instances, or report on relationships between entries, custom objects give you the structure to do that reliably.

Association Labels: The New Middle Ground

HubSpot recently introduced support for same-object associations, meaning you can now associate one contact to another, one company to another, and so on — and apply labels to define the relationship.

This opens up a new modeling option for situations where you don’t necessarily need a custom object, but you do need to capture structured relationships between existing records.

Let’s go back to our pet example. Suppose every pet is also a contact — maybe they’re clients in their own right (this is silly for pets, but very real for humans in a family, or for employees in a company). You don’t want to create a custom object just to relate them. Instead, you can use contact-to-contact associations and apply labels like Parent, Child, or Dependent to define how each record relates to another.

This approach lets you maintain separation between records while still tracking meaningful relationships — all without bloating your schema with unnecessary objects or duplicated data.

Final Thoughts: Get the Foundation Right

Choosing between custom properties, custom objects, and associations might seem like a technical decision, but it’s actually a strategic one. The structure you choose determines not just how you store data, but how you automate processes, build reports, and scale your CRM over time.

A flat, property-heavy system might feel easier at first, but it quickly becomes rigid and hard to maintain. On the other hand, introducing objects and associations too early — or unnecessarily — can complicate your setup without adding value.

The key is to model your system around how the data behaves:

  • If it’s one value, and it can change — use a property.
  • If it’s many values, and you want to track each instance — use a custom object.
  • If it’s a relationship between two records — use an association with labels.

Model it right the first time, and you won’t have to fix it later. That’s the real power of HubSpot’s CRM flexibility.

Josh McClanahan

Co-Founder & CEO at AccountAim

1w

This is great and an area that more RevOps teams should spend time. It can be a bit daunting at first if you've never thought through this in as much detail but will pay dividends down the line when you are trying to actually analyze what's happening in the business. Only small nit would be disagreeing that you shouldn't track the full history of a change. 100% of the time I'd rather have the history than not. It's really hard to know what data points you'll want to track or trend over time. Just default to tracking all of it.

Like
Reply
Peter Sterkenburg

Revenue Operations | Hubspot | B2B | SaaS | Customer-Led Growth

1w

I remember many a conversation we have had about that! 😅 Nice breakdown!

Like
Reply

To view or add a comment, sign in

Others also viewed

Explore topics