HubSpot App Objects vs Custom Objects: What's the Difference and Why Did CommercePro Change?

HubSpot App Objects and Custom Objects both extend HubSpot beyond its standard CRM data structure, but they are built for different jobs. Custom Objects are created and owned by the customer to enable them customise the data model to align with their business requirements. App Objects are created and owned by an installed application to provide the data structure that application needs to work inside HubSpot.

That difference is central to CommercePro 2.0.

Earlier versions of CommercePro relied on an architecture that required a HubSpot Enterprise license for its Custom Object feature. CommercePro 2.0 now uses HubSpot App Objects to bring its commerce data model into HubSpot as part of the application itself. Customers no longer need Enterprise simply because CommercePro needs structured commerce records beyond Contacts, Companies, Deals and Tickets.

The change is bigger than a different HubSpot subscription requirement. It changes who owns the commerce architecture. Instead of requiring the customer's HubSpot environment to provide the structures CommercePro needs, CommercePro can now provide and maintain those structures itself.

That is one of the reasons CommercePro 2.0 can now run on HubSpot Content Hub Professional, and why understanding the difference between App Objects and Custom Objects matters.

Why did CommercePro previously need HubSpot Enterprise?

eCommerce doesn't fit neatly into HubSpot's standard CRM objects.

Contacts and Companies tell you who the customer is. Deals are useful for managing opportunities. But once somebody buys online, a commerce platform needs to represent a different set of information: what was ordered, the commercial terms around it, the status of the transaction and the ongoing relationship between that transaction and the customer.

Depending on the implementation, that can include records for things such as:

• Orders and their associated transaction data
• Subscriptions and recurring transactions
• Commerce-specific customer information
• Records that need to associate back to Contacts, Companies and other HubSpot data

Earlier versions of CommercePro relied on HubSpot architecture that made Content Hub Enterprise part of the minimum platform requirement.

For businesses already running Enterprise, that was rarely much of a consideration. For a business running Professional, however, it could materially change the CommercePro business case. Even if nothing else in the organisation required Enterprise, the CommercePro implementation did.

CommercePro 2.0 changes that architecture.

HubSpot has expanded what approved applications can do inside its platform, including through App Objects. CommercePro 2.0 has been rebuilt to take advantage of those capabilities.

What are HubSpot App Objects?

A HubSpot App Object is a structured record type introduced into HubSpot by an installed application as part of that application's own data model.

Instead of asking every customer to create and maintain the structures an application needs, the application can define those structures itself. Once approved as part of the HubSpot app, those records can become part of how the application operates within the customer's HubSpot environment.

The important distinction is ownership: the application owns the schema; the customer uses the records.

For CommercePro, that matters because commerce requires its own structured data. CommercePro can define the application-specific records it needs and bring that structure into HubSpot as part of CommercePro itself.

Those records can then exist alongside the customer's wider CRM data and associate with relevant HubSpot records without every CommercePro customer having to independently recreate the application's data model.

That is fundamentally different from a Custom Object.

What is a HubSpot Custom Object?

A HubSpot Custom Object is a record type created within a customer's own CRM to represent something their business needs to track that HubSpot does not provide as a standard object.

Imagine a construction business that sells work around projects. A Deal might represent the commercial opportunity, but the Project itself can have a much longer life and relationships with multiple Companies, Contacts and other records. Projects are part of how that business operates, regardless of which applications it happens to use.

The same principle can apply to:

• Properties or Sites for property businesses managing physical locations or assets.
• Policies or Accounts for financial services businesses with relationships that do not fit standard HubSpot records.
• Installed Assets for manufacturers that need to know which equipment sits with which customer.
• Projects for construction, engineering and other project-based businesses.

In those situations, the business needs the record. It isn't there because a particular application requires it.

The customer, usually with their HubSpot implementation partner, defines the object, its properties, its associations and how it fits into workflows, reporting and the rest of the CRM architecture.

That is why the simplest distinction between the two is also the most useful:

Custom Objects model the customer's business. App Objects provide structured data required by an application.

HubSpot App Objects vs Custom Objects: what's actually different?

From the user's perspective, App Objects and Custom Objects can initially appear quite similar. Both allow HubSpot to hold structured records beyond its standard object model.

Architecturally, however, they solve different problems.

That last distinction is particularly important in understanding the CommercePro 2.0 change.

It does not mean App Objects are a way for Professional customers to get Custom Objects without paying for Enterprise. They are not interchangeable.

An App Object exists because an application requires that record to provide its functionality. The application controls the schema. The customer cannot simply use CommercePro's App Objects to create arbitrary new record types for unrelated parts of their business.

They are different tools for different layers of the HubSpot architecture.

Why does CommercePro 2.0 use App Objects?

Because CommercePro should be responsible for the data model CommercePro needs to work.

An order is part of the commerce application. The customer needs access to the information and needs that information connected to the rest of their CRM, but they shouldn't have to design the underlying application architecture themselves.

Earlier approaches created a heavier dependency on the customer's HubSpot architecture and subscription.

With CommercePro 2.0, the commerce-specific data model can be delivered as part of the application. CommercePro defines the relevant App Objects, maintains their structure and can evolve that architecture as the product develops.

For customers, that creates several practical advantages:

• The commerce data model is delivered with CommercePro rather than having to be recreated for every implementation.
• The structure can remain consistent across CommercePro installations.
• CommercePro can maintain and evolve its application architecture without requiring every customer to independently manage the underlying schema.
• Commerce data can remain connected to the wider HubSpot customer record.
• The customer does not need Enterprise simply to provide Custom Objects for CommercePro's application architecture.

It is a cleaner separation of responsibilities.

The customer's HubSpot architecture models the customer's business. CommercePro's architecture models CommercePro.

Why did moving to App Objects change the HubSpot Enterprise requirement?

This is where a fairly technical platform change becomes commercially important.

Previously, the way CommercePro delivered parts of its experience meant Content Hub Enterprise was part of the baseline requirements. If you were on Professional and wanted CommercePro, moving to Enterprise could therefore become part of the implementation.

CommercePro 2.0 has changed the underlying architecture.

By using App Objects for application-specific commerce records, CommercePro can provide more of the structure it needs as part of the application rather than depending on Enterprise-level customer architecture.

As a result, CommercePro 2.0 now runs on HubSpot Content Hub Professional.

That doesn't mean every CommercePro customer should be on Professional. It means CommercePro itself no longer forces Enterprise into the decision.

A business that needs Enterprise for other reasons should absolutely still use it. A business that doesn't should no longer have to take on that subscription simply because it wants to run CommercePro.

That is a much more important distinction than "CommercePro got cheaper." The HubSpot subscription can now be determined by what the business actually needs from HubSpot, rather than by a technical dependency created by CommercePro.

Do HubSpot App Objects require Enterprise?

Customers do not need to create Enterprise Custom Objects in order to use App Objects delivered as part of an approved HubSpot application.

That is different from a business deciding it wants to create its own Custom Object.

If you decide your organisation needs a Projects object because Projects are fundamental to your operating model, that is part of your own HubSpot architecture. The relevant HubSpot Custom Object requirements apply.

If CommercePro needs a structured record because that record is fundamental to CommercePro's functionality, CommercePro can define and manage that structure through its approved application architecture.

The distinction is not "Enterprise objects versus Professional objects."

It is customer-owned architecture versus application-owned architecture.

That is also why App Objects should not be viewed as a licensing workaround. They exist so applications can own the data structures required to deliver their products properly inside HubSpot.

When would a CommercePro customer still need Custom Objects?

Potentially, quite often.

CommercePro moving to App Objects does not mean Custom Objects have become unnecessary. It means CommercePro no longer needs the customer to use Custom Objects simply to provide CommercePro's application-specific data model.

A manufacturer using CommercePro, for example, might still need an Installed Assets Custom Object because knowing which machines are operating at each customer site is fundamental to how that business works.

A construction supplier might use a Projects Custom Object because customers, contractors, consultants, quotes and orders all need to relate back to a specific project.

Those objects would still make sense even if CommercePro disappeared tomorrow.

That's a useful test when thinking about which model belongs where:

If you removed every third-party application from HubSpot tomorrow, would the business still need this record type?

If yes, it probably belongs in the customer's own CRM architecture.

If the record only exists because a particular application requires it to deliver its functionality, it is more naturally part of the application's architecture.

Do App Objects replace Custom Objects?

No. And CommercePro 2.0 is a useful example of why HubSpot needs both.

A well-architected HubSpot environment can contain three different layers of structured CRM data:

• Standard Objects, such as Contacts, Companies, Deals and Tickets, provided by HubSpot.
• Custom Objects, created to represent records specific to the customer's operating model.
• App Objects, introduced by applications that need their own structured records to deliver their functionality.

Those layers can work alongside each other.

A CommercePro customer could have a Contact representing the buyer, a Company representing their organisation, a customer-defined Project object representing the project they are purchasing for, and CommercePro App Objects representing relevant commerce activity.

Each record exists for a different reason.

The goal isn't to choose one object model and force everything into it. The goal is to put ownership of each part of the data model in the right place.

What does this change mean for businesses considering CommercePro?

If you looked at CommercePro previously and saw HubSpot Content Hub Enterprise listed as a requirement, that information was correct.

CommercePro 2.0 has changed.

The product has been rebuilt around newer HubSpot platform capabilities, including App Objects, allowing CommercePro to take greater ownership of the commerce data model its application requires.

That means businesses no longer need Content Hub Enterprise simply because CommercePro needs structured commerce records inside HubSpot.

CommercePro 2.0 now runs on HubSpot Content Hub Professional.

If your business needs Enterprise for Custom Objects, advanced HubSpot functionality or other parts of your architecture, that decision doesn't change. But if CommercePro was the reason Enterprise entered the conversation, it no longer has to be.

The difference between App Objects and Custom Objects explains why.

Frequently Asked Questions

What is the difference between HubSpot App Objects and Custom Objects?

The primary difference is ownership. Custom Objects are created and owned by the customer to represent records their business needs to track. App Objects are defined and delivered by an installed HubSpot application to provide structured records that application needs to function.

Why did CommercePro change to App Objects?

CommercePro 2.0 uses App Objects so CommercePro can own and maintain the commerce-specific data structures its application requires rather than requiring each customer to provide that architecture themselves. This creates a more consistent application architecture and is one of the changes that allows CommercePro 2.0 to now run on Content Hub Professional.

Does CommercePro 2.0 require HubSpot Enterprise?

No. CommercePro 2.0 runs on HubSpot Content Hub Professional. A business may still need Enterprise because of other HubSpot functionality or its own CRM architecture, but CommercePro itself no longer makes Enterprise a baseline requirement.

Did CommercePro previously require HubSpot Enterprise?

Yes. Earlier versions of CommercePro required HubSpot Content Hub Enterprise. If you previously researched CommercePro and saw Enterprise listed as a requirement, that information was correct at the time. The underlying architecture and requirements have changed with CommercePro 2.0.

Do HubSpot App Objects require Enterprise?

App Objects delivered as part of an approved HubSpot application do not require customers to create those records as their own Enterprise Custom Objects. The exact HubSpot subscription requirements still depend on the application and the customer's wider HubSpot environment.

Are App Objects a replacement for HubSpot Custom Objects?

No. Custom Objects and App Objects solve different problems. Custom Objects model records belonging to the customer's business, while App Objects provide structured records required by an application. A HubSpot environment can use both.

When should a business use a Custom Object?

A Custom Object is appropriate when the record represents something fundamental to how the business operates and should remain part of its CRM regardless of which applications are installed. Projects, Properties, Policies and Installed Assets are common examples.