Do You Need HubSpot Enterprise for Custom Objects?

Custom objects require Enterprise, and almost everyone assumes that means Enterprise on the hub where the work is happening. It does not. HubSpot's entitlement is account wide, so one qualifying Enterprise subscription anywhere on the portal unlocks custom objects everywhere on the portal.

That single fact changes the shape of a lot of upgrade conversations. A client running Sales Hub Professional and Marketing Hub Professional who needs a custom object for a marketing use case does not have to buy Marketing Hub Enterprise. They need one Enterprise subscription, and they get to pick which one based on what else they want from it.

We say this to partners more or less weekly, usually while someone is halfway through building a quote for the wrong upgrade.

What HubSpot actually requires

HubSpot's documentation lists custom objects as available with any of the following:

• Marketing Hub Enterprise
• Sales Hub Enterprise
• Service Hub Enterprise
• Data Hub Enterprise
• Content Hub Enterprise
• Smart CRM Enterprise
• Revenue Hub Enterprise

The wording is "with any of the following subscriptions." Not "in." The custom object lives in the CRM, which every hub shares, so the object is available to every tool on the portal once one qualifying subscription exists. A workflow built on the Marketing Professional side can enrol, filter and act on a custom object created because the client happens to own Sales Hub Enterprise.

Two caveats worth stating up front, because they are the ones that come back as scope questions later. Custom object pipelines also require Enterprise, and the number of custom objects and properties you can create varies by subscription, with HubSpot deferring the specific limits to its products and services catalogue rather than publishing them in the knowledge base. Check the current catalogue before you promise a client a specific number of objects.

What the one upgrade actually unlocks

Custom objects get the headline, but they are rarely the most valuable thing in the box. The same Enterprise entitlement brings:

Custom associations. The ability to define your own relationships between object types, including labelled associations and many-to-many relationships. On most builds we do, this is the part that actually solves the problem. The client thinks they need a new object; what they need is a relationship the standard model does not express.

The data model builder. A visual view of how your objects relate, which is where you create custom objects and manage associations. It is also the single best artefact to put in front of a client who is about to approve a data architecture, because it makes the design arguable before it is built.

Custom object pipelines. Stages, and therefore progression reporting, on your own object type.

Sandbox and finer permissioning. Not custom object features, but they arrive with the same tier, and for an agency delivering under its own brand they matter. A sandbox is the difference between testing a data model change and discovering it on a live portal.

If you are scoping an Enterprise upgrade for a client, the honest pitch is the data model as a whole, not the custom object on its own.

What Professional actually ceilings out at

The Professional tier limits that come up most often in our delivery work:

Capability	Professional	Enterprise
Custom objects	Not available	Available
Custom associations	Not available	Available
Sandbox environment	Not available	Available
Permissions granularity	Coarse	Field and record level controls
Workflow scale and complexity	Lower limits	Higher limits

Professional is a genuinely capable tier and most portals never outgrow it. The trigger for the conversation is not sophistication, it is shape: when the client's business has a thing in it that is not a contact, a company, a deal or a ticket, and that thing has a life of its own.

Three questions before you quote an upgrade

Most custom object requests that reach us do not need a custom object. Before we scope one, we run the request through three questions.

Does the thing have its own lifecycle? A property changes state on a record. An object has states of its own. A vehicle that goes from Available to Reserved to Sold to Serviced is an object. A "preferred contact method" is a property, no matter how strongly the client feels about it.

Does it need a many-to-many relationship? One contact to many deals is already supported. Many students to many courses, many properties to many bidders, many assets to many maintenance events: that is where the standard model runs out and either a custom object or a custom association becomes the answer.

Does it need its own record page? Will a human open this thing, look at its history, and work from it? If yes, it wants a record. If it only ever appears as a field on somebody else's record, it is a property.

Three yeses means it is genuinely an object. Two or fewer, and there is usually a cheaper build.

The alternatives to try first

Custom properties on an existing object. Unglamorous and frequently correct. If the extra data is genuinely one-to-one with a contact, company or deal, it is a property, and it costs nothing.

A second pipeline. Deals and tickets both support multiple pipelines with their own stages. A surprising number of "we need a custom object for our renewals process" requests are a renewals pipeline on the deal object.

A standard object used as a join layer. When you need to model a many-to-many relationship on Professional, an existing object can sometimes carry the join, with one record per relationship rather than one per entity. It is a compromise, the labels will read oddly, and you should document why you did it. But we have shipped it more than once to avoid an upgrade the client genuinely could not fund at that moment, and it held.

An external system with an API integration. If the data belongs to a system of record that is not HubSpot, the answer may be to leave it there and surface it through an integration rather than duplicating it into the CRM. Our white-label HubSpot API integration work is very often this conversation: not "can we model this in HubSpot" but "should we."

A worked example: when the standard model genuinely runs out

The clearest case we see is any business where one deal has several competing participants.

Take a client running a tender or bidding process. One opportunity, several bidding companies, each with its own submission, its own status, and its own documents. The instinct is to put a "bid status" dropdown on the company record and move on.

That fails for two specific reasons, and they are worth naming because they generalise well beyond bidding:

The status becomes shared when it should not be. A company bidding on three different opportunities has one company record and therefore one bid status. The moment your second deal exists, the field is wrong for at least one of them. Any status that describes a relationship rather than an entity has this problem, and putting it on either entity is the wrong answer.

The progress interface does not come with it. HubSpot's progress bar at the top of a record is driven by lifecycle stage and by deal pipelines. A custom dropdown property does not get one, so the client who asked for "a visual pipeline for bids" does not get the thing they were picturing, and finds that out at the demo.

The correct shape is a join layer: one record per bidder-per-opportunity, holding the status, the documents and the dates, associated to both the company and the deal. On Enterprise that is a custom object with custom associations. On Professional you are choosing between an existing standard object pressed into service as the join, or leaving the data outside HubSpot.

That test, does this attribute describe an entity or a relationship, resolves more custom object questions than any other single check we apply.

What happens after you create the object

Creating a custom object takes a few minutes. Quoting it that way is how projects go wrong, so it is worth itemising what the actual engagement contains.

Property design. Every property you create is one you will have to maintain, report on and explain. Portals routinely accumulate hundreds of custom properties with almost no fill rate, and a brand new object is an opportunity to not do that again. Design the minimum set that supports the reporting the client says they want.

Association design and labelling. Which objects does this connect to, in which direction, one-to-many or many-to-many, and what is each relationship called on the record page. Labelled associations are the difference between a data model a user can read and one they cannot.

Migrating the existing data in. The client's records currently live somewhere: a spreadsheet, a legacy system, or a set of custom properties on the contact object that you are now replacing. Extracting, shaping and importing that data, with the associations intact, is normally the largest single line on the quote. HubSpot imports create or update records; they do not append to associations, so repeated parent rows in an import file overwrite rather than accumulate, and the file has to be shaped accordingly.

Rebuilding the reporting. Existing dashboards read the old model. Every report that touched the data you just moved needs rebuilding against the new object.

Permissions and views. Who sees the object, what the default views are, and what the record page layout looks like for each team.

Training and documentation. A custom object is a new noun in the client's business vocabulary inside their CRM. If nobody explains it, adoption fails quietly and you get blamed for the build.

None of that is exotic, but all of it is billable, and none of it appears in a request that reads "we need a custom object for equipment."

How we scope this for agency partners

The pattern we see across the agencies we deliver for is that the custom object question arrives as a technical request and is really a commercial one. The client has asked for something, the agency does not have the platform depth in house to know whether it needs an upgrade, and the agency is reluctant to go back to the client with "we'll find out."

The sequence that works:

1. Look in the portal before answering. Which subscriptions exist today, at which tier, and is an Enterprise subscription already sitting there unused? We have found existing Enterprise entitlements on portals where the team had been budgeting for an upgrade.
2. Model the thing on paper first, using the three questions above. Fifteen minutes here changes the quote more than anything else you do.
3. Price the cheapest qualifying hub, not the hub the use case appears to live in.
4. Quote the data model work separately from the object. Creating a custom object takes minutes. Designing the associations, migrating the existing data into it, rebuilding the reporting on top of it and retraining the users is the actual project.

That last point is where quotes go wrong most often. The object is not the work.

The bottom line

You need Enterprise for custom objects, but you need it once, on one hub, and the entitlement covers the whole portal. Before you quote that upgrade, check whether the request is really an object at all: most are properties, pipelines or associations wearing an object's clothes.

If your team is fielding data model questions across a portfolio of client portals and would rather have a senior HubSpotter answer them than guess, that is exactly what our white-label agency services exist for, and the custom objects primer is a reasonable place to send a client who wants to understand the concept before the call.