HubSpot ships with four standard objects — contacts, companies, deals, and tickets — but plenty of businesses track something those four don't fit. A custom object lets you model that thing — a subscription, a property, a shipment, a course — as its own record type, with its own properties and associations, so it lives in HubSpot as a first-class object instead of being crammed into a deal or a note. Creating the records is straightforward once the object exists; the real decision is whether you need a custom object at all. Here's the practitioner's read on doing it right.
When should you actually use a custom object?
Use one when you're tracking a distinct thing that the standard objects can't represent without distorting your data. Before you build, ask whether the data really needs its own object or whether a property, a custom property group, or an existing object would do. Custom objects shine when the thing has its own lifecycle, its own properties, and needs to associate to contacts, companies, or deals in a many-to-many way. They're overkill when you could just add a few fields to a deal. Worked example: a company that sells equipment and tracks each installed unit's warranty, location, and service history needs an "Asset" custom object — those units don't belong on a single deal, and forcing them there breaks reporting. But a company tracking one extra detail per deal should just add a property. The discipline is resisting the urge to build a custom object for everything.
How do you define the custom object before creating records?
Set up the object's name, properties, and associations first — records inherit whatever structure you define here. Custom objects are created in HubSpot's settings (it requires the right edition and permissions). You define the object's singular and plural name, a primary display property, the properties each record will hold, and which other objects it can associate to. Get this right before adding records, because the structure shapes everything downstream — reporting, automation, and how records connect. A custom object with vague properties produces vague reports. Worked example: defining the "Asset" object with properties for serial number, warranty end date, and linked company means every record you create afterward slots cleanly into reports and workflows; skipping that planning means retrofitting fields later across hundreds of records.
How do you create the records themselves?
Add them manually, import them in bulk, or create them through automation — the same three paths as any HubSpot object. Once the object is defined, you create records from its index page (the "Create" button), via a CSV import for bulk loads, or automatically through a workflow or the API. For a one-off, manual entry is fine. For migrating existing data, import on a unique identifier so you don't create duplicates and so associations form automatically — the same discipline as any HubSpot import. For ongoing creation tied to a trigger, automation or the API keeps it hands-off. Worked example: importing 500 existing assets from a spreadsheet, with a company-name or domain column included, lets HubSpot auto-associate each asset to its company in one pass — far cleaner than creating them one at a time and linking them by hand.
How do you keep custom object data clean and useful?
Associate records correctly, set required properties, and use the object in reporting from day one. A custom object is only worth the effort if the records connect to the rest of your data and feed real reports. Make sure every record associates to the right contacts, companies, or deals; set required properties so records can't be created half-empty; and build at least one report or list off the object early, which surfaces data-quality gaps fast. An unused, unassociated custom object is just clutter. This is exactly the order we follow with clients: confirm the object is truly needed, define it carefully, load it on clean keys, then put guardrails and reporting around it.
The IV-Lead take
The hard part of custom objects isn't creating records — it's the judgment call of whether to build the object at all, and the discipline of defining it well before any data goes in. A well-scoped custom object makes HubSpot fit your business; a hastily built one adds a layer of mess you'll have to clean up later. Decide it's genuinely needed, model it carefully, and associate every record — that's what turns a custom object from clutter into a reporting asset.
Not sure whether you need a custom object or just better use of the standard ones? Book a 30-minute portal audit — we'll tell you straight whether a custom object earns its place in your portal. For the bigger picture, see how we set up HubSpot to fit the business through HubSpot implementation and optimization.
Frequently asked questions
What HubSpot edition do I need for custom objects?
Custom objects are available on HubSpot's higher tiers (Enterprise editions of the Hubs), and creating them requires admin-level permissions. Check your subscription before planning, since the feature isn't in every edition.
What's the difference between a custom object and a custom property?
A custom property adds a field to an existing object; a custom object creates an entirely new record type with its own properties and associations. Use a property for one extra detail, and a custom object only when you're tracking a distinct thing with its own lifecycle.
Can I import records into a custom object?
Yes — you import them via CSV the same way as contacts or companies, matching on a unique identifier to avoid duplicates and including an association column so records link to the right companies or contacts automatically.
How many custom objects can I create?
HubSpot allows a limited number depending on your edition, so it's worth using them deliberately rather than spinning one up for every idea. Plan which distinct things truly warrant their own object before you start building.
