If you've ever opened your HubSpot CRM and felt overwhelmed by duplicate properties, broken reports, or workflows that reference fields nobody remembers creating—you're not alone. The root cause is almost always the same: a poorly designed data model.
HubSpot's data model is the invisible architecture that determines how your customer information is stored, organized, and connected. It's the difference between a CRM that empowers your team and one that creates more confusion than clarity. For organizations in regulated industries—financial services firms tracking AUM and compliance milestones, healthcare organizations managing patient engagement, insurance companies handling policy lifecycles—getting the data model right isn't just a best practice. It's a business imperative.
In this comprehensive guide, we'll break down every component of HubSpot's data model, explain when to use custom objects versus custom properties, walk through real-world architecture scenarios for regulated industries, and share the best practices that prevent the "property sprawl" problem plaguing most HubSpot portals.
The HubSpot data model is the underlying structure that organizes all customer and business data within the CRM platform. Think of it as the blueprint for your database. Just as a building's architectural plans determine where walls, doors, and plumbing go, your data model determines where information lives, how it's categorized, and how different pieces of data relate to one another.
At its core, HubSpot's data model consists of four layers:
If you have experience with relational databases, HubSpot's architecture will feel familiar—the terminology differs, but the concepts are identical.
Objects are the top-level containers in your data model. Each object represents a distinct category of information and functions as its own database table with a unique schema, properties, and relationship rules.
Every HubSpot portal includes several pre-built objects. The most commonly used are:
| Object | Purpose | Deduplication Key | Available On |
|---|---|---|---|
| Contacts | People who interact with your business | Email address | All tiers |
| Companies | Organizations associated with your business | Domain name | All tiers |
| Deals | Revenue opportunities moving through your pipeline | Record ID | All tiers |
| Tickets | Customer support requests and issues | Record ID | All tiers |
| Leads | Sales qualification tracking for contacts/companies | Record ID | Sales Hub Pro+ |
| Products | Items or services your business sells | Record ID | All tiers |
| Quotes | Formal cost estimates linked to deals | Record ID | All tiers |
| Invoices | Digital bills sent to customers | Record ID | All tiers |
| Subscriptions | Recurring payment tracking | Record ID | All tiers |
HubSpot also includes specialized objects like Marketing Events, Campaigns, Appointments, Services, Listings, Courses, Projects, Carts, and Orders—some of which must be activated by a Super Admin in the Data Model tool.
Custom objects are user-defined tables for data that doesn't fit standard categories. Available on Enterprise subscriptions, custom objects behave identically to standard objects—they support custom properties, associations, workflows, and reporting. The difference is that you define the entire schema.
Common custom object examples for regulated industries:
Properties are the individual data fields stored on each record. Every property has four critical components:
| Property Type | Best For | Key Limitation |
|---|---|---|
| Single-line text | Names, IDs, short descriptions | Up to 65,536 characters |
| Multi-line text | Notes, detailed descriptions | Cannot be evaluated in workflow branching logic |
| Number | Revenue, counts, scores | Floating-point precision can cause rounding errors |
| Date | Deadlines, milestones | Evaluates in portal timezone, not user timezone |
| Date and time | Meeting times, timestamps | Includes time component unlike basic date |
| Dropdown select | Status, category, lifecycle stage | Internal values are permanent; display labels can change |
| Multiple checkboxes | Tags, multi-select categories | Harder to report on than single-select dropdowns |
| Calculated | Derived metrics, formulas | Fails silently (shows blank, no error message) |
| Score | Lead scoring, engagement scoring | Requires careful criteria management |
The single biggest data model mistake organizations make is uncontrolled property creation. Marketing creates lead_source_campaign, Sales adds campaign_source, and Operations builds utm_campaign_source—three properties tracking identical data.
Why it happens: HubSpot doesn't enforce property governance by default. Any user with sufficient permissions can create custom properties without validation, naming standards, or cross-functional review.
The impact:
The solution: Establish a property naming convention before building. Use prefixes to signal ownership and purpose: compliance_ for regulatory fields, fin_ for financial metrics, mkt_ for marketing properties, and ops_ for operational data.
Unlike display labels, internal API names cannot be changed after creation. If you create a property with the API name q4_2024_campaign_source and later need it for all quarters, you're stuck with a misleading name forever—or you must create a new property, migrate data, update all workflows and reports, then deprecate the old one.
Best practice: Always use generic, timeless API names (campaign_source_primary) even if the initial use case is time-bound.
Associations are the relationships between records. They're what allow you to see all contacts at a company, all deals associated with a contact, or all tickets linked to a specific product.
| Association | Cardinality | Example |
|---|---|---|
| Contact → Company | Many-to-one | Each contact has one primary company; companies have many contacts |
| Contact → Deal | Many-to-many | Contacts can be on multiple deals; deals involve multiple contacts |
| Deal → Company | Many-to-one | Each deal belongs to one primary company |
| Ticket → Contact | Many-to-one | Each ticket has one primary contact |
| Custom Object → Any | Configurable | You define the cardinality during object creation |
Association labels add context to relationships. Instead of just knowing "Jane Smith is associated with Acme Corp," labels let you specify how they're related:
For regulated industries, association labels are particularly powerful:
HubSpot's Data Model Builder (Settings → Data Management → Data Model) provides a visual representation of your entire CRM architecture. Updated significantly in late 2025, the tool now allows you to:
Pro tip: If your data model visualization looks like a plate of spaghetti with 15+ objects and 50+ association lines, it's time for an architecture review.
As of August 2025, HubSpot's Breeze Copilot can also help you configure your data model and answer questions about best practices—a helpful starting point, though not a substitute for strategic architecture planning.
This is the most common architectural decision teams face. Here's a clear decision framework:
1. One-to-Many Relationships Need Independent Tracking
A financial advisory firm manages multiple client accounts, each with its own AUM, investment strategy, risk tolerance, and rebalancing schedule. Adding account_1_aum, account_2_aum properties to Contact records creates rigid schema that breaks when clients have more accounts than you anticipated.
Solution: Create an "Accounts" custom object. Each Account record associates to one Contact (many-to-one) with properties for account_type, aum, strategy, risk_profile, and last_rebalanced_date.
2. Many-to-Many Relationships Require Context
An insurance brokerage handles policies that involve multiple contacts from multiple companies—policyholders, beneficiaries, agents, and underwriters all play different roles. Standard associations can't capture who represents which company in which capacity.
Solution: Create a "Policy Participants" custom object that sits between Contacts, Companies, and a "Policies" custom object, with properties like participant_role and relationship_type.
3. The Data Has Its Own Independent Lifecycle
A healthcare technology company sells annual compliance licenses that renew independently of the original deal. Each license has its own activation date, expiration, compliance status, and renewal terms.
Solution: Create a "Licenses" custom object associating to the originating Deal and the Company, with workflows triggering renewal processes 90 days before expiration.
compliance_status on Company recordsclient_segment dropdown on Contact recordsprimary_competitor text fieldDocument your intended data model in a spreadsheet or diagramming tool before touching HubSpot. Map out which objects you need, properties for each with naming conventions, association types and labels, and cardinality rules for every relationship.
Assign a Data Steward (or small governance committee) responsible for approving new property requests, maintaining naming conventions, conducting quarterly property audits, and documenting the data model for new team members.
For organizations in regulated industries, your data model must support:
Calculated properties that depend on other calculated properties introduce calculation lag and silent failures. Limit chains to a maximum of two levels.
Instead of creating custom objects just to "organize" properties, use Property Groups (Settings → Properties → Groups) to categorize related properties within objects.
Schedule quarterly reviews to identify duplicate or unused properties, archive deprecated properties, review association labels for redundancy, and validate that workflows still reference active properties.
Before rolling out a new data model component, test with 10–20 records to validate reports, workflows, associations, and cross-object queries.
| Limit | Professional Tier | Enterprise Tier |
|---|---|---|
| Custom objects allowed | 10 | 100 |
| Custom object records (per object) | 150,000 | 2,000,000 |
| Total custom object records | 600,000 | Unlimited |
| Custom properties per object | 10,000 | 10,000 |
| Association labels per object pair | 100 | 100 |
| Marketing contacts (baseline) | 100,000 | Varies |
Additional constraints:
Problem: Teams name properties q4_2024_campaign_source. Six months later, they need it for all quarters.
Solution: Use generic, timeless names from the start (campaign_source_primary).
Problem: Default labels like "Contact at company" lack specificity. Retroactively adding labels requires bulk updates.
Solution: Define association labels during object creation, before associating any records.
Problem: Creating a "Company Details" custom object to hold company attributes, with one-to-one associations to Company records.
Solution: Use property groups and record customization instead. Custom objects are for complex relationships, not data organization.
Problem: Revenue data exists in Deal amount, a custom annual_contract_value, and a calculated total_deal_value with no clear hierarchy.
Solution: Define which property is authoritative for each metric, document it, and build all reports from that single source.
Problem: Building 15 custom objects and 300+ properties before anyone has used the system.
Solution: Start with standard objects and minimal custom properties. Add complexity as real usage patterns emerge.
HubSpot's data model consists of four layers: objects (database tables like Contacts, Companies, Deals), records (individual entries within each object), properties (data fields on each record), and associations (relationships connecting records across objects). Together, these components define how all customer and business data is stored, organized, and related within the platform.
Create a custom object when data has one-to-many or many-to-many relationships, needs its own lifecycle (like contract renewals), or requires independent reporting. Use custom properties when data describes attributes of an existing record, involves simple one-to-one relationships, or tracks categorical information like status or type.
No. Internal API names are permanent once created. You can change the display label (what users see), but the underlying API name used by workflows, integrations, and reports cannot be modified. If you need a different API name, you must create a new property, migrate all data, update all references, and then deprecate the original property.
Professional tier allows up to 10 custom objects with 150,000 records per object (600,000 total across all custom objects). Enterprise tier allows up to 100 custom objects with 2 million records per object. All tiers support up to 10,000 custom properties per object and 100 association labels per object pair.
HubSpot supports compliance through sensitive data tools (introduced mid-2024 for HIPAA), field-level permissions to restrict access to regulated data, comprehensive audit trails logging every property change, and configurable data retention policies. Organizations should design custom objects and properties specifically for compliance tracking—such as separate objects for compliance cases, audit findings, or regulatory milestones.
The Data Model Builder (Settings → Data Management → Data Model) is a visual tool that displays all objects as nodes with connecting lines showing associations. It's available on all hubs and tiers for viewing, but custom object creation requires Enterprise subscription. The tool allows you to create objects, define properties, toggle display settings, and visualize your entire CRM architecture.
Associations are two-way relationships between records. When you associate Contact A with Company B, Company B is also associated with Contact A. Associations can be unlabeled (basic relationship) or labeled (with context like "Decision Maker" or "Billing Contact"). Different object pairs have different cardinality rules—for example, Contact → Company is many-to-one, while Contact → Deal is many-to-many.
Your HubSpot data model is the foundation everything else is built on—reporting, automation, integrations, AI tools, and ultimately your team's daily productivity. Getting it right from the start saves months of remediation work later. Getting it wrong creates compounding data quality issues that undermine every CRM initiative.
For organizations in regulated industries, the stakes are even higher. A poorly structured data model doesn't just slow down your sales team—it can create compliance gaps, audit failures, and client trust issues.
The key principles to remember:
Ready to build a HubSpot data model that scales with your business? Vantage Point specializes in CRM architecture for regulated industries. Whether you're implementing HubSpot for the first time or optimizing an existing portal, our team can help you design a data model that supports clean reporting, powerful automation, and full compliance.
Vantage Point is a CRM implementation and optimization partner specializing in regulated industries. We help financial services firms, healthcare organizations, insurance companies, and other compliance-sensitive businesses get the most from their HubSpot and Salesforce investments. From data model architecture to workflow automation to AI-powered personalization, we build CRM solutions that drive growth while maintaining compliance. Learn more at vantagepoint.io.