Every relationship.
In the right place.

What is a CRM data model?

A CRM data model describes the types of information your CRM holds, the fields that describe them and the relationships between individual records. It gives the team a shared structure for questions such as: who works at this company, which opportunities involve them and what needs to happen next?

An object is a type of thing: a person, company, deal or task. A record is one instance, such as the company “North Studio”. A field stores a value on that record, such as its website or owner. A relationship links records, such as a deal belonging to a company. Keeping these ideas distinct makes configuration decisions easier to explain.

HubSpot’s documentation uses the related terms objects, records, properties and associations [1]. Other CRMs use different names and support different relationship rules. This guide explains the underlying design decisions. It does not assume your chosen product supports arbitrary custom objects, multiple links or every field type described here.

Give each kind of record one clear job

Start with the things people already talk about when they describe their work. A person is someone you communicate with. A company is an organisation. A deal represents a possible transaction or engagement. A task describes an action that someone needs to perform. Delivery may need a project, campaign or another supported record type after the opportunity is won.

Try writing one sentence that explains what belongs in each object. A deal might be “one potential engagement with its own value, stage and outcome”. That definition tells you why three possible engagements with one company should normally have three deal records. It also prevents a long-running client relationship from being represented as one deal that never closes.

Decide where ownership belongs. The company owner may manage the overall relationship while a deal owner is responsible for one opportunity. A task assignee performs a particular action. Those responsibilities can belong to the same person, but they are different concepts. A useful model lets the team understand which question each ownership field answers.

Avoid using one “status” field to describe everything. A company’s relationship status, a deal’s pipeline stage and a task’s completion state are not interchangeable. If a deal is lost, the company may still be an active client on another engagement. Putting the state on the right record preserves that distinction.

Define relationships and their limits

For every link, describe what the relationship means and how many records can participate. One company may have many deals. One deal may have one primary company. A contact may work with more than one organisation over time. These are business decisions before they become configuration options.

A one-to-many relationship connects one record to several others. A many-to-many relationship lets records on both sides have several connections. If your process needs the latter, verify the product supports it in the relevant interface, API and importer. A text field listing several names is not equivalent to a set of maintained links.

Sometimes the relationship itself needs information. A person might be a decision maker on one deal and an adviser on another. The role belongs to the person–deal relationship, rather than being a permanent property of the person. Depending on the CRM, association labels or an intermediate record may support this. If they are unavailable, document a simpler approach and its limitations.

Consider what happens when relationships change. If a contact moves company, should the previous deal still show the historical context? If an organisation is acquired, do you need separate legal entities or a parent relationship? Work through these questions with examples. Avoid rewriting old business history merely to make current records look tidy.

Choose field types that preserve meaning

Use the field type that matches the decision the information supports. A date allows date filtering; a number supports arithmetic; a controlled choice keeps categories consistent. Free text is valuable for narrative context, but using it for every value makes reporting and validation harder to reason about.

Define the meaning as well as the format. “Value” could mean a proposed fee, expected annual revenue or total contract value. Those numbers should not be combined until the team agrees the basis. Similarly, “Close date” might mean a forecast decision date or an actual signed date. Keeping those separate helps users interpret reports correctly.

Distinguish zero, false and unknown. A recorded budget of zero means something different from an empty budget field. An unchecked boolean can mean false in one system and an unanswered question in another. Make the intended behaviour explicit in the data dictionary and test how the chosen product stores, displays and exports it.

Be selective about required fields. Requiring an unknown budget when an enquiry first arrives can encourage invented values. Decide when information should become required in the workflow, if the product supports stage-based rules. Otherwise, use a visible review process. A required field is useful only when users can provide a meaningful value at that point.

Use identifiers to keep the model connected

A display name helps a person recognise a record. An identifier helps a system refer to the same record consistently. Two companies can share a similar name, and a company can change its name. Use the CRM’s stable record IDs when connecting records through an integration, rather than relying on a label remaining unique.

Preserve external identifiers during a migration. A source record ID provides a way to trace the original row, match an update and investigate a discrepancy. Keep a source-to-destination mapping where the platforms use different IDs. The mapping should identify the source system as well as the record, because two systems may use the same numeric ID for unrelated entries.

Email addresses and domains can be useful matching signals, but their behaviour needs a policy. People may share a mailbox or change addresses. Several organisational records may use the same domain. Decide which fields identify records, which merely suggest a match and who reviews ambiguity. Identity rules should be stable enough to survive a routine update.

In Meibo’s API, linked fields reference records in the same workspace and pipeline stages have stable IDs [2]. That is a product-specific contract. Check the developer documentation when designing an integration, and verify every linked object your workflow depends on.

Decide between a field, a view and an object

Use a field when you need another fact about an existing record. Use a view when the same records need to be filtered or arranged for a different task. Consider another object only when you are modelling a distinct thing with its own identity, lifecycle or relationships, and the product supports the required extension.

For example, “Client industry” is normally a field on a company. “Clients with renewals due” is a view over relevant records. A subscription may deserve its own record if a company can have several subscriptions with different dates, values and states. The distinction comes from the business meaning, not from wanting another tab in the sidebar.

Before creating a new object, check the reporting, permissions, import and integration implications. A product may let you define the object but restrict how it participates in other features. Write down the full workflow you expect the new type to support and verify it end to end.

Keep a short change record when the model evolves. Adding an optional field is different from changing what an existing field means. For a semantic change, decide how existing values will be interpreted, whether they need migration and which reports or automations use them. Tell the team what has changed before they encounter inconsistent results.

A worked model for a client-services business

Consider a fictional consultancy with a company called North Studio, two contacts and two opportunities. The first opportunity is a website project; the second is an ongoing advisory engagement. Each deal has its own amount, owner, stage and expected decision date. The company record holds shared relationship context rather than copying it into both opportunities.

Tasks link the next actions to the relevant work: send the website scope, confirm the advisory decision meeting and update the company’s billing contact. A completed scope task does not automatically mean the website deal is won. The model keeps activity, buying state and relationship context separate so a manager can ask precise questions.

Now test a change: the primary contact leaves North Studio. Decide how the new primary contact is chosen and how historical notes remain interpretable. Then test a second change: the advisory opportunity closes while the website project remains open. Reports should reflect each outcome without marking the entire company as won or lost.

These examples are useful because they force the model to express real distinctions. A diagram can look complete while still hiding an ambiguous owner or an overloaded status field. Ask a teammate to explain the records in their own words. If the explanation differs from the intended meaning, improve the definition before importing more data.

Validate the model against business questions

Write a small set of questions the system must answer. Which companies have open opportunities? Which opportunities lack a dated next action? Who owns the overall relationship? Which data can an external reviewer see? Create representative records and demonstrate the answers through the actual interface and reports.

Include incomplete and exceptional records. A company may arrive before you know its website. A contact may exist before they are attached to an opportunity. A deal may have no reliable amount yet. The model should represent uncertainty clearly instead of forcing people to invent values to continue.

Finally, use the data dictionary template to record the agreed names, types, meanings and validation rules. Assign an owner to each definition and review the dictionary when the workflow changes. This small resource helps new teammates enter consistent information and gives future integrations a clear contract.

Common questions.