CRM record relationships
Contacts, companies, and deals: what is the difference?
Contacts, companies, and deals answer different business questions. A contact or company can be treated as a lead depending on how the business sells, but the deal is the specific opportunity moving through a decision. It should end as won, lost, approved for work, or another defined outcome. A deal is not truly closed just because a quote was sent; the customer has to agree to purchase or pay under the business's rule.
Record responsibility
Store a fact where it remains true
The best home for a field depends on what the fact describes.
Contact records describe people
A contact can hold a person's name, direct communication details, role, preferences, consent evidence, and history that belongs to that individual. A job title may change when the person changes roles, while a personal communication preference may remain attached to the person.
Do not create another contact merely because the same person requested a second quote. That fragments history and can create contradictory consent, ownership, and communication records.
Company records describe organizations
A company or account can hold the organization's legal or trading name, domain, industry, account owner, headquarters, commercial status, and other facts that apply across several people and opportunities.
Branches, franchises, departments, subsidiaries, and service locations need an explicit rule. They may deserve separate company, location, or custom records when they have different ownership, billing, contracts, operations, or reporting needs.
Deal records describe one revenue event
A deal or opportunity can hold the proposed work, value, currency, stage, expected close date, probability if the business uses it responsibly, products or services, competitors, outcome, and reason for closing.
Those facts should not overwrite the person or company record. One company can consider several projects at once, and a returning customer can create new opportunities without erasing the history of prior wins or losses.
Connections and roles
Associations preserve the real relationship
A link between records needs enough meaning for users and integrations to interpret it correctly.
Connect records instead of copying them
Associate the people involved with their organization and the relevant opportunity. When the platform supports relationship labels, distinguish roles such as decision maker, billing contact, site contact, influencer, or former employee rather than creating duplicate people.
Activities may need to appear on several related records, but that does not mean every note belongs everywhere. Sensitive or opportunity-specific information should stay within the access and context appropriate to it.
Do not assume every CRM permits the same shape
HubSpot documents associations between object records and supports labeled relationships. Salesforce supports account and contact relationships, including configurations for a person related to more than one account. Microsoft Dynamics documents its own account, contact, stakeholder, and opportunity rules.
Those differences matter during platform selection and migration. A model that depends on many-to-many relationships or several locations per account must be proven in the configured product rather than assumed from generic CRM language.
Opportunity creation
Not every lead should become a deal
A deal should begin when there is a revenue event worth tracking through a defined pipeline.
Set an evidence-based creation rule
The business might create a deal after fit is confirmed, a discovery meeting is accepted, a quote is requested, or another observable threshold is met. The right rule depends on the sales motion and reporting need.
Creating a deal for every form submission inflates pipeline and forces spam, support requests, vendors, applicants, and unqualified inquiries into sales stages where they do not belong.
Preserve each opportunity's own outcome
Close a deal with the decision that actually occurred: won, lost, approved for work, disqualified, or another outcome the business has defined. A confirmed close requires evidence such as the customer's agreement to purchase, accepted authorization, or payment under the company's sales process.
Do not rename and reuse that record for the next project. New work creates a new revenue event associated with the existing person and organization, preserving stage history, cycle time, value, attribution, and the real reasons opportunities were won or lost.
Business-model fit
Consumer and noncommercial models may need different records
Contacts, companies, and deals are a common pattern, not a universal commandment.
Model the relationship the business actually serves
A household service company may need people, households, properties, service locations, jobs, and estimates. A nonprofit may need constituents, households, organizations, programs, donations, and grants. A membership organization may center enrollment or subscriptions rather than a sales opportunity.
Use standard objects when their meanings fit and the platform supports the required relationships. Add custom objects only when a distinct identity or lifecycle cannot be represented clearly through the existing model.
Practical review
Test identity and relationships before importing
A clean diagram is not enough if real cases collapse or duplicate in the system.
Draw difficult real cases
Use representative examples: one person working for two organizations, one company with several branches, several people involved in one deal, one person with several open deals, a person who changes employers, a consumer household with two decision makers, and a returning customer with closed history.
For every fact, ask which record owns it, which relationships are required, who may edit it, and what should remain after one relationship ends.
Define identity and merge safety
Email addresses and company domains can help match records, but neither is a universal identity key. People share inboxes, change addresses, use several emails, and work for organizations with multiple or shared domains.
Set candidate-match rules, require review for ambiguous merges, preserve source identifiers, and test what the platform does to associations, activity, consent, ownership, and integration references when records merge or separate.
Common questions
What business owners usually want to know.
Can one contact be associated with more than one company?
Sometimes. The business relationship may require it, but CRM products and configurations differ. Verify whether the chosen platform supports multiple company relationships, labels, primary associations, reporting, and integrations in the way the business needs.
Should every new lead create a deal?
No. Create a deal when the inquiry reaches the business's defined threshold for a trackable revenue opportunity. Spam, vendors, applicants, support requests, and unqualified inquiries should not inflate the sales pipeline.
Where should a service address be stored?
It depends on whether the address belongs to the person, organization, property, job, or particular opportunity. If customers can have several service locations over time, a dedicated location or property record may be clearer than one overwritten address field.
Is email address a safe unique identifier for every contact?
No. Email is useful matching evidence, but addresses can be shared, changed, duplicated, or absent. Preserve platform and source identifiers and require review when a merge is ambiguous.
Research
Sources and further reading
Reviewed 2026-08-24. Use these references to check the details and continue your own research.
Need help applying this to your business?
Tell us where the process breaks down today. We will ask the questions needed to find the cause and decide what is worth fixing first.