HubSpot custom objects vs associations is usually framed as a feature question: does your HubSpot tier include custom objects, yes or no. That framing misses the actual decision, because plenty of teams who can already afford Enterprise still build a custom object for something an association and a couple of custom properties would have handled for free. The real question is not what you can afford, it is what the thing you are tracking actually needs: its own identity, its own pipeline, or just a link to a record that already exists.
HubSpot Custom Objects vs Associations: The Actual Decision Rule
A custom object is justified when the thing you are tracking needs at least one of three things a plain association cannot give it: a record-level identity that several other objects need to reference independently, its own pipeline with stages a deal or ticket pipeline cannot represent, or properties and reports that do not belong to any existing object. An association plus custom properties on an existing object is the right choice, and the cheaper one, when what you actually want is to describe or link something that already has a home on a contact, company, deal, or ticket.
Most teams get this backwards because a custom object feels more “correct” for anything with its own name, like a location, a subscription, or a piece of equipment. HubSpot’s own object documentation frames custom objects as the tool for exactly that kind of standalone entity, using a roastery’s “Roast Batch” records as its own example, tracked as their own entity and then associated out to the contact who ordered one, the deal it was sold on, and any ticket raised about it. But naming something is not the same as it needing independent identity. A subscription that only ever belongs to one company and is only ever viewed from that company’s record is a property set on the company, or an association to a lightweight object at most, not automatically a reason to build a new object type.
HubSpot’s own custom objects documentation adds two questions worth asking before building, because moving something onto a custom object also moves it away from tooling that only works on standard objects: can the record still receive bulk marketing email, which only sends to contacts, and can it still use pre-built reports such as deal attribution and sales forecasting, which are wired to deals specifically. Losing either is a real, recurring cost of the custom-object route, not a footnote.
There is also a middle rung most write-ups on this decision skip entirely: HubSpot ships several ready-made objects, such as appointments, services, listings, and courses, that a Super Admin can switch on without building anything. A meaningful share of the custom objects teams end up building are really reinventions of one of these already-defined objects, so it is worth checking whether HubSpot has already built the object before designing a new one from scratch.
What an Association Actually Is, and Its Real Limits
HubSpot’s object documentation defines an association plainly: it is a relationship between two records that lets you “visualize the relationships and quickly access relevant data.” No Enterprise tier is required to associate a contact with a company, a deal, or a ticket, and every standard object already ships with the associations a normal sales or service process needs. An optional association label, a short descriptor on the relationship itself, does require a Professional or Enterprise subscription, but the association mechanic underneath it does not.
Associations do have real ceilings, and they are worth knowing before assuming a property-and-association approach scales indefinitely. Per HubSpot’s own product and services catalog, free accounts can create up to 10,000 associations per association type per record, such as 10,000 contacts on one company, while paying accounts can create up to 250,000. The exceptions worth knowing, which apply regardless of edition, include a maximum of 1,000 associated contacts, 1,000 companies, and 1,000 tickets per deal, a maximum of 1,000 associated records of any type per engagement such as an email, a maximum of 1,000 form submissions per contact, a maximum of 10,000 line items and 10,000 products per deal, a maximum of 10,000 deals per contact, and a maximum of 100 quotes per deal. One further limit does split by edition: a maximum of 100,000 associated deals per product record on a free account, rising to 1,000,000 on a paid one.
For the overwhelming majority of RevOps use cases, none of these numbers are the binding constraint. They only start to matter for a handful of unusually high-volume relationships, such as a single company record accumulating far more contacts than a normal account structure would produce.
A Super Admin on a Professional or Enterprise account can also configure a custom limit for a specific association type, per HubSpot’s own guidance on setting association limits, up to a maximum of 10,000. This exists to restrict associations for data hygiene reasons, such as stopping reps from bulk-associating hundreds of unrelated contacts to a single deal, not to raise the ceiling beyond what the account already has.
What a Custom Object Actually Requires
Custom objects are only available on the Enterprise edition of Marketing Hub, Sales Hub, Service Hub, Content Hub, Data Hub, Revenue Hub, or Smart CRM, created either through the Data Model interface or through the Custom Objects API, per HubSpot’s own custom objects documentation. Once defined, a custom object gets everything a standard object has: its own properties, its own pipelines if the process needs stages, and its own associations to contacts, companies, deals, tickets, or other custom objects.
The Enterprise-only pricing is the constraint most teams weigh first, but it is not the constraint that actually bites once an account already has access. HubSpot’s product catalog gives an object-definition allowance that varies by hub: 10 object definitions, 1,000,000 total records, and 50 pipelines on Marketing Hub, Sales Hub, Service Hub, and Content Hub Enterprise, rising to 20 object definitions, 1,500,000 records, and 100 pipelines on Data Hub and Revenue Hub Enterprise. A paid limit increase adds ten more object definitions and a million more records at a time for five hundred dollars a month, up to a stated account-wide maximum of fifty million custom object records.
Separate from any of that, and unaffected by budget, is a fixed structural ceiling: a custom object can hold a maximum of nine defined association types to other object types. That is not nine associated records, it is nine distinct kinds of relationship a single custom object type can ever have, at once, to contacts, companies, deals, tickets, or other custom objects combined.
That nine-association-type ceiling is the detail worth planning around before building a custom object rather than after. A “Roast Batch” object that only ever needs to associate out to contacts, deals, and tickets, as HubSpot’s own example does, has plenty of headroom. A custom object designed to sit at the centre of a much larger, still-growing process is the one to sketch out fully before building, for reasons the next section covers.
Where Teams Get This Wrong
The most common mistake is building a custom object for something that is really just a property. A “renewal type” or “contract tier” that only ever describes a single deal is a custom property on the deal, not a reason to build and maintain a separate object with its own permissions, its own reporting setup, and its own place in every integration that touches the account.
The second common mistake is the opposite: forcing a genuinely independent entity, one with its own identity that several deals or contacts need to reference over time, onto an existing object as a bloated set of properties. A piece of equipment that gets serviced under several different deals across several years needs its own record so the service history stays attached to the equipment rather than getting duplicated or lost every time it changes deals. Properties on a deal cannot represent that; an association to a proper record can.
The third common mistake is treating the nine-association-type ceiling as a future problem rather than a design constraint. A custom object built to be the connective tissue for an entire complex process, associated to contacts, companies, deals, tickets, and several other custom objects all at once, can run out of association types in a way that is expensive to redesign around later, since every workflow, report, and integration built against the original object has to move with it. Sketching out every relationship the object will realistically need, including ones planned for next year, before building it in the Data Model interface catches this while it is still free to fix.
The fourth common mistake is ignoring the cost gap entirely. Custom objects require an Enterprise edition of at least one HubSpot hub or Smart CRM, and a genuinely complex data model can also mean paying for the object-definition limit increase on top of that. An association and a handful of custom properties on an object the account already has cost nothing extra, and for the substantial share of use cases that never need independent identity or a dedicated pipeline, that is the entire decision in one line: cheaper, simpler, and available on the tier the team is already paying for.
Related Reading
For the strategy layer this kind of data-model decision sits inside, see RevOps Consultancy. For the CRM build work that puts objects and associations into practice, see HubSpot Consultancy. On keeping whatever data model results actually clean once it is live, Automated Pipeline Hygiene covers the wider practice.
Go deeper: HubSpot Lifecycle Management: Contacts vs Custom Objects · HubSpot Global Activity Associations
Frequently Asked Questions
Do I need HubSpot Enterprise to use associations between records?
No. Associations between standard objects such as contacts, companies, deals, and tickets are available on every HubSpot tier. Enterprise is only required to build a custom object, and Professional or Enterprise is required specifically for optional association labels, not for the underlying association mechanic itself.
What’s the actual limit on how many object types a custom object can associate to?
Per HubSpot’s own product catalog, a custom object can have a maximum of nine defined association types to other object types, combined across contacts, companies, deals, tickets, and other custom objects. That is a fixed structural ceiling on distinct relationship types, not on the number of associated records within any one of them.
Should I build a custom object or just add a property to an existing record?
Add a property if the thing you are tracking only ever describes or belongs to one existing record, such as a contract tier on a deal. Build a custom object only if it needs its own identity referenced by several records independently, its own pipeline with stages, or properties and reports no existing object can hold.
How many custom objects can a HubSpot Enterprise account create?
Ten object definitions on Marketing Hub, Sales Hub, Service Hub, or Content Hub Enterprise, rising to twenty on Data Hub or Revenue Hub Enterprise, per HubSpot’s own catalog. A paid limit increase adds ten more object definitions and a million more records at a time, up to a stated account-wide maximum of fifty million custom object records.