Build a custom object when the "thing" you're tracking has its own lifecycle, needs to associate with more than one deal, contact, or company over time, and needs to be reported on independently. If it only ever describes one existing record, it's a property, not an object.
In This Article
What a custom object actually is
A custom object is a record type you define yourself, with its own properties, its own pipeline if it needs one, and associations to standard objects like Contacts, Companies, and Deals. Think of it as HubSpot letting you say "this business also revolves around X," where X isn't a person, a company, or a sales opportunity.
When a custom object is the right call
- The "thing" has its own lifecycle independent of a deal, it gets created, updated, and closed out on its own timeline
- Multiple deals, contacts, or companies need to associate with the same record over time
- The business needs to report on it as its own category, not as a property tucked inside a deal
A real example: tracking physical assets
One pattern that comes up often in industries dealing with physical inventory, vehicles, vessels, equipment, real estate, is that the asset itself needs to exist as a record independent of any single deal. A boat, for instance, doesn't stop existing when a deal closes. It might come back through the pipeline years later with a different buyer, a different broker, or a different listing.
In cases like this, a custom object representing the asset, with its own identifying properties (serial numbers, registration IDs, specifications) and associations to every deal, contact, and company that's ever touched it, gives the business a full history that a deal-only data model simply can't capture.
Matching logic like reconciling incoming records by a unique identifier first, then falling back to a secondary one, keeps duplicate asset records from piling up as the same item moves through multiple systems and multiple transactions over time.
If you find yourself wanting to attach the same "thing" to more than one deal, or you keep re-creating the same entity because there's nowhere for it to live between transactions, that's usually a custom object waiting to happen.
When to leave it as a property instead
Not everything that feels like "its own thing" needs to be a custom object. A custom object earns its place when it has its own lifecycle, needs to associate with more than one record over time, and needs independent reporting. If it only ever describes one existing Contact, Company, or Deal, and never needs to stand on its own in a report, it belongs as a property on that record instead.
The most common mistake isn't creating a custom object, it's creating one before mapping out the associations and reporting it needs to support. A custom object with no clear association strategy tends to accumulate duplicate, orphaned, or inconsistent records fast.
Map out every association the object will need, every report it should feed, and who owns keeping its data clean. Objects built with that groundwork in place tend to stay reliable for years. Objects built without it tend to become the thing a future technical audit has to untangle.