Most CRM systems look deceptively simple from the front end: a list of names, some pipeline columns, maybe a dashboard with deal totals. What sits underneath is a structured relational data model where each record type has a defined role, specific fields, and explicit relationships to other records. Understanding that model matters whether you’re configuring a new CRM, migrating data from an old one, troubleshooting duplicate records, or evaluating which tool actually fits how your business tracks revenue. This article covers the standard CRM entity structure, how the main objects relate to each other, what field types are available, and where the model tends to break down in practice.
Table of Contents
Core CRM Objects and What They Represent
The CRM data model is built around a small set of primary entities. Each entity is a table in the underlying database, and most CRM vendors expose these as named objects or modules in their UI.
Contacts: The Person Record
Contacts represent individual people. In a B2B context, a contact is typically an employee at a company your team works with or sells to. Standard fields on a contact record include first name, last name, email, phone, job title, and a link to the company they belong to. Most CRMs also support logging communication history directly on the contact, so call notes, email threads, and meeting records accumulate in one place rather than scattering across inboxes.
The relationship between contacts and companies is one-to-many from the company side: one company can have many contacts. Each contact record holds a foreign key pointing to its parent company, which is why the UI shows a company name in the contact list even though the database stores only an ID. A contact without a linked company is technically possible in most systems but creates reporting gaps if your team operates with an account-based model.
Companies: The Organization Record
Companies (also called Accounts in Salesforce and several other tools) represent the organizations your business interacts with. A company record aggregates everything connected to that organization: all associated contacts, open and closed deals, logged activities, and support cases if your CRM includes a helpdesk module.
Company hierarchies are supported in more advanced CRM setups. A parent company can have subsidiary companies beneath it, each with their own contacts and deals. Roll-up logic at the parent level then aggregates pipeline value, activity counts, and revenue across the entire group. This matters for enterprise sales teams managing complex accounts with multiple business units.
Deals: The Revenue Record
Deals (called Opportunities in Salesforce) track individual sales opportunities. A deal record typically carries the deal name, associated company, primary contact, deal value, expected close date, and current pipeline stage. The stage field is a picklist tied to a specific pipeline, and moving a deal from one stage to another is the core mechanic behind pipeline management.
Each stage in a pipeline often has a probability percentage attached. That probability drives weighted deal value calculations: a deal worth $50,000 at a 40% probability stage contributes $20,000 to the weighted pipeline total. Teams use weighted totals for revenue forecasting rather than raw deal values, because summing everything at face value overstates what will actually close.
One deal can be associated with multiple contacts, and in some CRMs, multiple companies. The relationship between deals and contacts is many-to-many: a single deal might involve five stakeholders from the same company, or contacts from multiple companies in a partnership scenario. CRM systems handle this through a junction table linking deal IDs to contact IDs, with role fields sometimes added to describe who serves as the economic buyer, champion, or technical evaluator.
Leads: The Pre-Qualified Record
Leads exist in a separate part of the CRM data model. A lead represents a person who has expressed some interest but has not yet been linked to an account or an opportunity. The lead object often combines personal attributes (name, email, job title), company attributes (company name, size, industry), and some opportunity information (product interest, budget range, source) into a single flat record.
That flat structure is actually a design choice reflecting the uncertainty of early-stage prospects. Before qualification, you may not know which account the person belongs to or whether there is a real deal to be had. Once a lead is qualified, most CRMs run a conversion process that splits the lead into a contact, links it to a company record, and optionally creates a deal. After conversion, the original lead record is typically marked as converted and removed from active queues.
The key structural difference is that leads are unattached: by default, a lead record with a company field value of “Acme Corp” has no database link to an account record named “Acme Corp.” That disconnection is a frequent source of operational friction in account-based marketing workflows, where campaign attribution needs to trace back through both lead and contact records.
Activities: The Interaction Record
Activities log what your team has actually done with a contact or deal. The activity entity usually covers calls, meetings, emails, and notes. In data model terms, activities have a polymorphic relationship with other objects: a single activity can be linked to a contact, a deal, a company, or in some systems all three simultaneously.
Most platforms separate planned items (tasks and calendar events) from completed items (logged activities). A task has a due date and an owner. An event has a start time and end time. A logged activity is a record of something that already happened, with notes, a timestamp, and an outcome. All three often live under the same parent activity object in the schema, which is why custom fields added to the activity object apply consistently across task and event records.
CRM Field Types and How They Shape Data Quality
Every entity in the CRM model is composed of fields, and the type of each field determines what data can be stored and how it can be queried.
Text fields handle names, descriptions, and free-form notes. Short text fields cap at a few hundred characters and are searchable. Long text or multi-line fields store paragraphs but are often not filterable, which limits their usefulness in segmentation queries.
Picklists and dropdowns store a single value from a predefined list. A contact’s lifecycle stage, a deal’s pipeline stage, a company’s account type: all of these are typically picklist fields. Single-select picklists enforce consistency and make filtering reliable. Multi-select picklists allow more flexibility but can complicate reporting because a record can satisfy multiple values in the same field.
Date and date-time fields track time-sensitive events: deal close dates, last activity dates, creation timestamps. These are essential for pipeline aging reports and follow-up automation triggers.
Lookup fields store a reference to another record, usually represented as an ID with a display label. When a contact shows a company name, that company name is coming from a lookup field pointing to the company’s primary key in the database. Lookup fields enforce the relational structure of the CRM model.
Currency and number fields handle deal values, revenue figures, and quantity data. Currency fields often carry a currency code alongside the numeric value, which matters for multi-currency setups where deals are tracked in different denominations.
Calculated fields derive their value automatically from other fields. A weighted deal amount is the most common example: the system multiplies the deal value by the stage probability, or by an individual deal probability if one is set, and stores or displays the result without manual input.
Custom fields extend any of these base types and can be added to any standard object. The discipline is knowing when a custom field adds genuine analytical value versus when it adds noise that no one will filter on. Most CRM administrators recommend auditing custom fields periodically and removing ones that haven’t been populated in six months.
How Object Relationships Drive Pipeline Logic
The relationships between CRM objects are not just structural curiosities. They directly determine what your pipeline reports can show, how automation fires, and where data breaks down under edge cases.
The company-to-contact relationship is one-to-many. One company, many contacts. The contact-to-deal relationship is many-to-many: a contact can appear on multiple deals, and a deal can have multiple contacts. When a company has many deals, the system rolls up pipeline value at the account level by aggregating across all deals linked to contacts at that company.
Activity records attach to both contacts and deals. That attachment point is what makes a CRM timeline possible: you can view every email, call, and meeting related to a specific deal in chronological order, or pull the same history from the contact level. If activities only attached to contacts, you would lose deal-level context. If they only attached to deals, you would lose the person-level history.
Stage progressions on deals are technically just picklist value changes, but most CRMs trigger automation on stage transitions. Moving a deal from Proposal to Negotiation might fire a notification, create a task, or update a date field. The automation logic depends on that picklist relationship between the deal record and the pipeline configuration.
For teams running sales inside Jira, the object structure maps onto Jira’s own concepts. A deal can correspond to a Jira issue, a contact to a linked organization member, and pipeline stages to issue statuses or custom fields. Mria CRM takes this approach directly: it stores CRM entities as Jira-native structures using Atlassian Forge, so deal records, contact links, and pipeline stages live inside Jira’s data layer rather than in a separate external database. The key components of what a full CRM data model covers are explored in detail in [our CRM components overview.
Common Data Model Problems in Practice
A few structural problems appear repeatedly across CRM deployments, regardless of platform.
Duplicate Contact and Company Records
Duplicate records are the most common data quality failure. They happen when the same person is entered under two slightly different names, or when a lead is converted without checking whether a contact for that person already exists. The practical result is split activity histories: some calls logged under one record, some under another. Most CRMs offer deduplication tools, but they require field-level matching rules that someone has to configure and maintain.
Lead-to-Contact Conversion Gaps
The conversion from lead to contact is a breaking change in the data model. Data entered on the lead may not map cleanly to contact and company fields, especially if custom fields on the lead have no equivalent on the contact object. Many teams discover these gaps after running their first post-conversion report and noticing that lead source attribution disappears from contact records.
Many-to-Many Deal-Contact Relationships Not Maintained
Teams often assign a single primary contact to each deal and leave it at that. When the deal involves multiple stakeholders, the others go untracked. This shows up as blind spots in post-sale analysis: the team thinks they know who the decision-maker was, but the CRM has no record of the other three people who influenced the purchase.
Field Type Mismatch on Import
Data imports fail silently when source data doesn’t match target field types. Importing a numeric deal value into a text field stores the number as a string, which looks correct on screen but breaks currency calculations and sorting. Date values without consistent formatting land in date fields as errors or empty values. Reviewing field type mapping before any bulk import prevents downstream reporting problems.
Choosing a CRM Data Model That Fits Your Process
The standard CRM entity set (leads, contacts, companies, deals, activities) covers most B2B sales workflows. Where it breaks down is when your business operates with non-standard relationship structures: B2C where individuals are customers without company affiliations, partner sales where deals involve multiple organizations with different roles, or service businesses where revenue comes from ongoing relationships rather than discrete closed deals.
Before selecting a CRM, map your actual workflow against the platform’s data model. Identify which of your record types correspond to which CRM objects. Check whether the system’s relationship rules fit your data: can one deal belong to multiple companies? Can a contact appear without a parent account? Can you add custom objects if none of the standard ones match a record type you need?
The configuration cost of bending a CRM’s data model to fit an incompatible business process is real. A platform whose native structure aligns with your workflow will be faster to set up, easier to maintain, and far more reliable as a reporting source over time. The data model is not a feature buried in settings: it is the foundation that either makes your pipeline data trustworthy or quietly undermines it.
For a broader look at how sales pipelines connect to the data model in practice, our sales pipeline guide.
