HubSpot custom objects.
Model the thing your business actually sells. A property, a loan, a shipment, a vehicle, a clinical programme. When the thing at the centre of your business is not a contact, a company or a deal, forcing it into one of those is what makes the CRM feel wrong.
The deal record is standing in for a property.
One property has two deals against it, three contacts, and a history that outlives both. Modelled as a deal it loses that history the moment the first transaction closes, and the second buyer starts from nothing.
The deal closes. The asset does not.
Objects — the wrong shapeGetting the model right before building it.
Deciding whether it is an object at all
Most candidates are properties, a pipeline, or an association. Custom objects are permanent complexity and a tier requirement, so each one has to earn its place.
Association design
How the object relates to contacts, companies and deals, with labelled association types. This is what makes it usable in reporting rather than a data island.
Lifecycle on the object
If the thing has states it moves between, that needs modelling as deliberately as a deal pipeline, including who owns it in each state.
Record pages people can use
Custom cards, the right properties in the right order, and associated records visible. A well-modelled object with a badly laid out record page still does not get used.
Reporting across objects
Custom object data in reports alongside deals and companies, which is usually the actual business case for creating one.
Loading and keeping it current
Initial import plus the ongoing sync from wherever the data really lives, because most custom objects mirror a system of record elsewhere.
Audit, architect, build, hand over.
Audit
The portal read end to end — objects, properties, automation, permissions, integrations and the reports leadership actually opens.
Architect
The model written down before it is built: objects, lifecycle, ownership and the definitions every report has to agree on.
Build
Configuration, automation and integration built to that model, in a sequence that leaves the team working throughout.
Hand over
Documentation, enablement for the people who run it daily, and a period operating alongside your team until it is genuinely theirs.
An object for every noun.
Enterprise portals accumulate custom objects because creating one is easy and saying no is a conversation. Each adds permanent complexity to reporting, permissions and every integration afterwards. Three well-designed objects beat nine convenient ones, every time.
What people ask before they commit.
Do we need custom objects or will properties do?
Properties if it is a fact about an existing record. An object if it has its own lifecycle, its own associations and more than one relationship to other records. We work through it with you before anything is created.
Which tier do we need?
Custom objects require Enterprise on the relevant hub, with the exact allowance depending on the hub and tier. We check what you have before designing to it.
Can custom objects appear in reports?
Yes, in the custom report builder alongside standard objects. That capability is normally the reason to build one rather than keep the data elsewhere.
What are the limits?
There are caps on object count, property count and association types, and they matter at design time. We work within them rather than discovering them at build.
How long does it take?
Two to six weeks per object including modelling, build, import and the record page. Modelling takes longer than building and is worth every hour.
Where people go from here.
Model it once, properly.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.