Core data objects: the CRM data model and the buying group

Accounts, contacts, opportunities, leads and campaigns form the familiar CRM data model. Workflows, scores, reports and routing rules are built around those objects. Most operators inherited this model from platform design rather than choosing it, and it determines what the demand engine can see.

The model has a particular weakness for B2B buying. B2B purchase decisions are made by groups of people, and the standard object set represents organisations and individuals well while representing the deciding group far less consistently. The consequences are operational: same-account leads suppressed as noise, routing that fires on one person’s engagement while ten people weigh the deal, forecasts hanging off opportunities with a single contact attached.

The model is one of the system foundations of demand generation: its objects determine what the programme can record and act on. The buying group is the object most models still lack.

What the CRM data model is

A CRM data model is the set of standard entities a CRM uses to represent a market: accounts for organisations, contacts for individuals, opportunities for potential revenue, leads as a pre-qualification holding area, and campaigns as the engagement layer connecting marketing activity to the rest. Every score, route and report in the system operates on these objects.

This model is a convention inherited from CRM platform design. Documentation, training and implementation partners’ default builds reproduce it so widely that it can seem like the only way to structure customer data. The useful question for an operator is what it under-represents.

What each object is for

Here is the standard set.

The account represents the organisation and is the anchor for ownership, territory, hierarchy and firmographics. Almost everything else in the model hangs off it.

The contact represents an individual tied to an account. It carries job titles, roles and reachability, and it is usually where marketing permission lives.

The opportunity represents a potential revenue event. It carries stages, amounts, close dates and an owner, and the forecast is built on it. Sales typically owns this object.

The lead is a temporary bucket for a prospect whose account affiliation has not yet been confirmed, held apart from the main model until someone or something qualifies it. Lead-to-account matching is the bridge out of that bucket, the process that works out which organisation a lead belongs to, and it has to run before lead routing can send the record anywhere sensible.

The campaign is the engagement layer that connects marketing touches to the people and accounts they landed on, so that activity can later be joined to outcomes.

Those definitions cover organisations, individuals, revenue events and marketing activity. What they do not cover well is the group that makes the decision.

The buying group as a data object

A buying group, treated as a data object, is the set of contact records from one account grouped around a specific potential purchase, each carrying a role, with engagement and state tracked at group level rather than only on the individuals. It is the entity that decides a B2B purchase, and it is the newest and least consistently modelled of the core objects.

The argument for it has a specific origin. In 2017, SiriusDecisions (the B2B research firm since acquired by Forrester) rebuilt its widely adopted Demand Waterfall around what it called demand units: a buying group organised around a need that a solution can address. Its stated reason was that “demand units, not accounts, are usually the true targets” marketing and sales should have in mind. The prior, lead-centric waterfall dated to 2006; the 2017 revision moved the unit of demand from the individual inquiry to the group. Forrester sells advisory services around this framework, so read the positioning with that in mind, but the architectural point has held for nearly a decade.

As of July 2026, the platform documentation we reviewed does not show a universal, first-class buying-group object in the core sales data model. The documentation reviewed was the Salesforce Winter ’20 release notes covering the opportunity contact role, the Salesforce B2B Commerce documentation for the BuyerGroup objects, and HubSpot’s association-labels documentation.

The platforms have been adding group constructs for years, addressing the gap up to a point. Salesforce’s Winter ’20 release gave the opportunity contact role full Object Manager treatment, with custom fields, buttons and links, custom page layouts, validation rules and triggers, delivering the long-standing IdeaExchange request titled “Make Opportunity Contact Role a First Class Object”.

HubSpot supports association labels, which let a contact be labelled on its relationship to a deal (a contact labelled “Buyer” on a deal, in HubSpot’s own example) and used in segments, workflows and reports. This labels relationships rather than creating a group object.

Where group capability exists, deployed practice still tends to run through the opportunity object, contact-role conventions, custom objects and overlay tools rather than through a group used as the operating unit.

The practice literature points the same way. A July 2024 piece on Salesforce Ben, produced as branded content with LeanData (a routing vendor, so a party with an interest in the pattern), describes the buying-group motion as opportunity-centric: the opportunity object serves as the container holding multiple contacts from a group, and adopting the motion “often involves rearchitecting existing systems, like Salesforce”.

The strongest objection to all of this is that the CRM already has a group construct: opportunity contact roles. Forrester itself made that case. When Salesforce made the opportunity contact role customisable in Winter ’20, Forrester published a walkthrough showing its Demand Unit Waterfall could be set up with standard objects, and called the contact role “the most natural object to house buying group members”.

The objection is mainstream and deserves a straight answer on the mechanics. A contact role attaches to an opportunity, so it can only hold a group once an opportunity exists; the group that Forrester’s own method says you should detect from intent signals forms before any opportunity record does.

Contact roles carry no group-level state: there is no native home for the group’s stage, completeness or engagement rollup, only fields on individual role records. And role coverage in practice is often thin. Many opportunities carry a single primary contact regardless of how many people engaged, something the same Forrester walkthrough describes and most operators will recognise from their own pipeline.

How big is the group these objects need to hold? It depends on who measured it, when, and how. The figures, with their source and date:

The spread carries the design lesson: group size varies by deal, method and segment, so a buying-group object must hold variable membership rather than a fixed set of role slots.

Forrester has converted the idea into an operational method. Its six-step buying-group guidance, built on the B2B Revenue Waterfall, says to detect active buying groups from first, second and third-party intent signals, identify the members, and treat second and third leads from the same organisation as “reinforcing signals of buying intentions” rather than duplicates. The same guidance recommends moving revenue development work off the lead object and onto an object such as the opportunity, which can hold and measure touches against several individuals at once. Forrester’s e-book on the shift is titled “It Was Never About Leads”, which states the analyst position about as directly as it can be stated.

What would first-class status mean in practice? An object that groups contact records from one account around a potential purchase before any opportunity exists; a role on each membership; group-level state and an engagement rollup, so the system can report how complete and how active the group is. Something has to instantiate it: an intent-signal threshold, the first qualified lead from a new organisation, or manual creation by an operator who can see a deal forming. Membership then needs maintenance, because people join the decision late, change roles and leave; a group object with static membership decays into another list.

Until the platforms settle this, teams can represent the group in three ways.

1. 1
   Custom junction object: a purpose-built object linking several contact records to a potential purchase before any opportunity exists.
2. 2
   Contact-role proxy: disciplined use of opportunity contact roles, with custom fields for role and engagement, along the route Forrester described.
3. 3
   Overlay group: an ABM platform or routing tool maintains the group construct and syncs it down into CRM fields.

These are implementation patterns rather than vendor recommendations; they differ in how much group-level state they can hold and who maintains it.

A scope note: this argument is B2B throughout, because buying groups and opportunity objects are B2B constructs and the evidence above (Forrester, Challenger, Gartner, Wynter) is B2B research. B2C systems meet the same problem from the other direction: a household of individuals who share purchasing power, which some B2C data models represent as a household or decision-unit object. The design question is the same; the direction of approach differs.

The operational cost of individual-level records

The loss of buying-group evidence from an individual-level model is often misnamed as a deduplication problem. True deduplication, merging records for the same person, works. Buying-group evidence is destroyed by lead-to-account matching failures, and by suppression and routing rules that treat a second lead from the same organisation as redundant. “Account already has an open opportunity: disqualify.” “Existing contact at this account: recycle.” Rules like these were written to protect sales time, and they discard the very signal Forrester’s method treats as qualification evidence.

Scoring and routing carry the same assumption. A score fires on one person’s engagement, and a route sends one record to one owner, while the state of the deal lives at group level. A highly engaged individual can be a lone enthusiast with no committee behind them; a quietly engaged individual can be one member of a twelve-person group in late evaluation. Individual-level records cannot tell those situations apart, so effort follows the wrong signal in both directions.

Forecasting inherits the problem next. An opportunity carrying a single contact role reads the same as one carrying a mapped, active group, even though they represent different levels of risk. Measurement feels it last, because joining the group’s touches to a revenue outcome requires identity resolution across every object involved, the plumbing covered in measurement and identity.

Whichever objects the system uses, their data changes over time. Landbase, a data vendor aggregating third-party figures (2026, with no independent methodology of its own), puts B2B contact-data decay between 22.5% and 70.3% annually depending on industry and methodology. RevenueBase, a contact-data vendor tracking changes across its own records, measured 3.6% of business emails going stale in November 2024 alone, against a traditional monthly rate of 1.5 to 2.0%. Both are vendor figures, and they point the same way. Object design and record accuracy are separate problems; fixing one does not fix the other. The full treatment of decay and hygiene is in data truth and CRM hygiene.

Emerging objects: what has not settled

The acceptance layer of the lifecycle is moving too, and it has not settled. The Sales Accepted Lead (SAL) was built for the individual record: sales reviews one lead and accepts or rejects it. Some teams are now adopting a Sales Accepted Account (SAA), an emerging object where acceptance happens at account or group level instead. The case for it is coherent: if a group decides the deal, accepting an individual record accepts the wrong unit. The case against is equally practical: another lifecycle object adds definition and governance load, the market has not converged on what an SAA means, and renaming the acceptance point does not by itself improve qualification. Both cases remain live.

Behind the acceptance question sits a wider tension: whether qualification is a status stamped on a record or a state read from a group as it forms. That distinction shapes lifecycle thresholds and whether qualification is reassessed as evidence changes (see minimum viable lead and dynamically qualified lead). Every new object, including SAA, needs a written definition owned and agreed by the functions that use it (see sales and marketing alignment).

The model is only as good as what enters it

An object definition also needs admission criteria: what evidence must a record provide before the system creates the object or adds it as a member? An opportunity is only worth forecasting if it carried real evidence when it was created; a buying-group membership is only worth routing on if the contact behind it is a real, reachable person with a lawful basis for contact. Object design and admission control are the same decision, made in two places.

The capture process determines which records enter the model. Validation at the point of capture, checking each record for compliance, truth and value before it writes to the CRM, decides whether the accounts, contacts and group memberships downstream are true when they arrive. A contact that fails capture validation never writes to the CRM, never joins the buying group and never carries a role. Group membership is assembled only from contacts that passed the checks. The argument for validating at source rather than cleaning after ingestion is made in data truth and CRM hygiene.

Teams running account-based marketing usually feel the object gap first, because ABM assumes the group is the unit from day one. For everyone else the practical next step is an audit with three parts.

1. 1
   Check the object definitions: does every object in your instance, custom ones included, have a written purpose and an owner?
2. 2
   Check buying-group coverage: for your last twenty opportunities, how many contacts were attached, in what roles, and would the group have been visible before the opportunity existed?
3. 3
   Check the matching layer: trace recent same-account leads through your suppression and routing rules and see whether they surfaced as reinforcing signals or vanished as duplicates.

Where the audit traces problems back to what enters at capture, a validation layer such as the LeadScale Engine applies the checks agreed for each programme before records write to the CRM. Start with the audit; it tells you whether the weakness is the model, the matching or the intake, and each of those is a design decision you can then make deliberately.