HubSpot Custom Objects: When to Build One, What Breaks, and Why the Exit Is One-Way

What a custom object actually is

A custom object is a record type you define yourself. It sits alongside the standard ones HubSpot ships with: contacts, companies, deals, and tickets. HubSpot's own examples are a pet-boarding business tracking "Pets", and a dealership tracking vehicle inventory. Both are a genuinely new thing the business needs to track, not a different flavour of contact or deal.

Custom objects are gated to Enterprise. As at August 2026, that gate applies account-wide, across every hub: Marketing, Sales, Service, Content, Data, and Revenue. Any one Enterprise subscription unlocks custom objects for the whole portal. The feature lives at the CRM level, not inside a single hub. Buy Sales Hub Enterprise for the forecasting tools, and you also get custom objects, whether or not you asked for them. Professional tier doesn't get custom objects at all. The closest things it gets instead are calculated properties and association labels. Both are genuinely useful. Neither is the same thing.

A property or a standard object might answer it first

HubSpot's own pre-build guidance sits in the "before you get started" section of its custom objects docs. It tells you to check three things before you create anything. Does the data overlap with an object you already have? Do you need a feature that only works on a standard object, such as bulk marketing email or deal forecasting? Does an existing report type already cover what you are trying to measure? Most of the custom objects that get built, and later regretted, would have failed at least one of those three checks.

The clearest sign you actually need a custom object is that the data does not fit anywhere else. It is not that the data is merely inconvenient where it currently sits. A dealership's vehicle inventory is not a variant of a deal or a contact. Neither is a pet-boarding business's list of pets. Both are a genuinely separate thing the business tracks, with their own lifecycle, independent of any one contact or deal. That is why HubSpot uses them as its own examples of a good fit.

HubSpot also warns against the opposite mistake: building a custom object to replace a standard one, instead of extending it. Its own example is treating a custom object as a stand-in for Contacts. That loses the automatic activity association contacts get for free: emails, calls, and meetings tied to the record without any extra setup. A custom property on an object you already have almost always solves the same problem, with none of that cost. It's worth ruling out before you reach for a new object type.

The real limits, as at August 2026

HubSpot publishes hard ceilings through its limits API. They are worth checking before you plan a build around one object doing everything. As at August 2026, HubSpot's limits API reports a cap of 20 custom object types per Enterprise account. That account can hold a combined limit of 1,500,000 records across every custom object type. Both numbers have moved before. Older sources cite 10 object types and 500,000 records, which suggests HubSpot has raised both ceilings at least once already. Treat today's figures as a snapshot, not a promise about what you will still have next year.

Inside each object, HubSpot allows up to 1,000 custom properties. Account-wide, across every object, standard and custom combined, the cap is 10,000 custom properties. Calculated properties are capped separately, at up to 200 account-wide. Association labels, the tags that describe how one record relates to another, are capped at 50 per object pair as at August 2026. That one has an older, lower ceiling behind it too, so treat it the same way: current, not fixed. Custom objects can also carry up to 100 pipelines account-wide, the same pipeline mechanism deals use.

None of these numbers is likely to bite a straightforward build. They matter most if you are planning to model something at real scale: tens of thousands of records syncing from an external system, dozens of association types. Confirm the object is the right shape for the data first.

What custom objects don't get that standard objects do

A custom object record looks and behaves like a normal HubSpot record, right up until you try to use it the way you use a contact or a deal. Several features that feel like they should work on any object are, in HubSpot's own docs, tied to one specific standard object and nothing else.

Bulk marketing email can only be sent to contacts. Not companies, not deals, not custom objects. If part of the reason you are considering a custom object is to run a campaign against it directly, that path does not exist. The relevant data has to be synced onto a contact first.

Deal attribution reports and sales forecasting are connected directly to deals, and nothing else. A custom object representing a piece of equipment or a project cannot generate its own forecast the way a deal can, even when it is the thing actually driving the revenue.

Attribution reporting more broadly is limited to three data sources: contacts, deals, and revenue. Custom objects are not a supported attribution source at all.

Score properties, HubSpot's native lead-scoring mechanism, are supported only on contacts, companies, and deals. There is no score property for a custom object, or for a ticket.

Custom objects also have no purpose-built report types of their own. Standard objects get dedicated report shapes: deal forecast reports, contact-create attribution, and so on. A custom object is limited to generic single-object reports and the custom report builder. The builder can combine a custom object with its associated records, but it doesn't come with any of the purpose-built report types deals and contacts get for free.

Two more gaps are worth naming, and qualifying, in the same breath. Both have shifted recently. Neither should be treated as a fixed ceiling. As at August 2026, HubSpot's own Agent for Copilot lists the objects it can read directly: contacts, companies, deals, tickets, and a long list of commerce objects. Custom objects are not on that list. On mobile, the picture has improved. Older community requests complained about not being able to edit custom object records in the HubSpot app. Current documentation describes full viewing, filtering, creating, and editing of custom object records on mobile, with no distinction drawn for custom objects specifically.

The unwind: deleting a custom object is one-way

Every decision above is reversible. This one is not, and it is worth reading slowly before you build anything you might later want to take apart.

HubSpot will not let you delete a custom object while anything still references it. Its own docs are direct about this: you cannot delete a custom object that is currently being used by other tools. You have to remove references to it from those tools first. In practice, that means manually finding and stripping every workflow that touches the object, and every calculated property built on top of it, one at a time. Only then will HubSpot let the delete button do anything.

Once you have cleared all of that and gone ahead, there is no undo. HubSpot's own words: you cannot restore a deleted custom object. That is a different rule from deleting individual records, which go to a recycling bin and stay restorable for 90 days if you delete them through the API. The object itself, the schema, the properties, the whole shape of the thing, gets one delete, with no recycling bin behind it.

Here is the part that matters most. It's also the part HubSpot does not cover at all: what happens to the reports, dashboards, permission sets, and third-party integrations built on top of the object, once it's gone. The docs describe the pre-deletion cleanup you must do: strip out workflows and calculated properties. They say nothing about what happens next. They don't say what happens to a report that used to chart that object's records, or to a dashboard tile that pulled from it. They don't say what happens to a permission set that scoped access to it, or to an integration that was syncing to it. That is a real gap in HubSpot's own documentation, so plan for it before you build, not after. Before you create a custom object, write down every report, dashboard, permission set, and integration you expect to touch it. You will be the one tracking that list down by hand, if the object ever needs to go.

There is also no documented path for converting a custom object's records into a standard object, or for merging two custom object types into one. If you get the shape wrong the first time, there is no correct-course option, only starting over. HubSpot doesn't publish a migration tool for this. That doesn't mean nobody has ever done it by hand, exporting and re-importing through the API. But there is nothing native built for the job, and nothing in the docs walks you through it.

How to decide

Run the checks in the order HubSpot itself suggests, then add one more of your own. Does the data overlap with an object you already have? Do you need a feature, bulk email, deal forecasting, lead scoring, that only works on a standard object? Does an existing report type already cover what you need to measure? If any of those point away from a new object, a custom property on contacts, companies, or deals is very likely the better answer. It costs you almost nothing to unwind later, if it turns out to be wrong.

If you have ruled all three out, and the data genuinely does not fit anywhere else, there is one last question. It's the one the docs never ask. Are you prepared to list, and eventually manually strip, every workflow, calculated property, report, dashboard, permission set, and integration that ends up depending on this object? That's the work waiting for you on the day you decide you were wrong about it. That list is real work whether or not you ever act on it, and HubSpot will not generate it for you. Custom objects are genuinely the right tool when the data is its own thing: a fleet of vehicles, a set of pets, a piece of equipment tracked across its own lifecycle. They are the wrong tool for anything that is really just a variant of a contact or a deal wearing a different label. That is exactly the kind of build you end up stripping back out again, by hand.

Related.

Common questions.