HubSpot Custom Objects: When to Use Them and How

Key takeaways

• Build a custom object only when you need to track many records per contact or company, each with its own fields, history and reporting. If it's one value, use a property.
• Design the associations before the fields. Labels, cardinality and who owns each record decide whether your reports work later.
• Custom objects need an Enterprise subscription and have account limits, so check your numbers before you design around five of them.

A customer success lead sends you a spreadsheet. It lists every product each account has installed, with renewal dates, seat counts and an owner for each one. Right now it lives in a tab nobody trusts, and the CRM only has a text field called “Products” that says “A, B, C”.

That’s the classic case for HubSpot custom objects. When one company has many of something and each one needs its own fields, history and reports, a property won’t hold it. Here’s how to decide, and how to build it so it doesn’t become a mess in a year.

What a custom object is

HubSpot ships with contacts, companies, deals and tickets. A custom object is a fifth, sixth or seventh record type that you define. You set the name, the properties, the associations to other objects and, if the records move through stages, a pipeline.

Think of it as a table in your data model. Each row is a record with its own owner, timeline and workflows. You can report on it and trigger automation from it, like any standard object.

One thing to know up front: HubSpot’s knowledge base says an Enterprise subscription is required to create custom objects, and your account has limits on how many you can create. Check yours under Data Management before you plan.

Custom object or property? A quick test

Most teams reach for a custom object too early. Run the request through this test first.

Question	If yes	If no
Can one company have many of these?	Lean custom object	Use a property
Does each one need its own fields?	Custom object	Property or a dropdown
Do you need history or an owner per item?	Custom object	Property
Will you report on them as a group?	Custom object	Property
Is it just a label or a status?	Property	n/a

If you answer yes to three or more, build the object. If it’s one value that changes over time, a property with history already does the job.

An illustration (not a client example): a company with a single “contract tier” gets a property. A company with six locations, each with its own address, headcount and manager, gets a Locations object.

Good use cases we see most

These are the patterns that earn a custom object:

• Subscriptions or licences, when an account holds several with different renewal dates.
• Locations or sites, for franchise, retail or multi-office customers.
• Assets or devices, where support needs to know what the customer actually owns.
• Projects or engagements, if delivery work doesn’t fit a deal or a ticket.
• Applications or enrolments, common in education and services.

Notice what’s missing: leads, “accounts we like” and anything that’s really a lifecycle stage. Those belong on the objects you already have.

Design the associations first

Fields are the easy part. The associations are where designs go wrong.

If you can’t write the reports first, you’re not ready to build. That one habit saves the most rework.

Design rules that keep it clean

Some rules we’d apply on any build:

1. Name the object in the singular. “Subscription”, not “Subscriptions”. The UI adds the plural.
2. Set a primary display property that humans can read, like “Acme - Pro plan”, not an ID.
3. Use dropdowns and required fields where reporting depends on the value. Free text breaks groupings.
4. Keep it lean. Start with 8 to 12 properties. You can add more; removing them later is painful.
5. Decide the unique key early if you’ll import or sync from another system, such as a billing tool.

Be careful with property sprawl. A custom object with 60 fields nobody fills in is just a second spreadsheet. Our CRM data hygiene checklist covers how to keep required fields honest.

Reporting and automation on custom objects

Once the object exists, the payoff is in what you can do with it. You can build reports across objects, such as renewals due in 60 days by account owner. You can also trigger workflows when a custom record changes, for instance creating a task for the account manager when a subscription is 90 days from renewal.

Keep the first automation simple. One workflow, one outcome, and a person who checks it weekly. If you’re thinking about AI on top, clean objects matter even more, because an agent only knows what your records say. Our CRM AI readiness checklist is a good test, and our post on HubSpot Breeze agents vs custom agents covers what to build once the data is ready.

Common mistakes

• Building before the reports are defined. You end up with fields no one uses.
• Using a custom object as a dumping ground for anything that doesn’t fit, instead of fixing the standard objects.
• Skipping association labels, then discovering you can’t tell the billing contact from the technical one.
• No owner for the data model. Five admins add five versions of the same field.
• Planning a migration without mapping the objects. If you’re moving CRMs, see our CRM migration checklist.

The bottom line

Use a custom object when the thing you’re tracking comes in many, with its own details, owner and reporting. Use a property when it’s one value. Design the associations and the reports first, keep the field list short, and check your plan limits before you commit.

If you’d like a second opinion on your data model, we’re happy to walk through it with you. Our HubSpot implementation services page shows how we approach it.

Sources

• HubSpot Knowledge Base, “Track your CRM data limits” (Enterprise requirement for custom objects, limits in Data Management): https://knowledge.hubspot.com/data-management/track-crm-data-limits