CRM entities: Leads, Contacts, Accounts, and Opportunities

Most CRM confusion starts before anyone builds a workflow. A person, the company they work for, and a possible purchase are three different entities. Qualification is work your team performs around them. Teams often squeeze all four concepts into one status field, then wonder why handoffs, reporting, and automation disagree. This page gives you a plain-language way to map those things first. You can then choose Salesforce or HubSpot objects without letting a platform label become your business model.

Start with three entities and the work around them

Before opening a CRM settings page, name the thing you are trying to track.

Concept	Question it answers	Common CRM record
A person	Who are we talking to or about?	Contact; sometimes Lead
A company	Which organization does that person belong to or represent?	Account or Company
A transaction	What potential purchase, renewal, or expansion are we pursuing?	Opportunity or Deal
Qualification work	What work is happening to decide whether to pursue or route this relationship?	Lead, status, task, or workflow when the work needs its own owner, history, reporting, or automation

Those categories relate to one another, but they are not interchangeable. A person can change jobs without changing the history of an Opportunity. One Account can have several Contacts and several Opportunities. A sales rep can work a qualification task without that task becoming the person's permanent identity. Give the work its own record only when you need to track it as a durable business object.

That distinction makes reporting possible. It also stops a familiar failure: a team calls an Account "qualified" because one Contact booked a meeting, then later cannot explain which person, deal, or evidence caused the status to change.

Operating choice: Your entity model should describe the business you run. It is not a vote on which CRM object has the friendliest name.

How Leads, Contacts, Accounts, and Opportunities fit

Lead

Lead is the least portable word in this model. It can mean a prospect record, a qualification-work record, or a lifecycle label. Treat it as platform-specific until your team defines which one it means.

Whether you use a separate Lead record is an operating choice. Some teams keep every person as a Contact and use fields or work records to track qualification. Others hold incomplete prospects as Leads before creating or associating the durable person and company records. Either model can work when conversion, matching, reporting, and history are documented.

Contact

A Contact represents a person your business knows. That person might be a prospect, a champion, a buyer, a customer administrator, or a former employee. None of those roles should be inferred solely from the fact that the record is a Contact.

Use a separate lifecycle or relationship field to describe the business state you care about. A Contact is the person. "Sales qualified," "customer," and "left the company" are states or facts about that person, not replacements for their identity.

Account or Company

An Account or Company represents an organization, or sometimes an individual buying as a business. It answers a different question from the Contact record: what is the company-level relationship with this business?

That relationship can be active while one person leaves. It can also be a target before any known person is engaged. Keep the company relationship separate from person lifecycle, consent, employment, and deal progress so one update does not erase another useful fact.

Opportunity or Deal

An Opportunity or Deal represents a specific commercial transaction in progress. It might be a new purchase, a renewal, or an expansion. The stage should describe evidence about that transaction, not a generic feeling about the Account or the person attached to it.

One Account can have more than one transaction at once. A new-business Opportunity can close while an expansion Opportunity remains open. A closed deal also does not automatically settle the lifecycle of every Contact at the Account.

Platform facts: the labels do not line up perfectly

Salesforce and HubSpot both cover these business concepts. They store and connect them differently. That is why you should decide the business model before asking an admin to configure it.

Salesforce: a Lead can convert into the durable records

Platform fact: Salesforce describes a Lead as a prospect before qualification, a Contact as a person, an Account as a company or individual, and an Opportunity as a deal in progress. When a Salesforce user converts a Lead, Salesforce creates or associates an Account and Contact; creating an Opportunity is optional. The process can match existing records, and it does not guarantee duplicate prevention. See Salesforce's Lead conversion overview, conversion considerations, and Lead implementation guidance.

Operating choice: Decide what qualifies a Lead for conversion, what should happen when a match already exists, and how reports preserve the history you need. Do not assume a Lead conversion is the same event as a person becoming sales qualified. It may be. It may not be.

Platform fact: Salesforce Lead Status and Opportunity Stage are separate, configurable fields. A Lead's pre-sales status does not define the stage of a deal. Salesforce documents the distinction in its picklist guidance.

HubSpot: a Lead is a separate qualification-work record

Platform fact: HubSpot uses Contacts for people, Companies for businesses, and Deals for transactions. Its Lead is a separate sales object for qualification work associated with a Contact or Company. A Contact can have multiple Lead records. HubSpot documents those object roles in its object overview and Lead creation guide.

That is a meaningful difference from Salesforce. In HubSpot, creating a Lead does not mean converting a person record into a Contact. The person can already be a Contact while the Lead records a particular qualification effort.

Platform fact: HubSpot lifecycle stage applies to Contacts and Companies. Lead records have their own pipeline stages, and Deals have their own deal stages. HubSpot's lifecycle-stage documentation and pipeline documentation cover those separate controls.

Operating choice: Decide whether your team maintains lifecycle primarily on the person, the company, or both. Do not map HubSpot lifecycle stage, Lead Status, Lead pipeline stage, and Deal stage to one shared list just because the words sound related.

Object movement is not lifecycle progress

Object movement describes where a record is stored or how it is associated. Business lifecycle progress describes a change in the relationship. They can happen at the same time, but they answer different questions.

For example, Salesforce can convert a Lead and associate it with an existing Contact because the person already exists in your CRM. That is an identity and record-model event. It does not, by itself, prove the person has reached a new business stage.

The reverse is also true. A Contact can become more qualified, lose interest, move to a new employer, or become a customer without moving to a different object. In HubSpot, a new Lead record can capture a fresh qualification effort for an existing Contact without changing the Contact's identity.

GTMJosh's existing AI-context material uses "lifecycle migration" in the narrower sense of a reporting population moving between objects. That is a real problem for retrieval and reporting. Read when the population moves between objects and when a contact becomes a deal for that implementation issue. This page is the prerequisite: define what each record means before you decide how a system or an AI should follow it.

Worked example: Acme Manufacturing

Worked example: The GTM Lab is a fictional B2B software company selling to mid-market manufacturers. Acme Manufacturing is a target account. Priya Shah is a plant operations leader at Acme who downloads a guide and later asks for a product walkthrough. The company may eventually buy a new implementation, then add an expansion later.

Business fact	Record in the map	Why it is separate
Priya works at Acme	Person: Priya Shah	Her employment and consent can change without changing Acme's company relationship.
Acme is a target organization	Account or Company: Acme Manufacturing	It can have multiple people, transactions, and relationship states.
The team is evaluating an initial implementation	Opportunity or Deal: Acme initial implementation	This is one commercial transaction with its own evidence and stage.
A rep is qualifying Priya's interest in that implementation	Qualification work	In Salesforce, this may begin on a Lead before conversion. In HubSpot, it can be a Lead associated with Priya or Acme.
Acme later considers another location	Opportunity or Deal: Acme expansion	It is a second transaction, not a reason to overwrite the first deal or Priya's person lifecycle.

The model gives each team somewhere precise to put new information. Marketing can record Priya's consent. Sales can work the qualification record. Finance can report the initial Opportunity. Customer Success can maintain the company relationship after the purchase. None of those updates need to pretend they are the same state.

Build an entity map before building stages

Use this as the first section of your Business Truth Map: shared documentation for your entities, lifecycles, fields, ownership, and unresolved questions. Fill it out with the people who own Marketing, Sales, Customer Success, Operations, and reporting. Keep unknowns visible instead of filling them with a guess.

For each entity	Document this
Plain-language definition	What real-world thing does this record represent?
Business purpose	Which decision, handoff, or report needs it?
Creation rule	What event creates it, and who or what can create it?
Relationships	Which people, companies, transactions, and supporting records can connect to it?
Source of truth	Which system or process owns its identity and its important fields?
Movement rule	Can it convert, merge, associate, or be retired? What history must survive?
Separate dimensions	Which facts belong elsewhere, such as consent, employment, lifecycle, ownership, fit, or health?
Reporting question	What should this record contribute to a count, funnel, or revenue report?
Review owner	Who can approve a change to this definition?

Two checks catch most early mistakes:

• Can you explain why a person, their company, and their potential purchase are three records rather than three values on one record?
• Can a record move or be associated differently without silently changing a lifecycle stage, consent state, or revenue report?

If either answer is no, do the entity map before you build automation. The workflow will only make the ambiguity run faster.

How this feeds CRM AI

An AI connected to a CRM needs more than object names. It needs the meaning of the records, the relationships that affect a report, and the rules that keep it from substituting one object for another. The CRM AI context layer overview explains that broader problem. The wrong-answer diagnostic shows the failure mode when a reporting population moves across objects and the agent does not follow it.

Do the business definition work first. Then document the field-level meaning, authority, and freshness an AI needs in the context-layer rule schema. The implementation pages for Salesforce and HubSpot pick up from there.