Skip to content

Plan your HubSpot data model

Last updated: October 20, 2026

Available with any of the following subscriptions, except where noted:

If you’re an admin setting up your account, you need to decide how you’ll handle your data in HubSpot. What data will you store, how will it be formatted, and how will it relate to each other? The data architecture you choose for your implementation of HubSpot is crucial to help you accomplish your business goals.

Without a plan for your data architecture, you run the risks of having messy data, of introducing duplicate records or properties in your CRM, and of having to rebuild aspects of your CRM to fix problems that could have been anticipated with proper planning. You can avoid these issues by outlining your business goals and what you want your users to do in the CRM, determining how your data relates to those goals and user actions, and creating a plan for implementing that specific data model. Creating this model before you start building processes in HubSpot ensures that your teams are aligned on the plan from day one.

To help you in these efforts, this guide includes:

Subscription required An Enterprise subscription is required to create custom objects.

Determine your data needs

Before you start importing data into HubSpot or creating custom objects, you’ll need to understand what types of data will best serve your goals.

To help you understand your data needs, consider the questions in the categories below.

Revenue generation

Outlining your business’ revenue model can help you understand what is important to track for your business to be successful.

  • How does your business make money?
  • What are the primary revenue motions for your business (e.g., rep-driven sales, self-purchase, contracts, subscriptions, etc.)?
  • How are you currently tracking sales/revenue?

Customer lifecycle

Understanding how a customer moves through your business helps you figure out what data needs to exist on each record and which objects need pipelines. It also surfaces a common mistake: treating lifecycle stage and deal stage as the same thing.

Lifecycle stage (e.g., lead, customer, churned, etc.) describes where someone is in their overall relationship with your company. Deal stage tracks the progress of a specific commercial opportunity. Conflating the two makes reporting unreliable, so it’s crucial to understand these elements before you start creating records in HubSpot.

  • What are the major stages in your customer lifecycle?
  • What events cause a record to move from one stage to another? Are there approval processes at specific stages?
  • What does leadership need to measure at each stage?

Business elements

Once you understand your revenue model and your ideal customer journey, you can identify the specific things your business needs to track: the “nouns” of your business. In HubSpot, these nouns are represented by object types (like contacts, companies, deals, tickets, or custom objects you define). The records you create in HubSpot will fall into one of these object types, so it’s important to have clear definitions of them before you start importing data.

The goal is to list every type of record you’ll need, not to decide yet whether it’s a standard or custom object. That decision comes later. After outlining your revenue model, you can expand on the specific elements that drive that model.

  • What are the core components of your business (e.g., “contacts,” “deals,” “subscriptions,” “appointments,” etc.)?
  • Do you need to track more specialized entities, like locations, implementations, vendors, or programs?
  • How do these entities relate to each other (e.g., an “appointment” taking place at a specific “location,” an individual “shipment” that’s part of a larger “order,” a “contract” signed as part of a “deal”)?

Permissions and usage

As you start to plan the data needs for your business, it can be helpful to figure out which teams will be responsible for specific processes, and what data they need access to in order to meet their goals.

  • Which teams will rely on HubSpot as a system of record? Do any teams need their own record type to track a specific process (e.g., a sales team tracking a “lead” as a distinct record of interactions with a specific “contact”)?
  • What are the crucial data points those teams need to act on when accomplishing tasks?
  • Where do responsibilities change hands between teams?

The answers to these questions will help you start to understand the types of data that are important to your business and how that data can be formatted. In the next step, you’ll use this information to create a diagram of your data model, giving your team a plan for your CRM usage in HubSpot.

Build an entity relationship diagram (ERD)

Now that you know the types of data you want to store in HubSpot, you can outline how these data points relate to each other. This map of data and relationships will be your business’ entity relationship diagram (ERD). The ERD helps you define how your data will be structured in your CRM.

While HubSpot provides a data model builder where you can create custom objects, it’s important to plan your approach before you start building the custom objects themselves. Creating an ERD outside of HubSpot ensures that your teams are aligned on your data strategy and can give you a place to experiment without having to commit to creating specific object types. Once you’ve refined your ERD, you can then enact that strategy in HubSpot more efficiently.

1: Listing out business entities (example)

Write out all your business elements. It can be helpful to add a brief description of what the entity “represents.”

For example, if your business runs primarily on a service model, where you install and maintain industrial equipment, you might include the following entities in your diagram (among others):

  • Company records, representing your end customers.
  • Contact records, representing points-of-contact at those companies.
  • Deal records, representing sales of equipment to be installed and then serviced for a contracted period.
  • Location records, representing the specific locations where the equipment will be installed.
  • Service records, representing the maintenance done for specific machines.

Here are the business entities listed out for our hypothetical company:

2: Deciding between standard and custom objects (example)

Review your business elements and determine which of the entities are covered by HubSpot’s standard objects, and which would require the creation of custom objects.

For example, our industrial equipment company can use the standard HubSpot objects for companies, contacts, deals, and services. They’ll choose to make a custom object for locations.

3: Mapping object relationships (example)

Once your entities are listed, you’ll need to connect them with the proper relationships.

For example, the industrial equipment company would note the following relationships (among others):

  • A company can have one or more contacts. Each contact only has one company.
  • A company can have any number of deals (or it could have zero deals). Each deal is associated with exactly one company.
  • Deals are also associated with at least one contact. A contact can be associated with any number of deals (or they could be associated with zero deals).
  • Each deal is associated with at least one location. A location can be associated with one or more deals.
  • A service record is for a particular piece of equipment, so it can only have one location. Each service record is also associated with a single deal.

In this step, the business entities (i.e., the objects that will be used in HubSpot) have been connected with lines that describe how they are associated with each other. These lines also display the type of association (e.g., one-to-many, many-to-many, etc.).

4: Adding association labels (example)

Some relationships between entities might be complicated. In your ERD, you can provide labels to the relationships to mark exactly how a particular record is associated with another.

For example, our industrial equipment company might work with many contacts to close a deal, but only one contact is authorized to sign off on the sale. They can add a label to the relationship between deals and contacts, noting the “Role” of the contact:

Example ERDs by revenue model

Below, there are four example ERDs, representing companies that follow different revenue models. Each example ERD is designed as one possible solution for that hypothetical company.

Additionally, each example focuses on just a subset of the objects used by the company. In their full ERD, they’d include other objects to track other aspects of their business, such as marketing efforts and customer service processes.

Each example includes:

  • A hypothetical company, with a brief description of how they operate their business, and an explanation of some of the decisions they made related to object usage.
  • A list of the key objects they plan to use in their CRM. In reality, each of these businesses would use more object types than what’s listed. The goal here is to review how these different revenue companies can organize standard and custom objects to serve their specific needs.
  • A snapshot of their ERD. Again, these screenshots will represent just a portion of what an ERD for these businesses would include.

Example: SaaS/Subscription/MRR

SPRKT is a software company that provides a cloud-based design studio for inventors to model new handheld gadgets. The software is sold on a subscription basis with various subscription levels.

Inventors can use the software to create multiple unique designs for their gadgets. These designs are created in a specific instance of software: the customer account. SPRKT decided to model customer accounts as a custom object, so that they can track which features their customers are using.

Objects used:

  • Contacts: represents individuals.
  • Companies: represents companies.
  • Deals: represents sales of software subscriptions.
  • Subscriptions: represents the recurring payments for the software.
  • Customer Accounts: represents the specific instances of customers’ software accounts. On the customer account record, they can track software usage events (creating new designs, leveraging specific features, etc.).

Example: Services/retainers

The Sprocket Group is a consulting company that offers business advice for inventors of handheld gadgets. They sell one-time consulting packages on topics like applying for patents and creating a corporation. They also provide ongoing consulting services to help inventors market their inventions and organize their sales processes.

After they listed out their data needs, they realized that standard objects in HubSpot can handle exactly what their business is looking to track. They can still customize these standard objects as needed. For example, they can rely on association labels to differentiate between a company’s purchase of one-time services and ongoing consulting.

Objects used:

  • Contacts: represents individuals.
  • Companies: represents companies.
  • Deals: represents sales of consulting packages.
  • Subscriptions: represents the fees for ongoing consulting packages.
  • Services: represents the delivery of consulting hours for one-time services or ongoing consulting. On the service record, they can track which consultants are working with the customer and how many hours remain in the package (for one-time services). They can also use the service object to gather all their internal notes related to the customer.

Example: E-commerce transactions

Sprockets ‘R’ Us is an e-commerce company that sells handheld gadgets. They have two types of customers: direct consumers (who order directly from their website) and retail stores (who purchase stock in bulk for resale in physical stores).

Their sales to direct consumers are relatively easy to track, since those purchases are small and are going to a single location. For these customers, they can include all of the purchase information on the standard deal record. Their sales to retail stores, however, are more complex, requiring the tracking of multiple shipments and a more involved supply chain. They’ve decided to model this more complex data with custom objects.

Objects used:

  • Contacts: represents individuals. Most of their contacts will be direct consumers who purchase from their website.
  • Companies: represents the retail stores who purchase stock in bulk.
  • Deals: represents sales. They differentiate between their direct-to-consumer sales and their retail sales by using two different pipelines.
  • Retail Shipments: represents packages shipped together. Some of their retail sales require multiple shipments, so it’s useful to have the shipment data on its own record. This way, they can track deliveries and returns efficiently.
  • Warehouses: represents the specific source of shipments, and tracking the stock available at that location.

Example: Platform/Marketplace commissions

Sprocket-Mart is a platform that connects gadget inventors with customers. The platform allows inventors to create simple storefronts where they can list their gadgets for sale. Customers can search and filter the marketplace listings, compare sellers, and purchase gadgets. A small percentage of the sale goes to Sprocket-Mart as a commission.

Sprocket-Mart will use standard HubSpot objects to represent the users of their marketplace and the commissions that they earn on sales. However, they decided to use custom objects to represent the public profiles for inventors and the reviews that customers can leave on those seller profiles. That way they can separate the public-facing data (seller profiles and reviews) from the internal business data (user information and sales commissions).

Objects used:

  • Contacts: represents individual inventors and customers.
  • Deals: represents commissions earned on sales made through the marketplace.
  • Profiles: represents a seller’s details for a particular market. In rare cases, an individual inventor could run multiple storefronts, so it’s important that the contact object has a one-to-many relationship to the profile object.
  • Marketplace Sale: represents a specific exchange between a seller and a buyer on the marketplace. Marketplace sales are associated with the seller’s profile record, the contact making the purchase, and the deal record where the marketplace commission is stored.

Next steps

Was this article helpful?
This form is used for documentation feedback only. Learn how to get help with HubSpot.