HubSpot CRM Data Model: Objects, Properties and Associations

#01What are the basic building blocks?

An object is a category of business information. A record is one instance of it. A property is a field on that record. An association links records so the system can understand their relationship. An activity records an interaction rather than replacing the person or company involved.

A contact can work at a company and participate in a deal. The company's industry belongs on the company record; the person's role belongs on the contact; the potential contract amount belongs on the deal. Copying every fact onto every object creates inconsistent versions that later require reconciliation.

HubSpot's association guidance describes two-way relationships and support for relationships within and across objects, with additional feature requirements where noted. Do not assume every label, association limit or advanced rule is included in every subscription.

Start with standard objects and properties. Custom objects or elaborate structures may be justified, but they require verified access and a clear reason. A more complex model is not inherently more mature. It can simply make every future report harder to build.

#02How do you decide where a fact belongs?

Ask what the fact describes and what changes independently. A person's newsletter preference is not a company characteristic. A company's headquarters location is not necessarily the contact's working location. A deal's product interest can change without changing the organisation's industry.

The workshop example deserves thought. One date property can describe the latest request but cannot preserve a full history of repeated attendance. If reporting needs history, use a supported event or record design rather than silently overwriting the only evidence.

Do not create fields before deciding how they will be used. A field that nobody maintains can mislead a workflow long after its original campaign ends.

#03What belongs in a property dictionary?

Record the display name, internal identifier where relevant, object, definition, field type, allowed values, owner, source, update rule and downstream uses. Include whether unknown is a valid state and whether the field contains personal or sensitive data.

Choose field types for decisions. A controlled selection is useful when segments depend on consistent categories. Free text is useful for nuance but harder to filter reliably. Dates and numbers should remain dates and numbers rather than strings containing explanatory words.

Avoid ambiguous options. "Large" is meaningless without a definition. "Interested" could mean opened an email, requested a demo or mentioned a future project. Write observable criteria and keep a genuine unknown state instead of forcing the operator to guess.

HubSpot provides default properties and custom-property tools across plans with additional restrictions for some features. Check the current field type and limit requirements before designing around calculated, restricted or otherwise advanced behaviour. No universal quota is assumed in this course.

#04How should associations be designed?

List the relationships needed for the business question. A deal may involve several contacts at one company. A contact may relate to multiple companies. The model should preserve relevant context without pretending the person's email domain always resolves every relationship.

Define which relationship a workflow or report should use. "Associated company" can be ambiguous when several exist. A label or primary relationship may help where supported, but it needs a maintenance rule and verified entitlement.

Test association-driven reports with records that have multiple relationships. One-to-many joins can multiply rows. A report that sums deal amount once per associated contact can overstate pipeline if the aggregation is wrong.

Do not use a free-text company name as a substitute for the actual company association when the process depends on company-level data. Equally, do not merge unrelated entities merely because their names look similar. Subsidiaries, franchises and shared domains require business judgement.

#05How do you control updates and ownership?

Assign an authoritative source for each important property. The website might collect a declared role; a data steward may verify company category; a sales owner may approve qualification. An enrichment tool can suggest values without becoming the final authority for every field.

Define overwrite behaviour. Can a form replace a sales-verified value? Can an import clear a field? Should an integration write only when the destination is blank? These decisions belong in the model, not in a late troubleshooting session.

Keep raw and approved values separate when necessary. A submitted company size and a verified company size may serve different purposes. Do not create both automatically; use them when the distinction changes a decision and someone owns reconciliation.

Audit downstream dependencies before renaming, replacing or deleting a property. Segments, forms, workflows and reports can all depend on it. An apparently harmless cleanup can break a live journey if nobody checks usage.

#06How should you test a proposed model?

Create a small synthetic set representing realistic edge cases: a person with no company, several people in one deal, one person linked to two companies, an existing customer making a new enquiry and a missing value. Write expected associations and outputs.

Build one segment and one report using those records. If the rules require complicated exceptions immediately, inspect the model before adding more fields. Sometimes complexity reflects a real business need; sometimes it exposes a poorly placed fact.

Review the model with sales and operations. Marketing should not define opportunity ownership or customer status in isolation. Agree the source and timing of those facts so a campaign does not overwrite commercial reality.

Use n8n CRM and HubSpot workflows as a companion for integration design, but define the model first. An automation platform can move inconsistent data faster; it cannot decide what the data should mean for you.

#07How should repeated requests be represented?

Decide whether a property describes the person now or preserves a past event. A single "latest requested offer" field can be useful operationally, but each update replaces its previous value. It should not be treated as a complete history of everything the person requested.

For repeated requests, choose an available supported event, activity or associated-record approach that preserves the needed detail. Do not assume custom objects are included in every plan. If a simpler account cannot support the ideal design, document the manual evidence and reporting limitation rather than inventing a feature.

Define which questions the model must answer later: the latest request, all requests, the first qualifying request or a request linked to a particular opportunity. These need different representations. Test a person making two requests while associated with two companies. If the design cannot identify the intended company or event, fix that ambiguity before building a report on top of it.

#08Worked example: Ledgerline

All records, amounts and competitor observations are fictional and illustrative. Ledgerline competes with Competitors A to D; no claims about their private CRM designs are made.

Ledgerline wants to report workshop requests and later opportunities. Competitor A uses broad educational offers, Competitor B demos, Competitor C partner events and Competitor D newsletters. Those visible activities do not reveal their underlying data models.

Walkthrough

1. Ledgerline places role on the contact, industry on the company and potential agreement amount on the deal. It does not duplicate deal value on every attendee.
2. The data steward defines a controlled process-challenge field with an unknown state and a source owner. Sensitive invoice details are excluded.
3. Synthetic tests include two contacts associated with one illustrative deal worth \$18,000. The report must count that amount once at the deal grain.
4. A contact linked to two companies exposes an ambiguous workflow rule. The team defines the relevant association rather than choosing whichever record appears first.
5. The import and form designs are checked against the dictionary. A self-declared role cannot overwrite a verified classification without the agreed rule.
6. Sales approves the qualification and opportunity definitions before the model supports campaign reporting.

The model is useful because it preserves meaning and relationships. Its value does not depend on how many custom fields the portal contains.

#09Common mistakes

Using one property for several meanings. Latest interest, lifetime engagement and active opportunity status are not the same fact.

Duplicating company information across contacts without ownership. Values drift and segments become inconsistent.

Assuming associations cannot affect totals. Test report grain and one-to-many relationships.

Adding advanced features before checking access. Core records do not imply every custom object or field behaviour is available.

#10Try it yourself

Choose one report the business needs. List its fields, object homes, associations and source owners. Write a property dictionary for the five most important fields, including unknown and overwrite behaviour.

Create synthetic edge cases and inspect the report manually. Ask whether two contacts on one deal multiply the amount, whether a missing company excludes a legitimate person and whether repeated requests overwrite history you need. Fix the model before importing a full dataset.

#11Quick quiz

1. Is a property the same as an association?

Answer: No. A property stores a fact; an association links records.

2. Where should one opportunity's amount usually live?

Answer: On the deal representing that opportunity, not duplicated as independent revenue on every contact.

3. Why define overwrite rules?

Answer: Forms, imports and integrations can otherwise replace trusted values inconsistently.

#12What should you check before the next lesson?

Confirm object homes, definitions, associations and owners. Preserve history where the reporting question requires it. Next, define lifecycle stages and handoff rules so marketing and sales use those records to describe the same commercial process.

Previous: HubSpot Setup for Marketers: Plans, Access and Governance · Next: HubSpot Lifecycle Stages and Marketing-to-Sales Handoff

Or return to the HubSpot for Marketers track.

Related: HubSpot Lifecycle Stages and Marketing-to-Sales Handoff · HubSpot Imports, Deduplication and CRM Data Hygiene · HubSpot Reports, Dashboards and Funnel Definitions

#13Common questions

Are contacts and companies interchangeable? No. They represent different entities. Use supported associations to describe relationships instead of copying every field between records.

Does an association prove which company a request concerns? Not automatically. Define the relationship and event context, especially for records associated with several organisations.

Can one latest-offer property preserve all request history? No. Replacing its value loses earlier detail unless another supported record or event structure preserves it.