Custom objects extend HubSpot's data model with first-class entities beyond Contacts, Companies, Deals, Tickets, Products. Use them when your business has a recurring entity that doesn't fit those five (subscriptions, contracts, properties, vehicles, students, projects), when you need to track multiple instances of something per contact, or when you're modeling a real many-to-many. Don't use them as a reflex when migrating from Salesforce. Most Salesforce customizations don't earn a custom object in HubSpot. Start with native data model, add custom objects only when you hit a real wall.
The decision framework
Three questions, in order. The first "yes" is the answer.
Question 1. Can the entity be modeled as a custom property on Contact/Company/Deal? If yes, do that. A property holds the data, automations can reference it, reports can group by it, no custom object needed.
Question 2. Does each Contact/Company have multiple instances of this thing? If yes, you need a custom object. A property is a single value per record. If a contact has 5 subscriptions, 12 properties, 3 vehicles, you can't flatten that into properties on the contact.
Question 3. Does the entity have its own lifecycle, automations, or reporting needs? If yes, custom object. Subscriptions have their own state machine (active, past_due, canceled). Properties (real estate) have their own listing-to-close cycle. Custom objects are first-class so they can have their own pipelines, automations, and reports.
Common patterns we ship
Subscriptions (SaaS). One Contact has multiple Subscriptions over time. Subscription has plan, MRR, status, billing anchor, churn date. Synced from Stripe via webhooks. Powers MRR rollups and churn workflows.
Properties (Real Estate). Each property is a custom object with address, status (listed, under contract, closed), price, square footage, photos. Associated to the Deal (transaction) and Contact (buyer or seller).
Vehicles (Automotive). Customer has multiple vehicles. Vehicle has VIN, make, model, year, service history. Drives service reminders, recall workflows, and lifetime customer value reporting.
Locations (Multi-Site Services). Healthcare networks, restaurant chains, franchises. Company has multiple Locations. Location has its own properties (address, hours, manager) and engagement history.
Contracts (B2B Services). Distinct from Deals. A Deal is the sales motion; a Contract is the active legal/billing agreement. Different lifecycle (renewals, amendments, terminations), different automations, different reporting.
Schema design, the part that matters most
Once you've decided to add a custom object, the schema is the long-lived decision. Get this right, the rest of the implementation is fast. Get it wrong, and every report, automation, and integration pays a tax forever.
Naming. Singular noun, lowercase, plain English. "Subscription" not "Customer Subscriptions Table". Plural is auto-generated.
Primary display property. The label HubSpot uses everywhere. Should be human-readable and unique enough to disambiguate. For Subscription: customer name + plan name (e.g., "Acme Corp - Pro Annual").
Required properties at creation. Keep this minimal: 3 to 5 fields max. The rest get filled in over time. Required-on-creation that aren't actually known yet causes import failures and integration headaches.
Associations. Default to associating with Contact AND Company AND Deal. You may not need all three immediately, but enabling them upfront is cheaper than adding later when you have 100K records. Use association labels to clarify (e.g., a Subscription is "Active for" one Contact and "Billed to" another).
Pipelines. If the custom object has a state machine (subscription status, contract status, property listing status), define stages explicitly with exit criteria. This makes reporting and automation dramatically cleaner.
The Salesforce migration trap
Customers migrating from Salesforce often have 30+ custom objects. The reflex is to recreate them all in HubSpot. Wrong move every time. Reasons:
- · Salesforce's data model is more permissive, so customizations accumulate without strategic intent. Half the Salesforce custom objects don't actually do load-bearing work.
- · HubSpot caps custom objects at 10. You have to choose.
- · HubSpot's native objects (especially Companies + Contacts + Deals + Products) are richer than Salesforce's standard objects, so many Salesforce customizations are unnecessary in HubSpot.
- · Each custom object adds maintenance overhead: reports, automations, integrations, training.
The audit step in week one of every Salesforce-to-HubSpot migration is custom-object triage. We typically migrate 3 to 6 of the 30+, sunset the rest.
Limitations you should know
Salesforce sync caps at 5. Native HubSpot Salesforce connector handles 5 custom objects. Beyond that, custom integration required.
Reports get expensive. Custom-object reports with deep joins are computationally heavier than Contact/Company/Deal reports. They don't refresh as fast on dashboards. Plan for snapshot reporting, not live dashboards, for high-volume custom objects.
Workflow triggers are slower. Custom object workflow triggers run with a small delay (1 to 5 minutes typically). For real-time triggers, use webhooks.
Mobile app limited. Custom object support in the HubSpot mobile app is improving but lags behind native objects. If field reps live on mobile, test heavily before relying on a custom object as a daily driver.
A regional healthcare network had 4 separate Salesforce orgs across acquired practices. We consolidated to one HubSpot instance with a Location custom object (12 sites). Patient referrals route based on Location proximity, not zip code. Referral conversion rate improved 31% in the first quarter, driven by faster routing and better visibility into Location-level capacity.
FAQ
What is a HubSpot custom object?
A new top-level data type beyond Contacts, Companies, Deals, Tickets, and Products. You define the schema (properties, relationships, allowed values) and HubSpot treats it like a first-class object: searchable, reportable, automation-eligible, syncable. Available on HubSpot Enterprise tier and above.
When should I add a custom object?
Three real cases. (1) You have a recurring entity that doesn't fit Contact/Company/Deal/Ticket: subscriptions, contracts, locations, vehicles, properties, students, projects. (2) You need to track multiple instances of something per contact (e.g., a contact has 5 separate purchases, each with its own attributes). (3) You're modeling a many-to-many relationship that custom properties on Contact can't capture (a buying committee where 4 contacts share an opportunity, but the opportunity has its own state).
When should I NOT use a custom object?
If you can model it as a custom property on an existing object, do that. Custom objects add complexity to reports, automations, and integrations. They cost more in implementation time and ongoing maintenance. Reserve them for cases where the alternative is meaningfully worse.
How many custom objects can I have?
HubSpot Enterprise allows up to 10 custom objects per portal. Most customers we work with use 2 to 5. Going past 7 usually means the model is over-decomposed; we revisit and consolidate.
Do custom objects sync to Salesforce?
Yes, but only 5 of them via the native HubSpot Salesforce connector. If you have 6+ custom objects that need bidirectional Salesforce sync, you need either a custom integration via webhooks/middleware OR you accept that the long-tail custom objects stay HubSpot-only. We map this in the audit before any code gets written.
Can I report on custom objects?
Yes, in Custom Report Builder. Reports can join custom objects to Contacts, Companies, Deals via association labels. The limitation: dashboards have a 25-report cap, and complex custom-object reports are computationally expensive, so they don't refresh in real-time. Plan for snapshot reporting, not live dashboards, for high-volume custom objects.
What's the most common pitfall?
Over-modeling. Teams that come from Salesforce often want to recreate every Salesforce custom object 1:1 in HubSpot. Wrong move. HubSpot's data model is more opinionated and most Salesforce customizations don't make sense. Start with what HubSpot gives you, only add custom objects when you've hit a real limit.
How long does this take to implement?
Single custom object with 5-10 properties, basic relationships, no integrations: 1 week. Custom object with complex automations, Salesforce sync, multi-system integration: 3 to 4 weeks. The schema design is the slow part; building and testing is fast.
How INSIDEA works
