How to decide when HubSpot custom objects are worth the overhead for your data model.
When a new property is enough in HubSpot
The fastest way to wreck a HubSpot portal is to treat every data problem as a custom object problem. The second fastest is to treat none of them that way.
Most mid-market teams end up in one of those camps because creating a property feels like a five-minute decision and creating a custom object feels like calling an architect. So teams either keep stacking properties until the Company record looks like a junk drawer, or they spin up one-off objects that fall apart the first time someone tries to build a real report.
The baseline distinction
If you do not understand how HubSpot thinks about properties versus objects, you will overcomplicate simple use cases and oversimplify the ones that actually need more structure.
Here's the simplest way I can put it: a property describes a record. A custom object is a record. A property is "what color is the car." A custom object is "the car."
A property is an attribute of a record
A property answers questions like:
- What is this account's renewal date?
- How many active licenses does this customer have?
- Is this contact part of the buying committee?
A custom object is a thing
A custom object can exist on its own, be associated with other records, and have its own properties and lifecycle.
Examples include:
- Contract
- Location
- Implementation Project
- Installed Asset
The real question to ask
For many B2B mid-market teams, the question is not, Should we use custom objects? You probably already should be in at least some parts of the portal.
The better question is: Where is our current property sprawl hiding a data model that wants to be explicit?
What property sprawl usually signals
You can usually feel it before you can name it. Reports take three exports and a VLOOKUP to answer a question your CEO asks in a Slack message. Onboarding hands off to Service, and something always gets lost in the translation. Your Zapier-and-prayer integration breaks every time someone renames a property.
None of these feel like data model problems in the moment — they feel like people problems, or tooling problems, or "we just need better process" problems. They aren't. They're your schema, quietly charging interest.
That's usually the point where this turns into Data Architecture & Analytics work, not because anyone wants fancy ERDs, but because the day-to-day business questions cannot be answered reliably:
- MRR by location
- Renewals by product line
- Installs by region
Patterns that actually need a custom object
The places where you truly need a new object are almost always about repeating structure, distinct lifecycles, or distinct owners.
Repeating structure
If you find yourself jamming lists into a single field — multiple contracts in one long text property, multiple locations in a comma-separated string — that's a smell. You're hiding rows inside a cell. Reporting, automation, and permissions will all suffer.
A simple pattern many B2B teams run into:
- One company works with you across multiple physical locations
- Each location has its own install base, on-site contacts, and renewal dates
- Finance wants to see ARR by location; Sales wants renewal workflows by site; Service wants tickets tied to a specific asset at that site
You can fake this with custom properties on the Company record — Location 1 Address, Location 2 Address, Location 3 Address, and so on until someone in Finance asks for ARR by site and the whole house of cards comes down. A Location custom object associated to Company, Deals, and Tickets does what the properties were pretending to do — except it actually works when the questions get harder.
Distinct lifecycle
If the "thing" moves through its own stages that don't match any existing object, consider a custom object. Implementation projects are a good example — a project has milestones and owners that don't match a sales Deal or a support Ticket.
For many mid-market teams, an Implementation Project custom object with stages like Planned, In Progress, At Risk, and Complete gives you real visibility without polluting the sales pipeline. Without it, you end up with onboarding managers updating Deal Stage to track project health, finance pulling its hair out because "Closed Won" doesn't mean what they think it means, and a CEO dashboard that lies cheerfully to everyone who looks at it.
Distinct owners or permissions
If a dataset needs to be owned or segmented differently, that's another case. Think about:
- Partner programs
- Distributor agreements
- Assets you install and maintain over years
HubSpot's own docs hint at this split: properties extend what's stored on a record, while custom objects introduce new record types with their own properties and associations. If you want to go deeper on the underlying APIs, HubSpot's Properties API and Custom objects API guide are the place to start.
Designing your data model before you click create
Before you create anything, sketch the model. This is the step most teams skip, then regret six months later when they're untangling reports.
For a mid-market RevOps team, this can be a one-hour working session, not a six-week data strategy project. The bar is:
- Whiteboard your core objects: Contacts, Companies, Deals, Tickets, and any obvious candidates like Locations, Assets, Projects
- List the properties that matter: For each object, the 10–20 properties you actually use to make decisions. Ignore vanity fields.
- Draw associations: Which objects must be related? Which are optional? Where do you need many-to-many?
Then sanity-check these questions:
- Could any of these "new objects" just be properties on an existing object without breaking reporting?
- Are you creating an object just to store config or reference data that could live in a dropdown instead?
- Do you know which teams will own and maintain this data the hard way, not the ideal way?
When you move from sketch to build, keep HubSpot's limits and behavior in mind by cross-referencing their custom object how-to: Create custom object records. That will keep you honest on things like how many custom objects your subscription supports and how they show up in the UI.
Don't start with "what's possible." Start with "what needs to be reliably reportable for the next three years," and work backward.
Start with your own portal
Before you talk to anyone — us included — audit what you've already got. Walk through your portal honestly and ask:
- Where are you hiding rows inside a cell? Comma-separated lists in a "Notes" field.
Contract 2andContract 3properties created in a panic. Long text fields where someone is heroically maintaining structured data by hand, like a monk copying manuscripts. - Which reports are you not running because the data won't support them? MRR by location, renewals by product line, installs by region — if those questions can't be answered, the model is the reason.
- Which handoffs break because the model can't represent what your business actually does? Sales-to-onboarding, onboarding-to-service, service-to-renewal — friction at the handoff is usually a schema problem wearing a process costume.
If, after that audit, you've got a clear list of problems but aren't sure which ones warrant a new object versus a property cleanup, that's the right moment to bring in a second set of eyes. That's the work our team does week in and week out: Data Architecture & Analytics. The conversation is a lot more useful when you arrive with your own diagnosis in hand.
