HubSpot custom objects: when you actually need one
You need a HubSpot custom object when the thing you are tracking has many instances per company, its own lifecycle, and properties that do not belong on a contact or deal. If there is only ever one per record, a property is the right answer and a custom object will make reporting harder.
By HubReven
Custom objects are available on Enterprise, and most of the requests we see for them should be something cheaper.
Here is the test, and what to do when the answer is no.
The three questions
1. Can there be many of them per company?
A subscription, a vehicle, a property, a course enrolment, a shipment. Companies have several, each with its own attributes and dates.
If there is only ever one per company or per contact, it is a property. "Account tier" is a property. "Contract renewal date" is a property. Making them objects buys you nothing and costs you every report.
2. Does it have its own lifecycle?
Does it get created, change state, and end, independently of the deal that produced it? A subscription is active, then paused, then cancelled, on its own timeline. A shipment is booked, in transit, delivered.
If its state is just the deal's state wearing a different name, it is the deal.
3. Does it need its own properties and its own history?
Twenty fields that only make sense for this thing, and a timeline of what happened to it. If the answer is two fields, it is two properties.
Three yeses means a custom object. Two or fewer means one of the alternatives below.
What to use instead
A property when there is one value per record. The cheapest option and the easiest to report on.
A multi select property when there are a few values from a fixed list. "Products owned" with eight options is a property, not eight objects.
A line item when it is something sold on a deal with quantity and price. Line items already exist, already roll up to deal amount, and already report. Rebuilding them as a custom object is a classic expensive mistake.
A second pipeline when it is a process with stages that is not your sales process. Onboarding, renewals and support escalations are usually pipelines on the deal or ticket object rather than new objects.
A separate record with an association when it genuinely is a different kind of thing, which is the case a custom object exists for.
What it actually costs you
Custom objects are not free once created.
Reporting gets harder. Cross object reports are more limited than reports within one object. If leadership needs a number that spans your custom object and deals, check that the report you need is possible before you commit.
Workflows get more complex. Automation across objects means association based triggers and copying values between records, which is where the timing bugs live.
Everything needs building. Views, dashboards, permissions, forms and imports that exist for standard objects have to be created for yours.
Integrations get more expensive. Most marketplace apps sync standard objects only. A custom object usually means a custom integration rather than an app you install.
If you do build one
Four decisions worth making before creation, because some are hard to change later.
The primary display property. What shows in lists and search. A subscription showing as a UUID is unusable. Use something human readable.
A unique external ID. If this object comes from another system, create a unique property for that system's ID immediately. It is what every future sync will key on, and retrofitting it after records exist is painful.
The associations. Which standard objects it links to, and whether the relationship is one to many or many to many. Get this wrong and you rebuild.
Which properties are required. Fewer than you think. Required fields that the source system cannot supply will block every import.
The honest recommendation
Start without one.
Model the thing as properties and associations, live with it for a quarter, and see what you cannot do. If the limitation is real, you will be able to describe it precisely, and building the object then is straightforward.
Portals get unmaintainable through accumulated good intentions, not through one bad decision. The same discipline applies to properties, stages and dashboards: build what the data supports, not what the plan imagines.
Frequently asked questions
Do I need HubSpot Enterprise for custom objects?
Yes, custom objects require an Enterprise tier. If you are on Professional, the alternatives are properties, multi select properties, line items and additional pipelines, which cover most cases.
What is the difference between a custom object and a custom property?
A property is one value on an existing record. A custom object is a new record type with its own properties, its own timeline and its own associations. If there is only ever one value per company or contact, you want a property.
Can I convert properties into a custom object later?
There is no automatic conversion. You create the object and migrate the data, which is a straightforward migration if you planned a unique external ID and a messy one if you did not.
Will marketplace integrations sync my custom object?
Usually not. Most apps sync standard objects only, so a custom object typically requires a custom integration through a private app.
Get the next one