Every growing HubSpot portal eventually hits the same wall. The business tracks something real (a property, a course, a subscription, a shipment, a project) and none of the four standard objects fit it. So it gets crammed into a deal, or scattered across eleven custom properties on the company record, or it lives in a spreadsheet nobody in HubSpot can see.
Custom objects are HubSpot's answer to that. They let you define a new record type with its own fields, its own records, and its own relationships to everything else in the CRM. This guide covers what they actually are, which plans include them, how to create one, the limits worth knowing before you commit, and the specific cases where a custom object is the expensive answer to a cheap problem.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What are HubSpot custom objects?
HubSpot ships with four standard CRM objects: contacts, companies, deals, and tickets. A custom object is a fifth, sixth, or seventh record type that you define, and once defined it behaves like a native part of the CRM rather than a bolt-on.
Its own properties
You define the fields. A Subscription object might carry term length, MRR, renewal date, and plan tier, all typed and filterable the same way contact properties are.
Its own records
Each row is a real CRM record with an ID, an owner, a timeline, and a record page. Reps can open one, log activity on it, and see its history.
Associations to standard objects
A custom object record links to companies, contacts, deals, or tickets, with labelled association types. This is what makes it a data model rather than a table.
Full automation and reporting
Custom objects can be enrolled in workflows, used as list criteria, and pulled into custom reports. That parity is the real argument for building one.
Which HubSpot plans include custom objects
This is the first thing to check and the most common place custom object plans die. Custom objects are Enterprise only, with no partial access on lower tiers.
| Plan | Custom objects |
|---|---|
| Free HubSpot CRM | No |
| Any Starter tier | No |
| Any Professional tier | No |
| Sales Hub Enterprise | Yes |
| Marketing Hub Enterprise | Yes |
| Service Hub Enterprise | Yes |
| Content Hub Enterprise | Yes |
| Data Hub Enterprise | Yes |
The gate applies to everything downstream, not just the create button. A Professional portal cannot create a custom object, cannot receive one from an integration, and cannot build the lists, workflows, or reports that would sit on top of one. There is no half-enabled state to design around.
Custom object or custom property? The test that settles it
Most of the time the honest answer is that you do not need a custom object. The decision comes down to cardinality, which is a formal way of asking "how many of these can one record have?"
Contract end date, plan tier, headcount band, onboarding status. One field on the company or deal, filterable and reportable, available on every plan including free.
A renewal is usually just another deal in a renewal pipeline. A support escalation is a ticket. Reusing a standard object costs nothing and inherits all the reporting you already built.
Twelve subscriptions per company, each with its own term. Forty properties per agent. Every course a student enrolled in. This is the one-to-many case nothing else handles.
If you can answer the question with one field on a record you already have, you do not have an object. You have a property, and properties are free.
What teams actually build as custom objects
The feature is generic, so the examples that stick are the ones where the business's core noun genuinely is not in HubSpot's model.
Real estate: Property or Listing
A single agent works dozens of listings, each with an address, price, status, and its own set of interested contacts. The textbook case.
Education: Course or Enrolment
A student contact enrolls in many courses over time, and each enrolment has its own start date, cohort, and completion state.
SaaS: Subscription or License
One company can hold several subscriptions on different terms. Modeling them as deals loses the renewal history the moment a deal closes.
Services: Project or Engagement
An agency runs several projects per client, each with a scope, budget, and delivery owner. This is the case where a lot of teams discover the work is already documented somewhere else.
Logistics and manufacturing: Shipment, Order, or Asset
Physical things with serial numbers, dates, and statuses that need to be associated with a company and reported on in aggregate.
How to create a custom object in HubSpot
Building one takes about half an hour. Deciding what it should contain takes considerably longer, and that is the part worth slowing down on.
- 1
Confirm the portal is on Enterprise
Check the subscription before anything else. Everything below is unavailable on Professional and there is no workaround inside HubSpot.
- 2
Open Data Management, then Data Model
In settings, find Data Management and open Data Model. Portals that have not been through HubSpot's more recent settings reshuffle will show this as Objects, then Custom Objects. Both land on the same editor.
- 3
Name it in singular and plural, then set the display property
HubSpot asks for both forms because it uses them across the UI. The primary display property is the field that titles every record, so choose something unique and readable. Record IDs make for a terrible record list.
- 4
Add only the properties you will use
Create the fields you will filter, report, or automate on, and stop. Every property you add is a field somebody has to populate forever, and a half-empty object is one nobody trusts. Prefer dropdowns over free text wherever the answer is a known set.
- 5
Define associations, then create and load records
Choose which standard objects each record links to and label the associations, then create the object. Populate it by import for a one-off migration, or through the custom objects API when a system of record owns the data.
Limits and gotchas worth knowing before you build
None of these are dealbreakers on their own, but each one has caught teams out after the object was already in production.
Check these before you commit to a data model
- Definitions are capped. Enterprise portals get a limited number of custom objects (commonly cited as ten), plus limits on properties per object and total records. HubSpot publishes the exact figures for your subscription in its Products and Services catalog, not in the feature docs.
- You cannot promote a property to an object later. If you model something as custom properties and later need one-to-many, that is a migration, not a setting change.
- Integration-created objects count too. Some marketplace apps define their own custom objects in your portal, which eats into the same cap.
- Custom object records surface as an associated-records card, usually in the record sidebar, not in the main column. Where exactly depends on how record customization is set up for that object.
- Every record needs an owner in practice, even though HubSpot does not force one. Objects without a clear person responsible for keeping them current go stale within a quarter.
- The object is only as good as its loading process. A custom object that depends on someone manually creating records after a call is a data-entry task with extra steps.
Where custom objects are the wrong answer
Custom objects are excellent at one shape of problem: structured, repeating, reportable entities that belong inside the CRM. They are a poor fit for everything else, and the mismatch is expensive because it comes with an Enterprise bill attached.
What custom objects do well
- Model genuine one-to-many relationships
- Full parity with standard objects in lists, workflows, and reports
- Real record pages with timelines and owners
- Association labels that describe the relationship
- API access for systems of record
Where they run out
- Enterprise tiers only, with no partial access
- Structured fields only, never documents or written context
- Capped number of definitions per portal
- Cannot be converted from existing properties
- Records have to be created and maintained by someone
- Duplicate the data if its real home is another tool
The second line of that list is the one that catches services teams. A lot of what people want on a HubSpot record is not a set of fields at all. It is a written thing: the account plan, the scoping doc, the project status page, the onboarding checklist, the client's actual requirements. That material is long, formatted, edited by more than one person, and linked to other pages.
A custom object can tell you that a project exists, its status, and its budget. It cannot show you the project.
For a lot of teams, especially the agencies and consultancies who hit this wall first, that written material already lives in Notion. Building a Project custom object in HubSpot then means keeping two versions of the same project: the real one in Notion that people write in, and the HubSpot shell that has to be updated to match. That is the same duplication trap described in the hidden cost of copy-pasting notes, just with a data model on top of it.
Custom object vs a live Notion card
These solve genuinely different problems, and the split is cleaner than it first looks. It comes down to whether you need to report on the data or read it.
If the question is "how many active subscriptions renew in Q4" or "which agents have listings over 500k", you need the data inside HubSpot as structured records. Nothing else answers that. Requires Enterprise.
Cheapest option by a distance, available on every plan, and enough for most of what teams initially reach for custom objects to solve.
NoteLinker puts a card on the HubSpot record that renders your Notion database rows live. The project stays where it is written and edited, and it shows up on the matching record. No Enterprise tier, no data model, and no second copy to keep current.
Plenty of portals end up doing two of these at once, and that is the right outcome. Model the things you genuinely report on as objects or properties. Leave the documents where they get written, and bring them onto the record instead of rebuilding them as fields.
Putting your Notion records on the HubSpot record
If the reason you started reading about custom objects was "the thing our business runs on is not visible in HubSpot", and that thing is written up in a Notion database, a custom object is solving a harder version of your problem than the one you have.
- 1
Install NoteLinker from the HubSpot Marketplace
Find NoteLinker in the HubSpot App Marketplace and install it. Standard OAuth, no developer build, and it works on every HubSpot tier including free.
- 2
Connect Notion and choose your databases
Authenticate with Notion and grant access to the databases holding your projects, accounts, or client records. Everything else in the workspace stays private.
- 3
Name the match properties
Tell NoteLinker which Notion property holds the contact email and which holds the deal name. That is how the card knows which rows belong on which record.
- 4
Open any contact or deal
The card renders the matching Notion rows inline, with the columns your view already shows. Rows are visible by default, so there is no sync step and nothing to press.
The full walkthrough lives on the setup page, and if you want to see the result before installing, here is Notion inside a HubSpot record.
Get your Notion databases onto every HubSpot record
NoteLinker renders your live Notion rows on the matching contact and deal, so the projects and accounts your team actually maintains show up in the CRM. No Enterprise tier and no data model to build.
Custom objects are one of the better things HubSpot ships, and when your business genuinely runs on a noun the CRM does not have, building one properly is worth the effort. Just be honest about which problem you are buying a fix for. If you need to report on records in aggregate, model them. If you need people to see context they already wrote somewhere else, show them the thing itself. See how the two surfaces fit together in our guide to the Notion HubSpot integration.
