Yes, custom objects require HubSpot Enterprise, but you almost certainly do not need to put every seat on Enterprise to get them. One qualifying Enterprise subscription anywhere on the portal unlocks custom objects across the whole portal, which is the part most pricing conversations get wrong and the reason a lot of teams talk themselves out of a build they could afford.
That is the licensing answer. The harder question is whether you should build one at all, because most of the teams who ask us about custom objects need three properties and a workflow instead.
Updated September 2026. Rewritten to lead with the licensing and cost question this page actually ranks for, with four stale facts from the previous version corrected against current sources: the Pro-to-Enterprise cost, the association cap, Zapier's custom object support, and the no-code build path. Several unsourced figures and client specifics from the previous version have been removed.
The short version
| Question | The 2026 answer |
|---|---|
| Which tier do I need? | Enterprise. Custom objects are not available on Free, Starter or Professional. |
| Do all my hubs need to be Enterprise? | No. One qualifying Enterprise subscription on the portal unlocks custom objects portal-wide. |
| What does the upgrade cost? | Depends entirely on which hub you upgrade. Sales Hub Enterprise is commonly listed around $150 per seat per month against roughly $90 for Professional, plus a larger one-time onboarding fee. Hub-level Enterprise plans are priced very differently from each other, so price the specific hub rather than trusting a blended number. |
| Can I build one without an engineer? | Yes for most cases. The data model builder in settings creates objects, properties and associations with no code. Engineering is for external sync and historical migration. |
| Should I build one? | Only if the entity has its own lifecycle, you need many per parent, and you need to report on it as its own thing. Two out of three means a property. |
Which HubSpot tier do you need for custom objects
Custom objects sit behind Enterprise. They are not in Free, Starter or Professional, and as of 2026 that has not changed despite being one of the most requested moves down-tier. Guides covering the current state, including Meticulosity and daeda, all report the same gate.
The detail that matters commercially is what counts as qualifying. The requirement is an Enterprise subscription on at least one hub, not Enterprise everywhere. Marketing Hub, Sales Hub, Service Hub, Content Hub, Data Hub and Smart CRM Enterprise are all reported as qualifying, and a single one of them lights up custom objects and custom associations for the entire portal, whichever hub your team actually works in.
That changes the shape of the decision. The question is not "can we move the whole company to Enterprise." It is "which single hub is cheapest for us to take to Enterprise, and does that hub's Enterprise tier earn its keep on its own merits." Those are very different conversations, and the second one is usually winnable.
Price the cheapest qualifying hub, not the hub your reps live in.
Custom objects unlock portal-wide from one Enterprise subscription. If the hub you would naturally upgrade is the expensive one, check whether a different hub gets you the same unlock for less, then judge that hub's Enterprise features on their own.
What the upgrade actually costs
This section used to carry a figure of roughly $1,200 per seat per month for the Pro-to-Enterprise jump. That number was wrong and it has been removed.
Current published pricing for Sales Hub puts Professional at roughly $90 per seat per month on annual billing and Enterprise at roughly $150, a difference closer to $60 per seat per month, with a larger required onboarding fee on the Enterprise side. Those figures come from 2026 pricing write-ups including Docket, ResonateHQ and EngageBay, and HubSpot's own Sales Hub pricing guide.
Three caveats, because this is exactly where confident blog numbers do damage.
First, hub-level Enterprise prices differ by an order of magnitude. Marketing Hub Enterprise is quoted in thousands per month while Sales Hub Enterprise is quoted per seat. Figures in the four-digit monthly range circulate widely and get repeated as if they were per-seat costs, which is how a $60 per seat decision turns into a $1,200 per seat myth. Read the unit on every number you are quoted, including ours.
Second, list price is not your price. Seat counts, annual commitment, existing contract terms and the onboarding fee all move it. Treat every published figure, including the ones above, as the starting point for a quote rather than the quote. If you want the fuller picture of how HubSpot bills in practice, we keep a separate breakdown of what B2B teams actually pay for HubSpot.
Third, and this is the one people skip: if the only reason to upgrade is custom objects, check whether the entity you want to model is genuinely an object. Most of the time it is not, and you have just saved the upgrade entirely.
What a custom object actually is
HubSpot ships with five standard objects: contacts, companies, deals, tickets and products. A custom object is a sixth, seventh, eighth record type that you define. It has its own properties, its own associations to other objects, its own permissions, and its own row in workflows and reports.
A subscription is a custom object. A shipment is a custom object. A loan application, a vehicle in your fleet, an event registration, a partnership agreement, a property listing. Anything that has its own lifecycle, its own owner, and its own attributes that do not belong on a contact or a deal.
A property, by contrast, is a single field on a record that already exists. One company, one renewal date. The difference is not about importance. It is about cardinality and lifecycle.
The three-part test: when you actually need one
Here is the test we run before any build. A custom object is the right call when three things are true at once.
First, the entity has its own lifecycle. A subscription starts, gets paid, renews, churns. A shipment is created, picked, packed, shipped, delivered. A loan application is submitted, reviewed, approved or denied, funded. If the entity just sits there with one or two fixed values, it is a property.
Second, you need many of them per parent. A company can have many subscriptions. A contact can have many event registrations. If the cardinality is one-to-one with a company or a deal, it is a property.
Third, you need to report on it as its own thing. You want a list of all active subscriptions across all customers. You want a dashboard of every shipment delayed past SLA. You want a workflow that fires when an application moves to approved. Reporting and workflows on the entity itself, not on the parent record.
If all three are true, build the custom object. If only two are true, a custom property on the parent object almost always wins, and it wins without an Enterprise upgrade.
The five patterns we see most often
Across B2B SaaS, B2B services and account-based businesses, the same five shapes come up. If your model fits one of these, most of the design work is already decided.
1. Subscription
The most common one. The deal closes, the subscription begins. The deal is a one-time event. The subscription is the recurring relationship. You associate one company to many subscriptions. Each one carries plan tier, MRR, ARR, start date, term, auto-renew flag, renewal date, churn risk score and a status. Customer success owns it, finance reports on it, renewal workflows fire from it.
The recurring reporting failure in B2B SaaS portals is teams modelling subscriptions as deals. It works for the first year. In the second year the renewal opens, a rep clones the original deal, and closed-won pipeline now counts the same logo twice in different years. A subscription object removes the ambiguity: closed-won deals are acquisitions, subscriptions are the recurring revenue.
2. Project or engagement
For agencies, professional services and any business that sells deliverables rather than seats. A project has a scope, a start date, an end date, a project manager, a status and a budget. It associates to the company and the deal that originated it. Time tracked, milestones, deliverables and invoices all hang off the project.
This is the pattern that replaces a Notion or Asana sidecar for delivery work, and the value is less about the object than about the handoff workflow that fills it at closed-won.
3. Asset or unit
Common in equipment leasing, healthcare devices, vehicle fleets and physical product businesses. Each unit has a serial number, a model, a warranty status, an install date and a service history. The asset is owned by a company, or a contact for B2C. Service tickets associate to the asset rather than the contact.
This is the case where the object pays back fastest, because the alternative is a properties graveyard where someone tracks "serial number 1", "serial number 2" and "serial number 3" as separate fields. That breaks the moment a customer has four units.
4. Application or request
Banks, lenders, insurance, education, anywhere there is a structured intake with its own approval lifecycle. The application has a status, an assignee, a decision date, a reason code and attachments. The same contact can submit several applications over time, each its own record with its own workflow.
This is where custom objects start replacing tickets. Tickets are built for support work: short cycles, single resolution, queue routing. Applications often need richer state machines, multi-week review windows and structured decision fields. In 2026 the case got stronger, because custom objects can now carry stage calculated properties that track how long a record has sat in each pipeline stage, the same way they already worked for deals and tickets.
5. Partner agreement or referral
For partner-led growth. A partner is a company in your CRM. The partner agreement is the formal contract: tier, commission percentage, effective date, expiry, exclusivity terms. Deals associate to partner agreements, and commission calculations run off the agreement rather than the company record.
The reason to split the agreement from the company is renewals and tier changes. A partner can move from Silver to Gold mid-year, and historical commission on deals closed under Silver should still calculate at the Silver rate. An object preserves the snapshot, a property on the company overwrites it. The object is only worth building once the program behind it is real, so if you are still deciding, start with when a B2B SaaS company should build a channel partner program, which covers the deal registration object this pairs with.
If the entity has its own lifecycle, its own owner and its own report, it is a custom object. If it does not, it is a property.
We talk teams out of custom objects more often than into them. Start with properties, prove the gap, then add the object. The upgrade is easier to justify once you can show the report that properties cannot produce.
When a property does the job
Before you build, pressure-test against the cheaper option. Most "we need a custom object" conversations should end with a custom property and a workflow.
A single renewal date on the company. A churn risk score on the deal. An industry tag on the company. A primary contact role. A campaign source on the contact. All properties. None of them need an object, and none of them need Enterprise.
The signal is one-to-one. One company, one renewal date. One contact, one campaign source. The moment you catch yourself thinking "we need three of these per record", stop and reconsider. Three of anything per record is where a property starts to break. Five is where you have lost.
The other question worth asking before you build: what report do you actually want off this object. A surprising number of requests dissolve at that question, because the answer turns out to be something HubSpot's existing objects already produce. Meetings are the classic one. A team that wants to count meetings per account this quarter does not need a meetings object. They need a saved view on the engagement data HubSpot already stores.
The build sequence that does not break
Most custom object builds that go wrong six months in went wrong in the sequence. The right order looks like this.
The freeze matters more than people expect. Once an object is live and wired into workflows, every property rename, association change and required-field flip risks breaking a downstream report or sequence. A 30-day freeze gives the team time to use the object, find the real gaps, and propose changes as one batch instead of a constant trickle. It is the same discipline that keeps a CRM migration from turning into a year of small corrections.
The five mistakes that wreck custom objects
Mistake one: skipping the model. Teams open the object builder and start adding properties from memory. Two weeks later the object needs to associate to both companies and deals, the deals association was never set up, and half the records are orphaned. Draw the diagram first, in the data model builder or anywhere else.
Mistake two: bad API names. Display names can change. Internal API names cannot. Ship a property called Status with the API name status, then later realise you needed subscription_status, and you cannot rename it without breaking every integration, workflow and report that references it. Prefix everything with the object name: subscription_status, subscription_mrr, subscription_renewal_date.
Mistake three: too many properties. The technical ceiling is high. The practical ceiling is much lower, somewhere around 40 fields, after which the record page becomes unreadable, users stop filling fields in, and reporting fragments because half the data is missing. If you are adding a 50th property, ask whether it belongs in a separate object or is a calculation on an existing one. This is a judgement from our own builds rather than a HubSpot limit, and it is worth treating as a smell rather than a rule.
Mistake four: designing around an association cap that no longer applies. This page previously said HubSpot caps associations at 500 per record. That was true once and is not the current picture. HubSpot has raised association limits substantially, and since July 2024 you can set custom association limits per object type or label through the associations API and in settings, configurable well beyond the old ceiling. The design question is still real, because a parent with tens of thousands of children is a rollup problem rather than an association problem, but "we will hit 500" is no longer the reason. Check the current limits for your object in the account usage screen before you design around a number you read in a blog post, this one included.
Mistake five: assuming no automation path exists. This page previously said custom objects were not supported by most Zapier triggers and actions. Zapier shipped custom object support in 2024 and now offers instant triggers for new custom objects and for property changes on them, plus create and update actions. The integration question is still worth asking, just with a different answer: check each tool in your stack rather than assuming the object is a dead end.
What changed in 2026, and what did not
Worth stating plainly, because most guides on this topic still describe 2022.
Changed: the no-code path is real. The data model builder in settings lets you create objects, define properties and manage associations visually, with association label counts visible per object pair. Stage calculated properties now exist for custom objects, so pipeline duration reporting works the way it does for deals. Association limits are configurable rather than fixed at a low ceiling. Zapier supports custom objects properly.
Did not change: the Enterprise gate, the one-qualifying-subscription rule, the fact that most teams asking for an object need a property, and the fact that a badly modelled object is harder to unwind than to build.
How custom objects fit your reporting stack
The payoff of a well-built custom object is not the object. It is the reporting that becomes possible.
Subscription objects give you MRR dashboards that reconcile with what finance sees in the billing system. Project objects give you utilization by project manager. Asset objects give you warranty expiry alerts and service revenue forecasts. Application objects give you funnel reporting on approval rates by stage, by reviewer, by source.
The trick is to design the properties with the report in mind. Want to report on monthly MRR change? Add a calculated property that holds it. Want to report on renewal risk? Add an enumeration with three values: healthy, watch, at risk. Decide the report first, then build the property that feeds it. The same principle applies to everything else you put on a dashboard, which we cover in how to stop looking at the wrong numbers in HubSpot.
One thing to settle before you build: who owns which half of the model. Custom objects and deal-side properties usually sit with RevOps, while lifecycle stages, the campaign object, UTM standards and the properties automation writes on a contact sit with marketing. When both sides edit the same properties without a boundary, you get two conventions inside one portal and reports that disagree with each other. It is worth reading what a marketing operations lead actually owns before you hand the portal to two teams, because the split is easier to agree in advance than to unpick after a quarter of parallel building.
Custom objects or an external system
A question we get from founders every month: should this live in HubSpot at all, or in a separate system?
The honest answer depends on who owns the workflow.
If sales and customer success own the workflow, HubSpot wins. The data sits alongside the contact, the company and the deal. Reps see it on the record. Workflows fire across object boundaries. Reporting lives in one place.
If finance or engineering owns the workflow, an external system usually wins. A billing platform handles invoices, dunning and tax. A product analytics tool handles event-level usage. Modelling invoices in HubSpot custom objects works for the first month, then breaks the moment accounting needs revenue recognition logic.
The clean pattern is a source-of-truth system holding the canonical record and HubSpot holding a derived, read-only object synced on a schedule for sales and CS visibility. Billing owns the subscription. HubSpot shows it. Nobody argues about whose number is right. This is the same architecture we describe in the CRM data enrichment guide: pick your source of truth, sync derivatives, never let two systems fight for the same field.
If the object is the reason you are considering moving CRM entirely, that is a different decision, and we cover the version of it that comes up most in HubSpot migration work.
The integration tax
Custom objects are not free downstream. Every integration you add later has to be checked for custom object support, and support is uneven rather than absent.
Zapier supports custom objects, including instant triggers on creation and property updates. Slack notifications work. Salesforce sync works with caveats around field mapping and bidirectional updates. Inbox sidebars in Outlook and Gmail generally do not surface custom objects. Many third-party HubSpot marketplace apps still handle standard objects only.
Before you build, list every integration the object needs to touch and check each one rather than assuming. Where a gap remains, an automation layer that talks to the HubSpot API directly closes it. We use n8n for that on client builds because it handles custom objects without complaint, and the same logic applies to any AI automation layer you run on top.
How we checked this page
We ran this guide against current sources in September 2026 and four of its factual claims had gone stale. The Pro-to-Enterprise cost was wrong by roughly an order of magnitude. The 500-association cap had been superseded. The claim that Zapier could not handle custom objects had been false since 2024. The no-code build path had improved enough that the advice to draw the model outside HubSpot was no longer the only option.
We are showing that rather than quietly fixing it, for two reasons. First, every one of those four claims is still repeated across guides that rank for this topic, so if you read three articles about HubSpot custom objects this week you probably read at least one of them. Second, this is the check we run on client portals too: not "is the configuration good" but "which of the things this team believes about their stack stopped being true and nobody noticed." Stale assumptions cost more than bad configuration, because nobody audits them.
Our own Search Console data on this page is part of the same honesty. This URL has held position 8.2 to 8.6 for fifty consecutive daily snapshots and earned two clicks in all of them, on 698 impressions in the 90 days to 10 September 2026. A page sitting on page one and earning nothing is not a ranking problem, it is an answer problem, which is why the licensing question now sits in the first line instead of in a mid-page paragraph.
Thinking about a custom object build?
If you are weighing whether to add a custom object or stick with properties, we can do the analysis in an hour. Book a free 30-minute audit and we will tell you which way the math goes, including whether the Enterprise upgrade is avoidable.
Book an audit →FAQ
Do I need HubSpot Enterprise to use custom objects?
Yes. Custom objects are an Enterprise feature and are not available on Free, Starter or Professional. The important qualifier is that you need one qualifying Enterprise subscription on the portal, not Enterprise across every hub and every seat. A single Enterprise hub unlocks custom objects portal-wide, so the real question is which hub is cheapest for you to upgrade.
How much more does Enterprise cost than Professional?
It depends which hub. For Sales Hub, 2026 published pricing puts Professional around $90 per seat per month and Enterprise around $150 on annual billing, with a larger one-time onboarding fee on Enterprise. Other hubs are priced very differently, and some Enterprise plans are quoted as a monthly platform fee rather than per seat, which is where a lot of the confusion in published comparisons comes from. Price the specific hub you would upgrade, and treat list price as the start of a quote.
Can I create custom objects without an engineer?
Yes, for most cases. HubSpot's data model builder in settings handles object creation, properties and associations visually with no code, and shows your objects and their association labels as a diagram. Engineering gets involved when you need to sync data from an external system, build a custom integration against the HubSpot API, or migrate historical records. Plan for at least one developer-day if external sync is in scope.
What is the difference between a custom object and a custom property?
A property is a single field on an existing record. One contact, one phone number. A custom object is a separate record type with its own lifecycle, properties, associations and reports. One company can have many subscription records, each with its own term, MRR and renewal date. Use a property for one-to-one data and a custom object for one-to-many. If you are unsure, it is a property.
Does Zapier work with HubSpot custom objects?
Yes. Zapier added custom object support in 2024 and now offers instant triggers for newly created custom objects and for property changes on them, plus actions to create and update records. Older guides saying custom objects are unsupported in Zapier are out of date. Other tools in your stack may still be standard-objects-only, so check each one rather than generalising in either direction.
Can I delete a custom object after I build it?
Yes, with consequences. Deleting an object removes all records, properties and associations tied to it. Workflows referencing the object break. Reports built on it disappear. If you are unsure whether you need an object, build it in the sandbox portal and run it for two weeks before promoting to production.
If you want help thinking through a custom object build or your broader HubSpot data model, we run audits and implementations through our CRM and RevOps practice. The first conversation is free and usually saves teams a few thousand dollars worth of bad property decisions.
Sources
None of the primary sources below was directly reachable from the environment this page was written in. Figures and product behaviour are credited to the organisations that published them, and the linked pages are where to verify the current position. HubSpot's own knowledge base article on creating custom objects and pricing page are the authority on anything below that matters to a purchase decision.
- Enterprise requirement for custom objects, and the rule that one qualifying Enterprise subscription unlocks the portal, from Meticulosity, daeda and Bluleadz's custom objects guide
- Sales Hub Professional and Enterprise per-seat pricing and onboarding fees, from Docket's 2026 Sales Hub pricing research, ResonateHQ's 2026 pricing guide, EngageBay's August 2026 update and HubSpot's own Sales Hub pricing guide
- Association limits, the July 2024 custom association limits release and configurable per-object ceilings, from HubSpot's developer changelog, HubSpot's knowledge base on record association limits and Coefficient's write-up
- Record and usage limits per custom object, from HubSpot's CRM data limits article and HubSpot's limits tracking developer guide
- Zapier custom object triggers and actions, from Zapier's HubSpot getting-started documentation and HubSpot's Zapier integration article
- The data model builder and the no-code object creation path, from HubSpot's data model builder article and Vantage Point's guide to the HubSpot data model
- Stage calculated properties for custom objects, from HubSpot's developer changelog rollups
- Position, impression and click figures for this page are our own Google Search Console data for the 90 days to 10 September 2026