How to decide when HubSpot custom objects are worth the overhead for your data model.
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.
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 answers questions like:
A custom object can exist on its own, be associated with other records, and have its own properties and lifecycle.
Examples include:
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?
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:
The places where you truly need a new object are almost always about repeating structure, distinct lifecycles, or distinct owners.
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:
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.
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.
If a dataset needs to be owned or segmented differently, that's another case. Think about:
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.
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:
Then sanity-check these questions:
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.
Before you talk to anyone — us included — audit what you've already got. Walk through your portal honestly and ask:
Contract 2 and Contract 3 properties created in a panic. Long text fields where someone is heroically maintaining structured data by hand, like a monk copying manuscripts.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.