🟡 HubSpot Operations Practical Textbook — 2026 Edition
Chapter 8

custom objects and
Advanced CRM design(Enterprise)

There is business data that cannot be expressed using HubSpot's standard "contacts, companies, deals, and tickets." Contracts, projects, products, assets, stores, real estate—bring domain-specific data into your CRM and associating it with existing objects.Evolving HubSpot from a general-purpose CRM to a system specialized for your business modelThe Data Agent runs in HubSpot.

📖 Estimated reading time: 25 minutes
🎯 Target audience: HubSpot administrators, RevOps engineers, solution architects
🔧 Required plan: Operations Hub Enterprise (required)

📋 Contents of this chapter

  1. 8-1What is a custom object? Differences from standard objects and design decisions
  2. 8-2Industry-specific use cases—SaaS, manufacturing, real estate, and education usage examples
  3. 8-3Property design and association design
  4. 8-4Best practices for creating, reading, writing, and operating with APIs
Section 8-1

What is a custom object? Differences from standard objects and design decisions

There are four standard objects in HubSpot: Contacts, Companies, Deals, and Tickets. These can be used in most BtoB businesses, butCompany-specific business entities (contracts, projects, equipment, assets, etc.) cannot be expressed.. Custom objects remove this restriction.

🗂️ HubSpot CRM Object Model——Standard + Custom Overview
standard object
👤
Contacts
firstname / lastname
email / phone
lifecyclestage
lead_score
standard object
🏢
Companies
name / domain
industry / employees
annualrevenue
city / country
standard object
💰
Deals
dealname / amount
dealstage / pipeline
closedate
hubspot_owner_id
standard object
🎫
Tickets
subject / content
hs_pipeline_stage
hs_ticket_priority
hs_resolution
★ Custom object example
📄
Contracts
contract_number
start_date / end_date
contract_value
auto_renew
★ Custom object example
🏗️
Projects
project_name
status / phase
kickoff_date
budget / actual_cost
★ Custom object example
🏠
Properties
property_address
property_type
asking_price
listing_date
★ Custom object example
⚙️
Equipment
serial_number
model / manufacturer
install_date
warranty_expiry
🔗 Associations——Objects can be freely connected
Contract ↔ Company (many to one)
. Only the following minimum roles will be granted.
Project ↔ Contact (many-to-many)
Equipment ↔ Company (many to one)
Equipment ↔ Ticket (many-to-many)
Property ↔ Contact (many-to-many)

Criteria for deciding whether to create a custom object

Judgment criteriacreate a custom objectOnboarding task creation
data independence That's the safe way to proceed. Can be expressed simply by adding custom properties to contacts and deals
one-to-many relationship There are multiple "contracts" for one company/One contact is linked to multiple "projects" If it is always one-to-one (one contract per company), it can often be handled by customizing the transaction object.
Utilization in WF/reports I want to run a workflow using that object as a starting point, and I want to summarize it in a report. If you just want to view it, you can also manage it using Notes or attachments.
Synchronization with external systems I want to use ERP/core system contracts, products, and orders by synchronizing them with HubSpot. If the external system is positive and HubSpot is just referencing it, it may be enough to just integrate it.
⚠️ Custom objects are “difficult to recreate”—taking time to design

Once you create a custom object and start filling it with data, it becomes difficult to change the object name, delete properties, or change associations.Before you start using it in production, be sure to verify the design in a sandbox and think about whether this structure will still be good in 5 years before creating it.. In particular, object names (API names) cannot be changed once they are set, so decide on naming rules in advance.

Section 8-2

Industry-specific use cases—SaaS, manufacturing, real estate, and education usage examples

The uses for custom objects vary widely depending on the business model. Specific design examples for four typical industries are shown below.

💻
Contracts (contract object)
SaaS/Subscription
"One company wants to manage multiple plans, separate contracts for each department, mid-term cancellations, and partial renewals. Using transaction objects alone will result in one transaction per company, making it impossible to track multiple contracts."
Custom objects: Contracts
contract_number
plan_type
mrr
arr
start_date
renewal_date
auto_renew
seats
contract_status
Related: Company (many-to-one) / Deal (one-to-one) / Contact (many-to-many/signer). Create an update task in CSM using workflow 90 days before the update date. Automatic aggregation of total MRR into company-level properties.
⚙️
Equipment (equipment/equipment object)
Manufacturing/Field Service
"I want to individually manage the equipment installed at a customer's factory. I want to see which equipment has the most problems and which equipment is nearing its maintenance deadline. Currently, I manage it using Excel, and the information is separated from the CRM."
Custom object: Equipment
serial_number
model_name
install_date
last_maintenance
warranty_expiry
firmware_version
location
equipment_status
Related: Company (installation location) / Ticket (many-to-many, list of support tickets related to this device). Automatically create a task for field service personnel 30 days before the maintenance deadline.
🏠
Properties (property object)
Real estate/rental management
``Contacts include buyers, sellers, owners, and tenants,'' and there are multiple parties involved in even one property. The transaction object is assumed to be one property per deal, so management cannot be centered on the property.
Custom object: Properties
property_address
property_type
floor_area
asking_price
listing_status
listing_date
year_built
rooms
Related: Contact (many-to-many/owner/viewer/buyer)/Deal (many-to-many). Centrally manage all parties, business negotiations, and preview history related to the property.
🎓
Enrollments (enrollment object)
Education / e-learning / School
"One student takes multiple courses, and the progress, grade, and completion date are different for each course. When you add properties for all courses to a contact, the columns explode and you can't create a report."
Custom object: Enrollments
course_name
enrollment_date
completion_date
progress_pct
final_score
certificate_issued
instructor
enrollment_status
Related: Contact (many-to-one, student) / Deal (one-to-one, sales transaction). A follow-up email will be automatically sent if the progress is less than 50% and 14 days have passed since the start of the course.
Section 8-3

Property design and association design

Property types that can be used in custom objects

Custom object properties can use all the same property types as standard objects. Choosing the right type has a direct impact on the accuracy of subsequent reports, filters, and automation.

text type
Single line text / Multiline text
Contract number, serial number, address, notes, etc. Free text can be entered flexibly.
⚠ If used for filtering and grouping, the "choice" type is more accurate
numerical system
Number / Currency / Percentage
MRR, ARR, progress rate, score, floor area, etc. You can calculate totals, averages, and maximum values ​​in reports.
✓ Values ​​that need to be aggregated or compared must be of this type.
date system
date/time
Contract start date, renewal date, installation date, completion date, etc. Date calculation (number of elapsed days/number of remaining days) is possible.
✓ Required if used for WF's "Trigger before XX days"
Choice system
Dropdown / Checkbox / Radio
Status (Active/Inactive), type, phase, priority, etc. Aggregation and filtering can be done reliably in reports.
✓ Always use this type for status and category types.
truth value system
Checkbox (single)
Automatic renewal flag, certificate issued, review completed, consent obtained, etc. Binary management of Yes/No.
✓ Flag management is done with Boolean. Avoid text yes/no
calculation system
Calculated property
For example, "Days remaining = renewal_date - today" or "Residual value = contract_value × (remaining_months / total_months)".
✓ Values ​​that can be calculated from other properties can be automated with calculated properties

Association design patterns

🔗 Key patterns for association design
Relationship definition between custom objects and standard objects/other custom objects
Pattern 1: Many-to-One
Multiple contracts tied to one company
Contracts ×N
───→
Company ×1
(N : 1)
In SaaS, one company has multiple contracts and multiple plans for each department. When you open a company record, all related agreements are listed. A company's total MRR can be summarized in a report.
Pattern 2: One-to-One
One contract corresponds to one transaction
Deal ×1
───→
Contract ×1
(1 : 1)
A pattern that automatically generates and links a corresponding contract when a deal is closed. You can immediately refer to the terms of the contract from the transaction record.
Pattern 3: Many-to-Many
Multiple contacts participate in multiple projects
Contact ×N
──↔──
Project ×N
(N : N)
Cases where one person is involved in multiple projects, such as consulting or IT projects, and multiple people are involved in one project. The role of "PM/Member/Client" can also be recorded using the association label.
Pattern 4: Custom ↔ Custom
Link tickets related to equipment
Equipment ×1
──↔──
Ticket ×N
(1 : N)
Aggregate support history for specific devices. You can instantly check the report to see how many troubles this device has had in the past year. When you open a device record, a list of related tickets will be displayed.
💡 Record roles with association labels

Associations in HubSpot can be labeled (roles). For example, by setting the label "Signer/Approver/Person in charge" for the Contract ↔ Contact association,Capable of recording contextual information beyond mere “linkage”. Labels can be added later, but if you think about what roles you want to track with this association when designing, you will be able to use it later.

Section 8-4

Best practices for creating, reading, writing, and operating with APIs

You can also create and update custom objects on a daily basis from the HubSpot UI, butLinkage with external systems, import of large amounts of data, automatic creation from workflowsUse the HubSpot API. The API endpoints for custom objects have the same structure as standard objects, only the schema (object definition) differs.

Creating custom objects (API)

POST /crm/v3/objects/{objectType} Creating records for custom objects
// Specify the API name of the custom object for objectType (e.g. p_contracts) // Note the prefix "p_" that HubSpot automatically adds { "properties": { "contract_number": "CTR-2026-00142", "plan_type": "Enterprise", "mrr": 200000, "start_date": "2026-04-01", "renewal_date": "2027-03-31", "auto_renew": true, "seats": 50, "contract_status": "Active" }, "associations": [ { // Link to related company "to": { "id": "12345" }, "types": [{ "associationCategory": "USER_DEFINED", "associationTypeId": 1 // Association type ID (check on the settings screen) }] }, { // Also link to related transactions (Deal) "to": { "id": "67890" }, "types": [{ "associationCategory": "USER_DEFINED", "associationTypeId": 2 }] } ] }

Six best practices for design, naming, and operation

01
API name (internal name) cannot be changed—determine naming rules first
Custom object API names (e.g. p_contracts) and property internal names (e.g. contract_number) cannot be changed once created. You can change the display name later, but the API name is persistent.
✗ NG: Meaningless names such as "test", "object1", "myobj"
✓ OK: “p_contracts” “p_equipment” “p_enrollments” — plural/snake case
02
Set the "Record Name" property in an easy-to-understand manner
Specify one "property that will be displayed as the record name" for the custom object. This will be the main label displayed on the list screen, so choose a value that is highly unique and meaningful (contract number, device serial number).
✗ NG: Numeric ID (even if "12345" is displayed, it has no meaning to humans)
✓ OK: Unique readable value such as “CTR-2026-00142” and “SN-XYZ-001”
03
Fully test your design in the sandbox before going live
Deleting custom objects is difficult after data has been added. The object name, property configuration, and association design are completely verified in the sandbox, reviewed by the team, and then created for production.
✗ NG: Make it in production as soon as you come up with it (you will regret it later)
✓ OK: Protect the process of sandbox → design review → production
04
The basic rule for properties is to start small and add more later.
If you create 100 properties from the beginning, the input load will increase, data quality will decrease, and management will become difficult. It is more likely to be successful if you first narrow it down to the 10 to 15 properties that are truly necessary, and then add the necessary properties as you operate.
✗ NG: Initial creation of a large number of properties that may be used in the future
✓ OK: Start with MVP (minimum configuration) and grow while operating
05
Narrow down the required fields and create a design that is “easy to input”
If there are too many required properties, the data quality will deteriorate as the person in charge enters random values. Require only a minimum of 3 to 5 items without which the object would not make any sense. The rest will be filled in with default values ​​or automatic input.
✗ NG: 20 items are required and people say, ``It's a hassle, so I won't use it.''
✓ OK: 5 items are required, the rest are optional or auto-completed
06
Zero input load with automatic creation from workflow
Create a workflow that automatically creates and links the corresponding Contract object when a transaction becomes Closed Won. This eliminates the need for personnel to manually create contracts and set associations, and eliminates omissions.
✗ NG: The rule “When an order is received, the person in charge manually creates a contract” always fails.
✓ OK: Deal Closed Won WF → Automatically create Contract → Automatically grant association

📌 Chapter 8 Summary

Custom objects are a feature that allows you to “make HubSpot specialized for your model.”

Business entities that cannot be expressed using the standard 4 objects can be added to CRM. The three criteria for judgment are ``10 or more unique properties, a one-to-many relationship, and a desire to use it in WF or reports.'' If this does not apply to all cases, you can often deal with it by adding custom properties.

Use cases vary greatly depending on the industry - refer to other companies' designs

Typical examples are Contracts (multiple contract management) for SaaS, Equipment (equipment tracking) for manufacturing, Properties (property management) for real estate, and Enrollments (attendance records) for education. In your business, ``data that is managed in spreadsheets and separated from CRM'' is a strong candidate for custom object creation.

API name and naming convention are determined “before creation”—cannot be changed later

Once set, the API name and property internal name of a custom object cannot be changed. The team agrees on a naming convention that uses plural snake cases like "p_contracts" and "p_equipment" before creating the actual product. Verification in sandbox is required.

Associations record even the “role of the relationship” using labels.

In addition to simply ``linking,'' the context of the relationship can also be recorded by labeling the ``Contract ↔ Contact'' association with ``Signer/Approver/Person in Charge.'' Express many-to-many relationships using associations, and do not try to create intermediate tables yourself.

Next Chapter
Chapter 9: Security, Authority, and Governance Design →