Custom objects are the most requested and least necessary feature in HubSpot. Someone reads that HubSpot can model anything, opens a spreadsheet of properties, and asks for a custom object called Projects, Subscriptions or Vehicles. Sometimes that is exactly right. More often the same need is met by a property group, a second pipeline, or an association you already have.
The reason to be careful is that custom objects are close to permanent. They require an Enterprise tier, they change how every report and workflow is built, and unwinding one after six months of data means migrating records nobody wants to touch.
This is the test we run in HubSpot CRM setup and automation engagements before creating anything: four questions, then the cheapest structure that answers them honestly.
What HubSpot already gives you
HubSpot ships with standard objects — contacts, companies, deals, tickets, products, line items, quotes and marketing events — and they are more flexible than people assume. Each takes custom properties, custom pipelines and stages, and associations with labels describing the relationship.
Deals in particular are underused as a model. A deal is any record that moves through stages, has an owner and a value, and closes: a renewal, an onboarding project, an application, a booking. If your 'thing' has a lifecycle and a value, a second deal pipeline usually beats a new object.
Tickets model repeatable work with a queue and status. Support requests, change requests, content jobs and onboarding tasks all fit tickets with a custom pipeline — free of the tier requirement and instantly compatible with existing reporting.
The four-question test
One: is it genuinely a separate record with its own lifecycle, or an attribute of something that exists? Contract renewal date is a property on a company. A contract with its own value, stages, owner and documents is a record.
Two: does one parent need many of them at once? A company with fifteen active subscriptions, each with its own term and value, cannot be flattened into properties. If a single field would need repeating — subscription_1_start, subscription_2_start — you have found a real object need.
Three: do you need to report on them independently? If the question is 'average subscription value by product line, regardless of deal', properties buried on a contact will not answer it.
Four: is a deal or ticket pipeline truly a bad fit? Be honest here. This question kills roughly half the custom object requests we receive, and every one it kills saves the client an Enterprise upgrade and months of rebuild work.
| What you're modelling | Use | Why |
|---|---|---|
| Contract renewal date | Property on company | One value per parent, no lifecycle |
| A renewal that closes | Second deal pipeline | Stages, owner, value, close date |
| Support or change requests | Tickets with custom pipeline | Queue, status, no tier upgrade |
| Many subscriptions per account | Custom object | One-to-many with independent reporting |
| Physical assets or vehicles | Custom object | Own lifecycle, own associations |
| Event attendance | Marketing events / properties | Already modelled natively |
| Products and pricing | Products & line items | Built in, quote-compatible |
What custom objects cost you beyond the licence
The tier requirement is the obvious cost: custom objects need Enterprise, which is a serious jump if the only reason to upgrade is one object. Our tier comparison covers what each level actually unlocks.
The quieter costs are operational. Custom object records are not contacts, so marketing email cannot be sent to them directly, some list and segmentation behaviour differs, and reporting on them requires custom report building rather than the out-of-the-box dashboards your team already knows.
Integrations are the third cost. Many third-party tools sync contacts, companies and deals, and stop there. Before committing, check that every connected system in your stack can read and write your object — the integrations that quietly break your CRM covers what happens when they cannot.
When a custom object is clearly the right answer
Subscriptions, policies and contracts where one account holds many concurrent agreements, each with its own dates, value and status, and finance needs to report on them separately from sales activity.
Physical inventory: properties, vehicles, machines, units. Each has a lifecycle independent of any deal, gets associated with multiple contacts over time, and carries attributes nobody wants stuffed into a deal record.
Courses, cohorts, applications and memberships in education or association models, where the record persists across many enrolments and needs its own reporting. In every one of these cases, the giveaway is the same: many per parent, own lifecycle, own reporting.
Build it properly if you build it
Name the object and its properties for the business, not the database, and decide the singular and plural labels before creating it — they surface everywhere in the UI. Define the primary display property carefully; it is what appears in every association card and search result.
Set up association labels deliberately. 'Company — primary account holder' and 'Company — billing entity' are different relationships, and getting labels right at the start is what makes later reporting possible without rework.
Then document it: an owner for the object, a written definition of every property, required fields enforced, and a rule for who may create records. Undocumented objects rot the same way undocumented workflows do — and the CRM data cleanup guide explains what that costs later.
The pragmatic path we recommend
Model the need with standard objects first. A second deal pipeline or a ticket pipeline plus a handful of properties can be live in a day, at no extra licence cost, and it will tell you within a quarter whether the structure holds.
If you hit real limits — repeating property groups, reports you cannot build, records you cannot associate — you will hit them with evidence, and the upgrade conversation becomes a business case instead of a hunch.
That order also protects your reporting. Every portal we clean up has at least one abandoned structure someone built before they understood the requirement. Building the cheap version first means the expensive version, if you ever need it, gets built once and correctly.