The definition
A CRM data model is the set of record types a system stores and the relations between them. Pipedrive keeps it small on purpose. An organisation is a company. A person is a human, normally linked to one organisation. A deal is a potential sale, linked to one organisation and usually to one person. An activity is something you do or plan to do, linked to a deal, a person or an organisation. A lead sits in front of all of it.
The relations run one way. An organisation has many people. An organisation has many deals. A deal has one organisation. A deal has many activities. That single arrow, deal to organisation, is the backbone of every report you will build. It is why revenue can be totalled by customer, by country and by industry without anyone writing a formula. A lead converts into person, organisation and deal in one action, then leaves the picture.
Why it matters
Take a company selling maintenance contracts. They store the customer name in a text field on the deal, because it was quicker during setup. Six months later, 900 deals carry 340 spellings of 180 customers. Nobody can answer what a single customer is worth. The fix is a rebuild of nine hundred records by hand. That is a two week job created by one modelling shortcut taken on day three.
The second reason is that the model decides what you can automate. Automations trigger on a record and read its related records. If the country lives on the organisation, every deal for that customer can be routed by it. If it lives in a note, nothing can read it. The same is true for reporting, which is why dashboards and reporting gets easy or impossible long before anyone opens Insights.
How to set it up in Pipedrive
Start with one decision: what does a single deal represent? One sale, one project, one contract year, or one renewal. Write the answer in a sentence and hold it. Everything else follows. A team that sells projects and renewals usually needs two pipelines with different stages, and the shape of both is covered in pipeline design.
Then place each piece of information on the record it truly belongs to. Industry, country and company size go on the organisation. Job title and consent go on the person. Value, source, close date and product go on the deal. The rule is simple. If the value would be the same for every deal at that customer, it belongs on the organisation. Build those fields deliberately, using custom fields, and keep the required list short. Where the model reaches outside Pipedrive, for invoicing or delivery, the connection runs through API tokens and webhooks. Those read exactly these records and nothing else.
Where teams get it wrong
The most expensive mistake is flattening the model during an import. Spreadsheets have one row per sale, with the company name repeated in a column. Import that without mapping, and you get thousands of duplicate organisations. The mapping work is the whole job, and it is set out in migrating from spreadsheets. Clean the source first, because deduplicating inside a live CRM is far slower.
The second mistake is putting structured data in free text. A note saying renewal due March is invisible to every filter and every automation. The third is one deal for a customer relationship that never closes. A deal must end, or your pipeline fills with immortal records that break win rate and forecast alike. The fourth is duplicating fields across levels, so industry sits on both the deal and the organisation. Two versions of one fact will disagree within a month, and no report can then be trusted.
Questions
Does a deal need an organisation, or is a person enough?
For business selling, always attach the organisation. Reporting by customer, by industry and by region all hang off that record, and a person changes jobs while the company stays. Link the person too, because that is who you email. A deal with only a person is invisible in every account level report.
When should I add a custom object instead of a field?
Pipedrive has no custom objects, so the question becomes where to put the thing. If it has its own lifecycle and its own dates, model it as a deal in a second pipeline. If it only describes an existing record, make it a field. Trying to fake an object with fields creates work forever.
How do leads relate to the rest of the model?
A lead is a holding area in front of the model. It carries a person and optionally an organisation, but no stage and no forecast. When it converts, Pipedrive creates or links the person, the organisation and a deal in one step. Nothing before conversion should appear in pipeline reporting.
Can one deal belong to two organisations?
No, and that limit is deliberate. One deal has one organisation, so revenue is never counted twice. When a partner or reseller is involved, record them in a separate field on the deal, or as a linked participant. Keep the organisation field for the party that receives the invoice.