Most people use a CRM every day without really understanding how it’s structured underneath. That’s fine — until something breaks, reporting stops making sense, or the system becomes harder to use instead of easier.
You don’t need to be technical to use a CRM well. But you do need to understand a few foundational concepts so you can make good decisions, ask the right questions, and avoid unnecessary complexity.
This is a practical explanation of the core building blocks that make up most CRMs, including HubSpot.
Objects: The Buckets That Hold Information
At the highest level, a CRM is organised into objects. An object is simply a category of data.
Common standard objects include:
- Contacts
- Companies
- Deals
- Tickets
Each object represents a different type of thing your business interacts with. Contacts are people. Companies are organisations. Deals represent revenue opportunities. Tickets represent support issues.
Objects define what kind of information you can store and how it’s used.
Standard Objects vs Custom Objects
Standard objects are built into the CRM. They cover the most common business needs and come with default behaviour, reporting, and automation.
Custom objects are created when your business needs to track something that doesn’t fit neatly into the standard options.
Examples of when a custom object might make sense include:
- Tracking locations, assets, or subscriptions
- Managing applications or enrolments
- Recording events, tours, or inspections
- Supporting industry-specific workflows
Custom objects are powerful, but they add complexity. If a standard object can do the job with a few custom properties, that’s usually the better option.
More structure is not always better structure.
Records: Individual Items Inside an Object
A record is a single entry within an object.
For example:
- One contact is a record in the Contacts object
- One company is a record in the Companies object
- One deal is a record in the Deals object
Records hold all the information, activity, and history related to that specific person, company, or opportunity.
When someone says “open the record,” they mean “look at this one specific thing.”
Properties: The Fields That Store Information
Properties are the individual pieces of information stored on a record. Think of them as fields or attributes.
Examples include:
- First name
- Email address
- Deal stage
- Lead source
- Contract value
Properties define what you can track, filter by, automate around, and report on.
Poorly thought-out properties are one of the biggest causes of messy CRMs. Too many properties, unclear naming, or overlapping fields make systems hard to use and trust.
Good properties create clarity. Bad ones create noise.
Associations: How Records Are Connected
Associations define how records relate to each other.
For example:
- A contact is associated with a company
- A deal is associated with one or more contacts
- A ticket is associated with a customer
Associations allow you to see the full picture across objects instead of isolated data points.
Without associations, a CRM becomes a set of disconnected lists. With them, it becomes a system.
Association Labels: Adding Meaning to Relationships
Association labels add context to associations.
Instead of just saying two records are connected, labels explain how they’re connected.
For example:
- A contact might be labelled as a decision-maker or billing contact
- A company might be labelled as a parent or subsidiary
- A deal might be linked as a renewal or expansion
Labels are especially useful when multiple relationships exist between the same objects. They add clarity without creating new objects or properties.
Used well, they improve reporting and understanding. Used poorly, they can overcomplicate simple relationships.
How These Pieces Work Together
Objects define what you track.
Records represent individual items.
Properties store the details.
Associations connect everything.
Association labels add meaning to those connections.
When these pieces are designed intentionally, the CRM feels intuitive. When they’re added reactively, the system becomes harder to manage over time.
The Trade-Off to Always Keep in Mind
Every new object, property, or label adds capability — and responsibility.
Before adding anything, it’s worth asking:
- What problem does this solve?
- Will this improve clarity or add work?
- Who will maintain it?
- How will it affect reporting and automation?
CRMs work best when they stay as simple as possible for as long as possible.
You don’t need to know every CRM feature to use one well. But understanding these core building blocks helps you design systems that support how people actually work.
A good CRM isn’t the one with the most objects or properties. It’s the one that creates clarity, supports decisions, and gets out of the way.
Structure should serve the business — not the other way around.