What Is a CRM Data Model? Objects, Relationships and Setup

A CRM data model is the schema that defines which record types hold your customer information, which fields they carry and how they are linked to each other. Record types such as company, contact, deal, quote, activity and support ticket are the parts of that schema. When the model is set up well, "what did we last discuss with this customer, and which quote is still open?" is answered on one screen; when it is set up badly, sales and finance see different numbers for the same customer.

What does a CRM data model define?

Every CRM data model answers four questions:

• Objects: What do we record? Companies, contacts, deals, products, support tickets and so on.
• Fields: What information does each record hold? Tax number, industry, deal amount, close date and so on.
• Relationships: How are records connected? Which company does the contact work at, which company does the deal belong to?
• Rules: Which fields are required, can the same record be entered twice, who can see what?

Common platforms use the same logic under different names. Salesforce calls record types "objects", Microsoft Dataverse calls them "tables", and HubSpot calls the links between objects "associations". Whichever software you choose, the thinking behind it is the same, which is why you can design the model on paper before you choose the software.

What does "CRM data" mean?

CRM data is all the data that builds up in your CRM, and in practice it falls into three groups. Identity data tells you who is who: company name, contact name, contact details. Relationship data tells you who is connected to whom: this person is the buyer at that company, this dealer covers that region. Process and interaction data builds up over time: calls, emails, quotes, deal stages, support tickets.

Thinking about these three groups separately matters because each has a different life cycle. A company record lives for years, a deal closes in a few weeks, and a call log is created once and never changes.

Which objects do most businesses need?

In a typical B2B business, these objects form the core structure:

• Company (account): An organization you have a relationship with as a customer, dealer, supplier or competitor.
• Contact: A real person who works at a company or buys as an individual.
• Lead: A request that has not been qualified yet. Once qualified, it becomes a contact and a deal.
• Deal (opportunity): A potential sale with an amount, a stage and an expected close date.
• Quote and order: The documents in which the deal becomes concrete with product lines.
• Activity: Calls, meetings, emails, tasks.
• Support ticket: A post-sale issue or request.

HubSpot's documentation also lists contacts and companies as standard objects, with deals, tickets, products and quotes positioned around them. If your business has a concept of its own (a project, a contract, a serviced device), creating a custom object for it is healthier than squeezing it into the fields of an existing object.

How should relationships between objects be set up?

There are two basic types of relationship. In a one-to-many relationship, several records are linked to one record: a company has many deals. Microsoft's Dataverse documentation describes this as a 1:N relationship created with a lookup column added to the related table. In a many-to-many relationship, both sides can link to more than one record: one contact can work with several companies, and one company has several contacts. This relationship is resolved with a linking table in between (an "intersect table" in Dataverse).

In consulting, dealer-network and B2B businesses, many-to-many relationships are unavoidable. Tying a contact to a single company field means their history is lost when they change jobs.

Put role and time on the relationship

Roles such as "decision maker", "technical evaluator", "accounts" or "former employee" belong not to the person but to the relationship between the person and the company. The same person can be a decision maker at one company and an adviser at another. HubSpot solves this with association labels; in your own model, adding a role and start and end dates to the link record does the same job.

Decide deletion and reassignment behavior up front

When a company record is deleted, what happens to the deals linked to it? Dataverse lets you define this at relationship level: delete the related records too, remove the link, or prevent deletion while related records exist. In Salesforce, in a master-detail relationship, deleting the master record also deletes the detail records. Discovering this decision later means data loss that is hard to reverse. For most businesses, the safe default is to deactivate customer records rather than delete them.

How should process data flow inside the CRM?

Keep deal stages limited and defined: new, meeting, quote, negotiation, won, lost. Write down the entry condition for each stage; for example, moving to "quote" requires a quote record to exist. Make the loss reason a required drop-down for lost deals; three months later, the answer to "why are we losing?" comes from that field.

Link activities to both the contact and the related deal. A meeting note linked only to the contact does not appear in the deal report. For automatically logged emails, selecting the customer-related correspondence rather than storing everything keeps the model from bloating.

Which data quality rules do you need?

• Unique identifiers and deduplication: Duplicate checks on tax number for companies and on email or phone for contacts.
• Drop-down lists: Fixed options instead of free text for fields such as city, industry, source channel and loss reason. Otherwise "Istanbul", "istanbul" and "Ist." look like three separate segments.
• Few but meaningful required fields: Making every field required pushes users to enter "-" or "0".
• Field owners: It should be clear who updates each field.

Any CRM holding personal data of people in Turkey must also follow the principles in Article 4 of Turkey's Personal Data Protection Law No. 6698 (KVKK). They include keeping data accurate and, where necessary, up to date; processing it only in a way that is relevant, limited and proportionate to its purpose; and keeping it only as long as necessary. Check the data protection law that applies to your own customers as well. For the data model, the implication is simple: every field should have an answer to "why do we keep this?", and it should be defined when a record is archived or deleted.

The most common mistakes

The first mistake we see often is adding another field for every new need. A few years later, hundreds of half-empty fields pile up and nobody knows which one is current. We describe how this happens, and how to clean it up, in our article on CRM data model complexity.

The second is keeping the company and the contact in one record. When a second contact appears at the company, either the record gets duplicated or the information goes into a notes field; both break reporting.

The third is ignoring the ERP. If the company in the CRM and the customer account in the ERP are the same customer, the two systems need a shared key, such as a customer account code. If that key is not planned from the start, the integration stage ends up matching records by name similarity.

Where should you start designing a CRM data model?

1. Map your sales and support processes step by step: where requests come from, who handles them, which stages a quote goes through.
2. List the "things" in that flow; each one is a candidate object.
3. Draw the relationships between objects and note whether each is one-to-many or many-to-many.
4. For each object, decide which fields will really be used on day one; park the "might be useful" fields.
5. Test your two most critical processes (for example, sales deals and support tickets) with a small sample of real data.
6. Try to produce the three reports you need from that test data. If a report cannot be produced, the gap is in the model.

If you are planning a setup that handles CRM together with ERP, see our CRM and ERP solutions, or get in touch if you would like to design the model for your own process together.