Consider a HubSpot custom object when your business needs to manage a distinct entity with its own identity, relationships and lifecycle. Do not create one just because a spreadsheet has extra columns. First decide whether the information describes an existing record, connects existing records or represents something that deserves a record of its own.
TLDR: Use a property for an attribute, an association for a relationship and a separate object for an entity that needs independent records. Evaluate standard objects first. Test the proposed model against reporting, automation, access and maintenance requirements before creating a custom schema.
Product documentation checked August 28, 2026. The three models below are fictional design examples. No custom object, property, association or CRM record was created for this article.
Start with the business entity in your HubSpot CRM
Ask whether the thing you want to track can exist more than once for the same person or company. Does it have an independent identity? Can its status change without changing the company? Does another team need to manage it separately?
Those questions help distinguish a description from an entity. A customer's preferred delivery method describes that customer. Several separately managed pieces of equipment may require individual records. A relationship between a contact and a company connects two existing entities.
We recommend documenting the business meaning before selecting a technical structure. A portal audit can expose repeated fields or duplicated records that suggest a model problem, but the repair should follow a clear requirement.
Confirm the account and feature constraints
HubSpot's current documentation lists eligible Enterprise subscriptions and requires Account access permissions to create, edit and manage custom objects. It also notes subscription-dependent object and property limits. Check the actual account before designing around a capability or capacity assumption. HubSpot: create and edit custom objects.
The same documentation recommends evaluating existing objects first. It identifies standard-object features that do not transfer automatically, including contact-based bulk marketing email and deal-based attribution and forecasting. A custom object is not a universal replacement for a contact or deal. HubSpot: custom-object considerations.
We recommend listing the exact reports, workflows and user actions that must work with the proposed model. Then verify each one in the intended subscription and configuration. A schema diagram alone cannot prove the operating process will work.
Model one: custom properties describe an existing record
In this fictional example, a service company wants to record each customer's preferred invoice delivery method. The business allows one current preference per company, and the value does not need an independent owner, status or history as a separate managed entity.
The proposed model is simple:
| Existing record | Proposed attribute | Business meaning |
|---|---|---|
| Company | Preferred invoice delivery method | The current approved preference for this company |
A property is the first option to evaluate. Creating a separate “Invoice Preference” object would add a record and relationship that the business has not shown it needs.
Before implementation, define the allowed values, the authoritative source and who can change the preference. If the requirement later expands to several billing arrangements with separate effective dates and owners, revisit the model. That is a new requirement, not proof that the simpler initial design was careless.
Model two: a relationship connects existing records
In this fictional example, one contact can be involved with several companies, and each company can have several contacts. The business needs to identify the person's relationship to each company without duplicating the person every time.
The proposed design question is relational:
| Existing entity | Relationship to evaluate | Existing entity |
|---|---|---|
| Contact | The person's approved role in this company relationship | Company |
Evaluate the available association behavior and any required relationship labels in the target account. The fact that a contact belongs in more than one business relationship does not, by itself, justify a new contact-like custom object.
Now test an edge case: the same person changes roles at one company but remains involved with another. Can your proposed model represent that difference without overwriting unrelated information? If the relationship itself needs extensive independent attributes, dates and a workflow, document those requirements before deciding whether a separate relationship entity is warranted.
Model three: an independently managed entity may need its own object
In this fictional example, a company owns several pieces of equipment. Each item has a unique identifier, service status and installation date. A service coordinator needs to find one item, associate it with the customer and track work related to that item.
The proposed logical model is:
| Entity | Independent information | Relationship |
|---|---|---|
| Company | Customer identity and ownership | Can be associated with several equipment records |
| Equipment candidate | Unique equipment identifier, installation date and service status | Belongs to the agreed customer relationship |
| Service record | The specific service request and its outcome | Connects to the relevant equipment and customer as required |
This is a candidate for a separate entity because each equipment item must remain individually identifiable. It is not a conclusion that a custom object is the only or best implementation. Evaluate the available standard objects and the required service tools before choosing.
Avoid fields such as “Equipment 1 status,” “Equipment 2 status” and “Equipment 3 status” if the business needs an open-ended list of independently managed items. The requirement is about repeated entities, not simply adding more columns.
Test the model with difficult questions
We recommend testing a small synthetic dataset before approving the schema. Include an entity with no relationship, several relationships, a changed owner and an archived record. Ask users to complete their actual jobs using those examples.
The review should cover:
- Identity: Can you identify and update the correct record without guessing from its display name?
- Cardinality: Can the model represent the required number and direction of relationships?
- Lifecycle: Can one entity change status without corrupting an unrelated process?
- Reporting: Can the required measures be calculated with the intended filters and associations?
- Access: Can each user see and change only the information required for their role?
- Operations: Who handles duplicates, missing relationships and retired records?
Keep configuration errors separate from model limitations. A common HubSpot issue might need a property mapping fix rather than a new object.
Approve ownership before creating the schema
Name the business owner, technical maintainer and report owner. Document the identifier, required fields, allowed statuses, association rules and retirement process. Explain how existing data will be mapped and reconciled if the model replaces a spreadsheet or an older structure.
We recommend approving the schema and migration plan separately. A good target model does not make a bulk import safe. The implementation still needs representative tests, backups appropriate to the change and a way to verify the resulting records and relationships.
For help reviewing a proposed data model, see Selworthy's HubSpot operations services or contact Selworthy. Share a simplified entity diagram and the business questions it needs to answer, without sending sensitive customer records in the initial request.
Keep custom properties and object records understandable
A custom property describes something about a record. An object record identifies a separately managed instance of an entity. Association labels can help explain relationships, subject to the behavior available in your HubSpot account. Keep those three design choices visible in the proposed data structure.
For the equipment example, separate the display name people recognize from the identifier used to reconcile records. Two machines could have the same descriptive name. Your import and integration design still needs a reliable way to distinguish them and to connect each one to the correct customer.
Document the singular and plural object names, identifying fields and relationship rules before you create a custom object. Explain what happens when an equipment item changes customer or is retired. A data model needs to describe ongoing business processes, not only the first import.
Use custom objects only when the added structure earns its maintenance cost. More objects can make a diagram look sophisticated while making routine customer requests harder to answer.
Compare standard objects before creating a custom object
Start with what HubSpot's standard objects already represent in your process. A contact record represents a person; creating another person-like object can split customer data and communications across two places. Preserve the business purpose of the existing object before adding a new one.
Next, distinguish one-to-one and one-to-many requirements in plain language. Does one company have one current preference, or can it have several independently managed arrangements? Can several contacts relate to the same equipment record? The relationship requirement matters more than the number of columns in the original file.
When the standard objects fit, use their supported properties and associations. When they do not, explain the gap with examples that users recognize. That explanation gives the maintainer a reason for the custom structure and helps prevent another team from building a duplicate model later.
Frequently asked questions
When should you use a custom object in HubSpot?
Consider one when a business entity needs independent records, identity, relationships and lifecycle management that the available standard objects do not suitably represent. Verify account eligibility and required reporting, automation and access behavior before choosing the design.
When is a property enough?
A property is often the first option when the information describes an existing record, such as one current preference or classification. Repeated independently managed items may require a different model rather than a growing series of numbered properties.
Does a many-to-many relationship always require a custom object?
No. First evaluate associations between the existing entities. A separate relationship entity becomes a design candidate when the relationship needs its own substantial information or lifecycle, but the required behavior still needs verification in the target account.
Should custom objects replace deals or contacts?
Not automatically. Standard objects have specific product behavior and reporting connections. Preserve the business purpose of contacts and deals, and verify any feature dependency before moving that information into a custom model.
