Standard objects (contacts, companies, deals, opportunities, cases) should carry your CRM data by default; custom objects are justified only when a thing has its own lifecycle, its own relationships, and its own reporting needs that no standard object can express. This decision matters because every custom object is a long-term commitment: it changes your data model, your integrations, your reporting, and every future admin's learning curve. Teams get this wrong in both directions — over-customizing early and rebuilding later, or forcing genuinely distinct data into standard objects until reporting collapses. Vantage Point helps teams make this call during implementation and data-model reviews, with a bias toward standard objects unless the case for custom is clear.
Both Salesforce and HubSpot ship with a set of standard objects that model the universal core of a business: people (contacts/leads), organizations (accounts/companies), revenue events (opportunities/deals), and service events (cases/tickets). Decades of platform development — reporting engines, automation builders, mobile apps, integrations, AI features — assume that model.
A custom object is a new table you add to that model: "Properties," "Policies," "Projects," "Shipments," "Portfolio Companies" — whatever your business tracks that the standard set doesn't. Both platforms support them, both let you define fields, relationships, and automation against them, and both will happily let you build far more of them than you should.
For a grounding in how objects, properties, and associations fit together on the HubSpot side, see understanding the HubSpot data model.
Standard objects aren't just convenient — they're subsidized. Every platform feature is built against them first: forecasting assumes opportunities, sequences assume contacts, attribution reporting assumes deals. When your data lives in standard objects, new platform features tend to "just work" against it.
Custom objects get a partial inheritance. Reporting on them is possible but more constrained; some automation triggers and AI features lag for custom objects; third-party integrations rarely know your custom schema exists. None of this disqualifies custom objects — it prices them. The question is never "can we build it?" but "is the ongoing tax worth what the object buys us?"
There's also a compounding effect. Each custom object adds fields, page layouts, permissions, automation, and integration mappings that every future admin must understand. A data model with three well-justified custom objects is an asset; one with twenty just-in-case objects is why CRM implementations need rescue.
| Question | If yes → | If no → |
|---|---|---|
| Does this thing have its own lifecycle (stages it moves through)? | Custom becomes plausible | Standard object + status property |
| Does it relate to many contacts/companies over time, independent of any single deal? | Custom becomes plausible | Association on a standard object |
| Do you need to report on it as its own entity, not as an attribute of something else? | Custom becomes plausible | Property or list |
| Can a standard object with a "type" or "category" property express it? | Use standard | Continue evaluating |
| Will integrations or AI features need to act on it natively? | Strongly favors standard | Less weight on this factor |
| Would a new admin understand why this object exists in five minutes? | Justification is holding | Re-examine the justification |
Notice the direction of the framework: custom objects must prove themselves. Standard is the acquitted-by-default option.
Three patterns justify custom objects reliably:
The contrapositive matters more: if your justification is "it feels cleaner," "the old system had it," or "we might need it someday," that's a standard object with a category property waiting to happen. Feelings and futures don't pay the maintenance tax.
The failure patterns repeat across orgs:
A quarterly object-model review — what exists, who owns it, what's it for, does it still clear the framework — keeps the model honest without bureaucracy.
Inventory your current or planned custom objects. For each, answer the six framework questions in writing. Objects that can't answer the first three with a clear yes are consolidation candidates — plan the migration into standard objects before the next integration or reporting initiative makes it urgent. If you're designing a data model for a new implementation, make the framework part of the design review so "just add a custom object" stops being the path of least resistance.
Vantage Point runs data-model reviews for Salesforce and HubSpot: object inventories, custom-vs-standard decisions, association and pipeline design, and consolidation plans for models that sprawled. Through our Salesforce implementation and advisory and HubSpot technology services, senior consultants make these calls with you — senior consultants only, no junior handoffs; the experts you meet are the experts who deliver. When a standard object will do, we'll tell you, even though custom builds are more billable.
Vantage Point can review your object model, flag custom objects that should be standard (and vice versa), and design a consolidation or build plan. Contact Vantage Point for a data-model review, or explore our Salesforce services.
A custom object is a new data table you add to your CRM's model to represent something the standard objects don't — a property, policy, project, or asset. Both Salesforce and HubSpot support them with custom fields, relationships, and automation, but they inherit only part of the platform's native reporting and integration features.
When the thing you're tracking has its own lifecycle with distinct stages, relates to many contacts or companies independently, and needs standalone reporting. If a standard object plus a type or category property can express it, use the standard object — it inherits more platform capability for free.
Not licensing — maintenance. Each custom object adds fields, layouts, permissions, automation, and integration mappings that every future admin must understand, and some platform features (reporting depth, certain automation and AI capabilities, third-party integrations) work better against standard objects. A few justified custom objects are an asset; a sprawl of them is technical debt.
Yes. Both platforms support custom objects with custom fields, associations, pipelines, and automation. The practical difference is depth of native reporting and ecosystem assumptions — both favor standard objects, which is why the default-to-standard principle applies on either platform.
There's no universal number, but the test is justification density: every object should be able to answer "what distinct lifecycle, relationships, and reporting does this support?" in one breath. Models where most objects can't answer that are consolidation candidates regardless of count.
It's a data migration, not a rebuild: export the custom object records, map them to the standard object plus a category property, re-associate, and rebuild the handful of reports and workflows that referenced the old object. It's meaningfully easier before more integrations accumulate against the custom schema — which is why earlier is better.
With a written framework, not a preference: lifecycle, relationships, and reporting needs must all clear the bar before custom gets built. We run object-model reviews on existing orgs and design reviews on new implementations, and we'll recommend the standard option even when custom work would be more billable.
Vantage Point is a boutique CRM consulting firm helping businesses transform with Salesforce, HubSpot, and AI — 150+ clients, 400+ engagements, and a 4.71/5 average engagement rating. Learn more at vantagepoint.io.