Models worth copying

The standard B2B triad (Account is the company, Contact is the person, Opportunity is the deal) plus the two junctions that make buying-committee and product reporting possible.

WhenEvery B2B org, day one. This is the load-bearing model every rollup, forecast, and routing rule reads; you decide it before you create a single custom field.

The model
1. 01Account (the company) with Contact hanging off it via Contact.AccountId (a lookup, not master-detail, so a contact can survive a reparent).
2. 02Opportunity linked to Account via Opportunity.AccountId (lookup, effectively required in the standard UI).
3. 03OpportunityContactRole junction (ContactId, OpportunityId, Role, IsPrimary) carries the many-to-many buying committee, one primary per opp.
4. 04OpportunityLineItem holds the products on the deal, each pointing at a PricebookEntry.
5. 05AccountContactRelation junction for contacts that touch more than one account, gated by the Contacts to Multiple Accounts org setting.
6. 06One grain per object: company facts on Account, person facts on Contact, deal facts on Opportunity, product facts on the line item.

A field stored off its true grain goes stale the moment the source updates, and recurring revenue that lives off the Opportunity object never reaches the CRO ARR number.

The Lead object as a pre-qualification staging area and the mapped conversion into Account, Contact, and (optionally) Opportunity, with dedupe enforced at the moment of conversion.

WhenAny org with a real pre-qualification stage (inbound MQLs, SDR-worked lists) where you do not want unqualified people polluting the Account and Contact tables. Skip the Lead object entirely if every inbound is already a known account.

The model
1. 01Lead holds the unqualified person plus Company as free text (not yet linked to an Account) and the source and routing fields.
2. 02A field mapping (Setup, Lead Custom Field Mapping) that carries Lead fields onto the Account/Contact/Opportunity on convert; every custom Lead field that must survive needs an explicit mapping.
3. 03Conversion writes IsConverted, ConvertedAccountId, ConvertedContactId, ConvertedOpportunityId, and ConvertedDate back onto the Lead, which is the audit trail.
4. 04Duplicate rules and matching rules (on email/domain) that fire on convert, so a Lead merges into the existing Account/Contact instead of spawning a second one.
5. 05A clear MQL-to-SAL definition governing when a Lead is allowed to convert, tied to routing.

Leads do not carry Opportunities or roll into the forecast, so a deal run on a Lead is invisible to pipeline reporting, and unmatched conversion is the single biggest source of duplicate accounts.

The catalog layer (Product2, Pricebook2, PricebookEntry, OpportunityLineItem) that makes the price book the single source of list price instead of a number a rep types.

WhenThe moment you sell more than a couple of SKUs, price by currency or region, or need line-level revenue reporting. This is the foundation the CPQ quote model and any billing integration sit on.

The model
1. 01Product2 is the master SKU (ProductCode, Family, IsActive); it holds no price of its own.
2. 02Pricebook2: one Standard Price Book plus optional custom price books per segment or region.
3. 03PricebookEntry is the junction (Product2, Pricebook2, UnitPrice, CurrencyIsoCode); a product needs a Standard Price Book entry before any custom-book entry, and one entry per currency in multi-currency orgs.
4. 04OpportunityLineItem references a PricebookEntry and carries Quantity, UnitPrice, and TotalPrice; the rep moves quantity and discount, never list.
5. 05List lives only on the PricebookEntry; discount and net are derived at the line, so what is our list price for this SKU has exactly one answer.

Once list price is editable at the line you lose the ability to report list, margin, or realized discount, and every downstream order and invoice inherits a number nobody governed.

The post-sale chain (Order and OrderItem, Contract, Asset) that records what the customer owns and generates renewal Opportunities from it, so recurring revenue has a home the forecast can see.

WhenAny subscription or recurring-revenue business, and the first time a renewal gets forgotten because it lived only in a spreadsheet or a rep calendar.

The model
1. 01Order and OrderItem capture the fulfilled, signed deal (Order references the Account and Contract; OrderItem references the PricebookEntry).
2. 02Contract (Account lookup, StartDate, ContractTerm, Status) is the term-and-obligation record the renewal date keys off.
3. 03Asset (Account, Contact, Product2 lookups, InstallDate, Status, Quantity) records what the customer actually owns; it supports a self-hierarchy via the standard Asset.ParentId field (with RootAssetId for the top) for bundles.
4. 04Renewal and amendment Opportunities generated from the Contract or Asset as an Opportunity Type Renewal, never as a separate custom object.
5. 05A rollup of active-Asset or Contract value to the Account for the current-ARR read.

The forecast sums Opportunities, so recurring revenue off that object is invisible, and an Asset base that does not reconcile to billing turns every renewal quote into a manual reconstruction. Managed CPQ packages add their own Subscription and Contract objects (for example SBQQ__Subscription__c); this model is the standard-object baseline.

The separation of ownership as a fact (OwnerId on the record) from territory as a rule (the assignment logic that decides the owner), plus the visibility layer that lets managers see their teams records.

WhenAny org past a handful of reps, and mandatory once you run segments, geos, or named-account books that must reassign cleanly when a rep leaves.

The model
1. 01OwnerId on Account, Lead, and Opportunity is the single ownership fact (a User on Account/Opportunity; Lead and Case owners can also be a Queue).
2. 02Enterprise Territory Management objects (Territory2Model, Territory2Type, Territory2, UserTerritory2Association, ObjectTerritory2Association) express territory as data and assign accounts by rule.
3. 03Role hierarchy plus sharing rules give managers rollup visibility without changing ownership.
4. 04Territory2 account-assignment rules or a routing tool (LeanData, or a record-triggered flow) set the owner deterministically from the territory rule, not by hand.
5. 05A reassignment path that rewrites OwnerId in a controlled, low-CPU way when books change.

Ownership stored in two places (a picklist and OwnerId) always diverges, and an unbounded owner-change cascade on a big account hierarchy fails the save and leaves the tree half-reassigned.

The self-referencing Account.ParentId tree plus an ultimate-parent rollup, so global accounts, subsidiaries, and franchises report as one entity without duplicating the account.

WhenEnterprise or multi-entity selling where one logical customer has many legal or regional accounts, and leadership wants ARR and pipeline rolled to the top of the tree.

The model
1. 01Account.ParentId (self-lookup) builds the parent-child tree; Salesforce renders it natively as View Hierarchy.
2. 02An Ultimate_Parent__c resolved by a scheduled job, Apex, or a rollup tool (a formula can only span a fixed number of parent hops, so it cannot resolve an arbitrary-depth tree), because ParentId only walks one level.
3. 03Rollups of ARR, open pipeline, and open cases up the hierarchy (via flow, Apex, or a rollup tool, since lookups do not roll up natively).
4. 04A single, enforced convention for which account is the parent (global HQ) versus which are children (regions, subsidiaries).
5. 05A guard against circular references (an account cannot be its own ancestor).

ParentId is a single hop, so multi-level rollups need a resolved ultimate-parent field, and a cascade that touches the entire subtree on one edit is the classic CPU-limit save failure on large enterprise trees.

The campaign and source model (LeadSource, Campaign, CampaignMember, Campaign Influence) that captures first touch immutably and multi-touch proportionally, so marketing can defend where pipeline came from.

WhenAny org where marketing owns a pipeline number and sales disputes it. Put it in before the first attribution argument, not after.

The model
1. 01LeadSource (standard picklist on Lead, Contact, and Opportunity) plus an Original_Lead_Source custom field that is write-once and never overwritten on later touches.
2. 02Campaign and CampaignMember junction (Campaign, Lead/Contact, Status) records every touch a person had.
3. 03Customizable Campaign Influence linking multiple Campaigns to one Opportunity with influence percentages, for the multi-touch view.
4. 04Primary Campaign Source on the Opportunity for the single first-touch credit.
5. 05UTM fields captured on the Lead at creation and mapped forward on conversion, so the source survives.

Attribution needs an immutable first-touch record to be defensible, and a source field that any process can rewrite (or that drops on conversion) means every attribution report is arguing over data the system already corrupted.

The polymorphic Task/Event model (WhoId to a person, WhatId to a record) plus auto-capture, so engagement rolls up to the right Account, Contact, and Opportunity instead of stranding on one object.

WhenAny org that scores engagement, coaches on activity, or reports last-touch. Get the WhoId and WhatId wiring right before you turn on a sales engagement tool that writes thousands of Tasks a day.

The model
1. 01Task and Event are the two Activity types (Activity itself is not directly queryable; you query Task/Event, or ActivityHistory and OpenActivity).
2. 02WhoId (polymorphic to Lead or Contact) and WhatId (polymorphic to Account, Opportunity, and other objects) place each activity against both a person and a record.
3. 03Sales-engagement tools (Groove, Salesloft, Outreach) write standard Task records from email and calendar; Einstein Activity Capture surfaces captured activity on the timeline but stores it off-platform, so those touches are not standard queryable Tasks and need EAC-specific reporting.
4. 04EmailMessage for email content, distinct from the Task that logs the touch.
5. 05Standard LastActivityDate on Account/Contact/Opportunity plus custom rollups (last inbound, activity count) for engagement scoring.

Engagement scoring and manager coaching read these rollups directly, and an activity attached to a person but not a deal (or captured manually and mostly missing) makes every engagement number understate reality.