Key Takeaways
- Use a separate object when something can exist multiple times per customer and needs independent tracking.
- Check existing platform objects before creating a new definition.
- Give records stable identifiers and define which system owns each important field.
- Specify what one row means in every revenue report to prevent double-counting.
- Validate real business scenarios and failure cases before loading production data.
A customer has three product workspaces, two contracts, different renewal dates, and one parent company. Your CRM has one “Renewal date” field.
Which date should it contain?
That question exposes a data-model problem. Adding another field may postpone it, but the structure still cannot describe the business reliably.
HubSpot custom objects let you represent business entities that do not fit the platform’s existing objects. For a SaaS company, that might mean product workspaces or contractual entitlements. The important decision is whether an entity needs its own identity, relationships, and lifecycle.
Where Standard HubSpot Objects Fall Short for B2B SaaS
Contacts describe people, companies describe organizations, and deals describe commercial opportunities. These are useful foundations for a b2b saas crm, but they may not fully describe how your product is purchased and used.
Imagine a fictional customer, Northstar Analytics. It has a European workspace and a US workspace. One contract covers both. A second contract covers an additional business unit, with a different renewal date and commercial owner.
Repeated fields such as “Contract 1,” “Contract 2,” and “Contract 3” reveal the problem. Every additional contract requires structural changes, while reporting and automation must account for every numbered field.
However, do not assume every SaaS concept requires a new object. Review the standard subscriptions and other relevant objects available in your account, including their integration behavior. The right question is whether the existing structure supports your actual process, not whether you prefer a different label.
How Custom Objects Work Inside the HubSpot Data Model
An object defines a category of records. A record represents one instance. A property describes that instance, while an association connects it with another record.
For Northstar, “Workspace” could be the object, “Northstar EU” a record, and “Production region” a property. Associations connect the workspace to its customer company and relevant contacts.
HubSpot supports relationships between custom and standard records, with usage in supported automation and reporting tools. The data model builder helps you inspect and configure the structure.
The following is an illustrative design, not a requirement to create every row as a custom object:
| Entity | What one record means | Example properties | Key relationships |
| Company | One customer organization | Account owner, segment | Contacts, contracts, workspaces |
| Contact | One person | Role, email | Company and relevant workspaces |
| Deal | One commercial opportunity | Type, stage, amount | Company and related contract |
| Contract | One commercial agreement | Contract ID, term dates, currency | Company, workspaces, related deals |
| Workspace | One product environment | Workspace ID, region, activation date | Company, contract, administrators |
The distinction between a contract and a deal matters. An initial sale and a later expansion are separate commercial events, even if both relate to one continuing agreement. Decide where current recurring value belongs before building either record type.
How to Plan a Custom Object Structure Before Building
Start with decisions your team needs to make
Write down three questions the structure must answer. For example:
- Which agreements renew next quarter, and who owns the conversation?
- Which workspaces have low adoption despite a significant contract value?
- Which customer contacts administer each environment?
Use the property-versus-object test
Choose a property for an attribute, such as a workspace’s region. Consider an object when the thing needs an independent ID, can occur more than once, or has its own dates, status, and relationships.
Define identity and ownership
Give each integrated entity a stable external identifier. Names are useful for people, but “Northstar Production” can change or be reused. Your matching logic should not depend on it.
Create a small ownership register:
| Field | Authoritative source | Intended CRM behavior |
| Contracted recurring value | Billing or contract system | Updated from the agreed commercial source |
| Workspace activation date | Product system | Synchronized into the CRM |
| Renewal owner | Revenue operations | Maintained by the responsible team |
| Customer health assessment | Customer success | Updated through a documented review process |
Also define what happens when the source provides a blank value, an older update, or a cancellation. Those rules are part of the design, not implementation details to improvise later.
Map relationships before loading records
Specify how many relationships are allowed and what they mean. Can a workspace belong to more than one agreement? Does a contact administer several workspaces? Who is the billing contact versus the technical administrator?
Where Salesforce remains part of the environment, document integration direction and conflict rules. Our guide to how the two platforms work together provides relevant background.
Build a small, complete version
Use the object creation documentation to create the definition, display properties, and associations. Then add the minimum fields needed for your first workflow and report. Configure a usable record view before asking the wider team to test it.
The Custom Object Mistakes That Break Reporting and Automation
Counting revenue at the wrong level
Suppose Northstar has a $60,000 annual agreement covering three workspaces. Copying $60,000 onto each workspace and summing the field produces $180,000.
Define the reporting grain: what does one counted record represent? Contract value belongs at the agreement level unless you explicitly allocate it across workspaces. An allocation should have a documented rule and reconcile to the original total.
In hubspot reporting, inspect selected data sources, associations, and aggregation behavior. The custom report builder documentation explains how report sources are configured. Validate the resulting numbers against a known sample before sharing the dashboard.
Overwriting history needed for comparison
Today’s recurring value does not reveal last quarter’s recurring value. Updating a current-value property may serve operational needs while failing historical analysis.
Agree whether changes should be represented through commercial events, snapshots, a reporting dataset, or another maintained history mechanism. Do not promise historical retention metrics from a structure that only stores current state.
Our guide to SaaS renewals and recurring revenue explores the wider operational requirements behind those metrics.
Triggering repeated actions
A renewal date changes. An integration updates the record again. A workflow creates another renewal task or opportunity.
Prevent repetition with an explicit action rule, such as a unique contract-and-renewal-period reference. The objective is simple: receiving the same business event twice should not create two commercial processes. Test updates and re-enrollment behavior, not just initial record creation.
Sending too much product data into the CRM
Your sales team may need active users, recent adoption, and a risk flag. It probably does not need every click event represented as a separate record.
Keep detailed telemetry in the system designed for it. Bring in the summaries required for human decisions and automation, with a timestamp showing when the summary was calculated.
How to Validate a Custom Object Setup Before Going Live
Create a test dataset that includes the awkward cases:
- One company with multiple contracts and renewal dates.
- One contract covering several workspaces.
- A shared administrator across environments.
- A cancellation followed by reactivation.
- A duplicate source update and a delayed update.
- A record missing its expected association.
For each case, write the expected result before testing. Northstar’s three workspaces should still produce $60,000 of agreement value. A repeated update should not create a second renewal opportunity.
Ask sales, customer success, and finance to complete their own tasks. Check whether users can find the right record, understand its status, and identify the next action. Test with normal permissions, because administrator access can hide usability problems.
Finally, assign an owner for failed synchronizations and missing relationships. A data model remains useful only if someone notices when it stops reflecting the business.
Need help designing the structure? Talk to SAGE about connecting your commercial processes, product data, and customer lifecycle before expanding the build.
FAQs
Which HubSpot plan includes custom objects?
An eligible Enterprise subscription is required. HubSpot lists the qualifying products in its object documentation. Having Professional alone does not provide this capability. Before purchasing an upgrade, confirm both object access and the separate reporting, workflow, and integration capabilities your proposed design requires.
How many custom objects can you create in HubSpot?
Limits vary by product. The current catalog lists 10 definitions for several Enterprise products and 20 for Data Hub Enterprise; record limits also differ. Additional capacity is available. Confirm your account’s entitlement, particularly when combining products, rather than assuming their limits add together automatically.
Can custom objects trigger HubSpot workflows?
Yes. HubSpot supports object-based workflows for these records with the relevant Enterprise access. Your setup can use record conditions to initiate supported actions. Design enrollment, re-enrollment, and exclusions together, and verify that actions involving associated contacts or companies affect the intended records.
How do custom objects differ from custom properties in HubSpot?
A custom property stores an attribute on a record. A custom object defines a separate type of record. “Workspace region” is an attribute; a workspace has its own identity. When a customer can have several instances with different owners, dates, or relationships, a separate record structure is usually worth evaluating.
Can custom objects be deleted after going live?
Yes, but deleting an object is a structural change with consequences for dependent tools. HubSpot requires removing references that prevent deletion. Before proceeding, export needed information, review integrations and automation, and plan how users will access retained history. Retiring a structure gradually may be safer than removing it immediately.
