iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A CRM can use three core records—Company, Contact, and Deal—to give teams a shared way to represent organizations, people, and revenue opportunities. This is a design proposal, not a universal CRM standard or a proven guarantee that data silos will disappear. It works only when the records, relationships, and reporting rules match how your business operates.
What is a CRM data model?
A CRM data model defines the kinds of records a system stores, the fields on those records, and how records relate. It also includes lifecycle and pipeline rules, activity history, identifiers, and governance—not just a list of object names. HubSpot’s overview describes these building blocks, including objects, properties, associations, pipelines and stages, activities, and unique IDs: HubSpot’s CRM data model explainer.
The three-object proposal discussed here recommends Company, Contact, and Deal as the core records. Its aim is to keep shared customer and revenue information legible across teams by assigning each concept a clear home. The original proposal explains its rationale, but the available material does not establish a measured reduction in silos or reporting effort: the three-object CRM model proposal.
Free tools Windows power users keep installed
One-click scans. No signup required.
What does each object represent?
Company: the organization
Use Company for the organization or account your business works with. Decide whether this means a legal entity, a parent account, a customer location, or another unit that matters to sales and service. If teams use different definitions, the same customer can still be fragmented even when they share an object name.
#1 Best Overall
Contact: the person
Use Contact for an individual associated with an organization. In this proposal, a person may be associated with one or more companies, which can accommodate people who change employers or work across organizations. The CRM must support the relationship you intend; some systems impose different cardinalities or represent associations differently.
Deal: the revenue opportunity
Use Deal for a discrete revenue opportunity. The proposal places pipeline stage and deal lifecycle on the Deal record. A renewal is represented as a deal type rather than automatically receiving a separate core object. This keeps opportunity-specific state with the opportunity, but only makes sense if your renewal process can be represented and reported that way.
How do the records connect?
The proposed links are Contact to Company, and Deal to Company and one or more Contacts. In database terms, these are associations: a Deal points to the organization involved and to the people participating in the opportunity. Explicit links make it easier to ask questions such as which opportunities belong to an account or which contacts are involved in a deal—provided the CRM supports those links and users maintain them consistently.
- Company → Contacts: identify the people associated with an organization, allowing for the possibility that a person has more than one company association.
- Company → Deals: connect opportunities to the organization they concern.
- Deal → Contacts: associate one or more people with an opportunity, rather than relying on a single contact field if several stakeholders matter.
Do not assume these links are universal CRM behavior. Zoho documents a Contacts-to-Deals many-to-one relationship through a field on Deals, while OnePageCRM describes a different entity structure with Contacts at the center. Check the product’s own rules before adopting a diagram: Zoho CRM’s data model documentation and OnePageCRM’s data model documentation.
Where should leads, stages, and activities live?
Lead status when there is no open deal
The proposal treats “lead” as a Contact state or context when no open Deal exists, rather than requiring a separate core Lead object. This can simplify the model if lead qualification is fundamentally a person-level status in your workflow. It is a poor fit if your qualification process needs its own record, ownership, history, or reporting independent of a Contact.
Pipeline stage on the Deal
Store opportunity stages and deal-specific lifecycle information on Deal so that the pipeline describes the progress of an opportunity, not the general status of a person or company. Define stage meanings and transitions clearly; otherwise, two teams can interpret the same stage differently while using the same field.
Activities and history
Calls, emails, meetings, tasks, and other interactions need a consistent attachment and history model. Decide whether an activity belongs to a Contact, Company, Deal, or more than one record, and verify how the CRM handles visibility, ownership, and reporting. An activity model can introduce its own complexity even when the core object count is small.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →When is a three-object model a good fit?
It is worth considering when your organization can describe its core customer and revenue work with organizations, people, and opportunities, and when a small number of shared concepts would help teams use consistent definitions. Fewer first-class objects can make ownership and reporting rules easier to explain—but only if the business process genuinely fits the records and links.
- Can one contact be related to multiple organizations, and does your CRM support that relationship?
- Can one deal involve several contacts, and can reports distinguish their roles?
- Do you serve consumers, households, partners, or service recipients whose relationships do not fit a simple organization-person-opportunity structure?
- Do activities need their own lifecycle, ownership, or reporting, rather than serving only as history attached to other records?
- Can the CRM enforce the relationships and cardinalities the model requires?
- Who defines unique identifiers, deduplication, field ownership, access, and changes to the model?
Business context matters: ServiceNow’s CRM data management documentation describes B2B, B2C, and B2B2C structures, illustrating why one relationship pattern cannot be assumed for every customer model: ServiceNow CRM data management.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should you compare CRM data models?
Compare the records and rules the platform actually supports—not just the number of objects in a diagram. HubSpot, for example, describes four standard objects: Contacts, Companies, Deals, and Tickets. That differs from the three-object proposal and shows why object counts are product-specific, not a universal definition of CRM design.
| What to compare | Questions to ask |
|---|---|
| Object responsibilities | Which concepts receive their own records? Are service cases, households, subscriptions, or leads separate objects? |
| Relationship cardinality | Can a contact relate to several companies? Can a deal link to multiple contacts? Can associations carry labels or roles? |
| Lifecycle and pipeline | Where do lead qualification, deal stages, renewals, and customer status live? |
| Activities and history | How are interactions associated, retained, owned, and made available to reports? |
| Platform support and extensibility | Does the CRM natively support the needed relationships, and can it be extended without making data harder to maintain? |
| Governance and reporting | Can teams agree on identifiers, field definitions, access, data quality, and the reports they need? |
Use the comparison to test whether a model supports real workflows. A compact schema is not inherently better if it forces teams to overload fields or lose distinctions they need for operations and reporting.
How to implement the model without creating new silos
- Map existing workflows. Identify how marketing, sales, and customer success currently represent people, organizations, opportunities, and interactions. Record where definitions differ.
- Write object definitions. Specify what qualifies as a Company, Contact, and Deal, including edge cases such as subsidiaries, shared contacts, and renewals.
- Specify associations. Document allowed links and cardinality, including whether a Contact can be linked to multiple Companies and whether a Deal can have multiple Contacts. Confirm the CRM can implement them.
- Assign lifecycle ownership. Define which record carries lead status, deal stage, renewal type, and customer status. Avoid placing the same meaning in multiple fields without a clear reason.
- Set activity and identifier rules. Decide how interactions attach to records, which identifiers are authoritative, and how duplicates are resolved.
- Validate reporting and governance. Test representative questions across teams, such as pipeline by Company or involved Contacts by Deal. Assign owners for field definitions, access, data quality, and future schema changes.
A model is useful when it gives teams shared, enforceable definitions and supports the questions they need to answer. If the CRM cannot represent the intended relationships—or the business needs entities the three records cannot express—extend the design rather than forcing the workflow into an unsuitable shape.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
