CRM MVP
A CRM holds four separate things: the opportunity you are trying to win, the person you are dealing with, the organisation they work for, and the activity that moves the opportunity along. Each is its own record, and each can be linked to the others.
What the platform calls them does not matter. Deal, opportunity and pipeline item are the same thing, and this site uses opportunity throughout.
This is the difference between a CRM and a contact list. If the organisation is a text field on a person rather than a record of its own, you cannot see everything happening at that company, and you cannot run a second opportunity into an organisation you have already sold to.
If the activity is not a real object, nothing can be scheduled, assigned, reported on, or synced to a calendar. The relationship stops being a system and becomes a set of notes.
All four must exist as distinct records and be associable with one another. Association with an organisation must be possible, but is not required to be mandatory.
The person and the organisation must be genuinely separate objects. Two record types inside a single object is a failure, not a Partial. The test is the data model, not the interface: separate list views, separate add buttons and a company field on the person record are interface behaviour and do not satisfy it. What settles it is one endpoint family serving both with a type marker on the record, one custom-field target covering both, or an action that converts a person into an organisation in place - a record can only change type in place if type is an attribute of one object.
Partial where all four exist but one is constrained - a record type that cannot be created independently, or an activity that attaches only through an intermediary record rather than directly.
Fails if any of the four is absent, exists but cannot be linked to the others, or the person and organisation are two types of one object.
Naming is excluded. Deal, opportunity and pipeline item are treated as the same thing.
Act! exposes Contacts, Companies, Opportunities and Activities as separate first-class entities, listed as distinct resources in the vendor's own API documentation alongside Groups, History, Notes, Products and custom entities. Contacts link to companies, activities are scheduled against known contacts, and the custom tables documentation states that table entries are associated to Act! entities including contacts, companies, groups and opportunities, which is the vendor's own statement that those four are the linkable entity set. Direct documentation of the opportunity-to-company and opportunity-to-activity links themselves was not reachable.
The sales CRM carries four separate records: the deal, the contact, the account, and the task. A deal takes a primary contact plus secondary contacts, and the create-deal API exposes `account` as an optional parameter, so organisation association is possible but not compulsory - a deal created from an account record does not need a contact at all. Accounts hold their own fields, associated contacts, notes and deals, and a contact can belong to only one account. Tasks attach to contacts and to deals; vendor documentation does not describe attaching a task directly to an account.
The CRM apps hold Opportunities, Contacts, Customers and Leads as separate apps, and activities (call logs, tasks, events, follow ups, notes, emails, documents) are separate objects that attach to them. Vendor documentation describes everything in the system as an object, with an opportunity linking to a customer and to contacts, and an activity carrying an "Associated with" section that lets one activity be attached to several records at once and stay synchronised across them. Constraint to note: an opportunity can be associated with only one customer, and the creation guidance states that a customer is selected when an opportunity is created, so organisation association is presented as part of the standard flow rather than as optional.
Attio ships five standard objects - Companies, People, Deals, Users and Workspaces. Companies and People exist in every workspace; Deals is a standard object that an administrator enables rather than builds, and it arrives with a predefined attribute set rather than an empty schema. The deal record carries associated people and associated company record reference attributes, and only owner and stage are required, so company association is possible without being compulsory. Tasks are a separate entity with their own endpoints and a linked records array that accepts records of any object by record identifier, and manually logged meeting activities can be linked to records from any object type, giving a distinct activity construct associable with deals, people and companies.
Bigin's data is organised into modules: Pipelines, Contacts, Companies, Products, Activities and Dashboards. The pipeline record is the opportunity, and its default fields include Company Name and Related Contacts alongside Amount, Closing Date, Sub-Pipeline and Stage. A pipeline record carries one primary Contact Name plus a Secondary Contacts field for additional people. Activities are tasks, events and calls, and a task is created with a Related To selection covering contacts, companies and pipeline records. Company association on a pipeline record is a field rather than a requirement, and the vendor does not document it as mandatory.
Breakcold carries a People section, a Companies section, a Deal object and a Task object. A person is linked to an organisation through a Company field on the lead profile, which searches existing company records or creates one, and each company record exposes a People section listing the individuals attached to it. A deal is a tracked opportunity to which multiple people and companies can be added from the deal information page, and each deal is tracked independently with its own stage, value and notes. Companies are held as lead records flagged as companies rather than as a wholly separate entity, and vendor documentation describes tasks being linked to leads and to inbox conversations but does not describe attaching a task to a deal.
https://developer.breakcold.com/help/contacts-lists/what-is-a-company-in-breakcold
https://developer.breakcold.com/help/contacts-lists/how-to-add-a-lead-to-a-company
https://developer.breakcold.com/help/pipeline-deals/can-each-deal-have-its-own-stage-and-value
https://developer.breakcold.com/help/tasks-activities/are-tasks-linked-to-a-message
Capsule holds Opportunity, Party and Task as separate objects, but the person and the organisation are not separate objects: both are a Party, and a Party is typed either person or organisation. One endpoint family serves both, a person carries an organisation field linking it to another Party, and the reverse relationship is read through that Party's employees endpoint. Opportunity and Task associations are otherwise complete - an Opportunity carries a main contact plus additional parties, and a Task carries party, opportunity and project associations - and an opportunity can be linked to a person alone, so organisation association is possible rather than compulsory. The dimension nevertheless fails on the data model: the interface behaviour of separate views and separate add actions does not make two types of one object into two objects.
All four objects exist. The Lead is the organisation record - vendor documentation describes it as representing a company or organisation and as covering what other systems split into lead and account - and Contacts are the people at that company. Opportunities and Contacts are dependent children of a Lead, so organisation association is compulsory rather than optional, and an Opportunity carries a Contact field linking it to a named person. The constraint is on the activity side: vendor documentation states that activities belong to Leads and represent work done on a Lead or its Contacts, and there is no opportunity association on user-created activities. The only documented activity-to-opportunity link is the system-generated `opportunity_due` task, which the platform creates for an opportunity scheduled to close on a given date. Activity and opportunity are therefore related only through their shared Lead.
Copper carries separate Person, Company, Opportunity and Task record types, alongside Leads and Projects. The Opportunity entity exposes `company_id` and `primary_contact_id` association fields, and a task can be related to a lead, person, company or opportunity record. Records can also be linked through a Related section on each profile. Only `name` is required by the API when creating an opportunity, so company association is possible rather than compulsory, although the guidance for creating an opportunity in the interface describes a primary contact as a required field.
https://developer.copper.com/opportunities/create-a-new-opportunity.html
https://developer.copper.com/opportunities/fetch-an-opportunity-by-id.html
https://support.copper.com/en/articles/8823248-relating-records
https://support.copper.com/en/articles/8823266-working-with-tasks
https://support.copper.com/en/articles/8823260-working-with-opportunities
folk carries a genuine deal object, separate from contacts, with its own API resource and its own record: a deal is described as an object used to track opportunities or other outcome-driven items, and its native fields are name, people, companies, created at and created by. People and companies are separate first-class record types that exist independently of any group and can be referenced from anywhere, and people and companies can be linked to each other. A deal may be associated with one or more people and one or more companies, and neither association is required, so organisation association is possible but not compulsory. Two activity-type objects exist and are distinct from notes: tasks, which carry a title, description, due date, assignee and a linked record and can be attached to a person, a company or a deal; and interactions, which record calls, meetings and messages with a date and an activity type. One real constraint applies to association: a deal lives inside a group and can only reference people and companies that are in that same group, and interactions attach only to a person or a company, not to a deal.
Deals, Contacts and Accounts are separate record types. A deal is created with a "Related account" that the vendor documentation marks as optional ("if any") and one or more "Related contacts", so organisation association is possible rather than compulsory. Activities exist as Tasks and Appointments (Meetings), and a task is created against a due date, an owner and a searched "contact, account or deal" as its related record.
Deals, contacts, companies and activities (calls, meetings, tasks, notes, emails) are separate object types in the shared HubSpot CRM data model, and records of different object types can be associated with one another. Associating a company or contact to a deal is optional rather than mandatory at creation.
Insightly holds Opportunities, Contacts and Organisations as separate objects, and the linking model connects opportunities to contacts and organisations, and contacts to organisations. Activities exist as two objects: Tasks, which link to contacts, opportunities, organisations, projects and emails, and Events, which link to contacts, organisations, opportunities and projects.
Keap carries a contact record, a company record that vendor documentation states is independent of the contact record and holds its own fields, a deal that sits in a pipeline, and activity records in the form of tasks and appointments. Deals are created against one or more contacts and appear on the contact record through a deal card, and appointments are booked against a contact. No vendor documentation found describes associating a deal with a company record, or linking a task or appointment to a deal, so the organisation and the activity appear to reach the opportunity only through the contact.
The application runs on Microsoft Dataverse and ships separate Opportunity, Account, Contact and activity tables, with activities (task, phone call, appointment, email and others) linked to a parent record through the Regarding field so they roll up under the opportunity, account or contact. The opportunity carries a Customer lookup that targets either an account or a contact and is business required, so an opportunity must name a customer but that customer can be a person rather than an organisation; a separate Primary Contact lookup holds the individual on an account-based deal.
monday CRM ships five dedicated entity boards - Leads, Contacts, Accounts, Deals and Activities. Contacts carry an Account column that is a Connect Boards column pointing at the Accounts board, the contact item card shows all deals connected to that contact, and notes, activities, custom activities and emails are linked to CRM records through shared email or phone values, Connect Boards columns and mirror columns, with manual association available to set the links explicitly. Account association is a column on the contact, not a requirement, so an organisation link is possible rather than mandatory. Association is by connected board columns rather than by a fixed relational schema, so each link is a column a board owner has to keep in place.
Deals and activities are first-class records: a deal carries name, amount, probability, pipeline, stage, owner, expected and actual close dates and Related Contacts, and activities (tasks, events, calls and administrator-defined types) can be raised from a contact, a company or a deal. The organisation is not a separate object. Nimble's API states that a contact carries a record_type of either person or company, so a company is a record type inside the contacts object rather than a distinct entity - one store, one endpoint family, one custom-field target, with a type discriminator on the record. Nimble presents it as an organisation in the interface, with separate People and Companies views, distinct Add Person and Add Company actions and automatic matching of imported company names to contacts, but interface behaviour is not the test. A second constraint compounds it: the deal's association field is documented only as Related Contacts, and no vendor page states that a company record can be attached to a deal.
https://www.nimble.com/developers/docs/
https://support.nimble.com/en/articles/2166089-nimble-contacts-tab-overviews
https://support.nimble.com/en/articles/502860-nimble-csv-import-wizard
https://support.nimble.com/en/articles/6716398-using-deal-s-pipeline-and-lists
https://support.nimble.com/en/articles/2924022-create-custom-activity-types-in-nimble
Nutshell holds Companies, People, Leads and Activities as separate record types. A Lead is the opportunity object and can be attached to companies and to people; activities are scheduled with participants drawn from companies, people and leads, and can be created from a lead, person or company page. Creating a company or person requires only a name.
Pipedrive carries separate Deal, Person, Organisation and Activity objects. A deal exposes `person_id` and `org_id` association fields, and an activity can be linked to a deal, an organisation or a person, appearing on that item's detail page. A deal must be linked to at least one of a person, an organisation or a project, so organisation association is possible but not compulsory.
The system is a hierarchical database with Company at the top, Contact beneath it, and Opportunity beneath the Contact, with Problems and interactions such as notes, documents, emails and quotes logged under those records. Tasks are a separate object that can be set against a Company, Contact, Opportunity, Problem or Enquiry, and multiple tasks can be assigned to different users on different dates. Vendor documentation states an opportunity is not strictly required to sit under a Contact but that doing so is strongly advised, so association is possible rather than compulsory at that level; contacts, however, are created at a Company.
Salesforce ships Opportunity, Contact, Account and the two activity objects (Task and Event) as standard objects. Contacts attach to an opportunity through Opportunity Contact Roles, which also record the part each contact plays in the deal. Tasks and events relate to accounts, contacts, leads and opportunities and appear on the record's activity timeline. Note: Salesforce documents Account Name as a required field on the Opportunity, so association to an organisation is presented as mandatory rather than optional.
Streak carries a box as the opportunity object, and contacts and organisations as separate record types, each with its own page holding contact details and the team's interaction history. A contact is an individual identified by name or email address and an organisation is a company identified by its domain, and both are attached to a box through a Contacts and Organisations column, so a box can carry both at once and neither is compulsory. Contacts and organisations sharing a domain are surfaced against one another as related records. Activities exist as tasks, call logs and meeting notes held against the box rather than attached directly to a contact or organisation.
Vtiger holds Deals, Contacts, Organizations and Events as separate modules. A deal is defined by the vendor as a sales opportunity being pursued with a person or an organisation. An organisation record carries its own information plus its related contacts and its associated deals, and deleting an organisation breaks the link to its contacts and removes its related deals, which confirms both relationships are real. An event can be created from inside a deal record through the deal's Events tab, and carries a Related To field that keeps it attached to the deal.
Zoho CRM ships separate Deals, Contacts and Accounts modules, plus three activity modules - Tasks, Meetings and Calls. A deal carries Account Name and Contact Name fields; tasks and meetings carry Contacts/Leads and Accounts fields and a related-to link, and appear as related lists on the record they are linked to. The documented deal layout marks Account Name as mandatory, so an organisation association is compulsory on every deal rather than optional.