4.2 Core CRM Objects & Standard Schema

4.2 Core CRM Objects & Standard Schema

Quick Answer: Salesforce CRM is built on a standard schema centered on Account, Contact, Opportunity, Lead, Case, Campaign, and User. Developers extend these objects with custom fields, record types, and related custom objects—they rarely replace them. Knowing standard relationships and special behaviors is required for correct SOQL, automation, and app design.

Platform Developer I assumes you can read a business scenario and map it onto the standard data model before inventing custom objects. This section is the CRM map you will reuse across Apex, Flow, and UI work.

Why Standard CRM Objects Matter to Developers

Standard objects are not just “admin defaults.” They include:

• Documented API names used in Apex and SOQL (Account, Contact, Opportunity)
• Built-in relationships and child relationship names for subqueries
• Special platform behaviors (Lead conversion, Opportunity products, Case assignment, Campaign members)
• Standard UI and sharing patterns users already understand
• AppExchange and integration expectations that target CRM core

Recreating “Customer__c” and “Deal__c” as pure custom objects throws away conversion, forecasting, standard reports, and years of platform optimization—exam answers almost always prefer standard when the concept fits.

Account

Account represents an organization (or, with Person Accounts, a person acting as an account). It is the gravitational center of B2B CRM.

Common roles:

• Parent for Contacts, Opportunities, Cases, Contracts, and many custom children
• Hierarchy via ParentId (account family trees)
• Billing/shipping address fields and standard industry/type picklists

Developer notes:

• Many children lookup or master-detail to Account
• SOQL often filters AccountId on children or navigates Account.Name
• Account teams, territory features, and sharing can affect visibility in enterprise orgs

Contact

Contact is a person associated with an Account (in the classic model).

Characteristics:

• Typically requires or strongly associates to an Account (org settings and UI enforce patterns)
• Email, phone, name fields power activity history and marketing syncs
• Related to Cases, Opportunities (via Contact Roles), Campaigns (Campaign Members)

SOQL pattern: SELECT Name, Account.Name FROM Contact WHERE AccountId = :acctId

Contacts are people; Accounts are organizations—do not store company-level attributes only on Contact when Account is the right home.

Opportunity

Opportunity models a revenue deal in a sales process.

Key standard concepts:

• StageName, CloseDate, Amount, Probability, IsWon / IsClosed
• Relationship to Account (AccountId) and optional primary contact patterns via Opportunity Contact Roles
• OpportunityLineItem (products), price books, and schedules in product-selling orgs
• Record types and sales processes vary stages by business line

Developer notes:

• Stage changes drive forecasts and often automation (Flow/Apex on stage)
• Amount may roll from products depending on configuration
• Child relationship queries retrieve line items and contact roles

Exam scenarios about “pipeline,” “closed won,” or “products on a deal” map to Opportunity—not a random custom object—unless requirements clearly diverge from sales deals.

Lead

Lead is a pre-qualification prospect: a person/company not yet converted into Account, Contact, and optionally Opportunity.

Special behavior—Lead conversion:

• Converts to Account + Contact (+ optional Opportunity)
• Field mapping defines how Lead fields land on targets
• After conversion, the Lead is converted; ongoing work continues on Account/Contact/Opportunity

Developer implications:

• Do not build long-term transactional history only on Lead if the business process assumes conversion
• Apex and Flow often run on convert; tests must cover conversion paths when logic depends on it
• Duplicate rules and matching often focus on Lead + Contact + Account

If the “prospect” is already a customer account, you may create Contacts/Opportunities directly—Leads are for the pre-account journey.

Case

Case is the standard support/service ticket object.

Typical fields/relationships:

• AccountId, ContactId, Status, Priority, Origin, Subject
• Case comments, emails, and milestone/entitlement features in service orgs
• Assignment rules, escalation rules, and teams (declarative service features)

Developer notes:

• Cases often drive Omni-Channel and service automation
• Custom “Ticket__c” is a red flag when Case meets requirements
• Parent-child Case hierarchies exist for complex issues

Campaign

Campaign represents a marketing initiative; Campaign Member links Leads/Contacts to campaigns with status (sent, responded, etc.).

Why developers care:

• Influence and ROI reporting paths connect Campaigns to Opportunities
• Members are a junction-like pattern between Campaign and person objects
• Custom marketing models should extend Campaign when the concept is still a campaign

User

User is the identity record for people who log in (and some automated users).

Relevance:

• OwnerId on most records points to User or Queue (for supported objects)
• Hierarchical relationship on User models manager chains
• Profile, permission sets, role, and license on User drive security—not the focus of this section, but schema always joins to User for ownership

Never invent a parallel “Employee__c” solely to represent Salesforce users when User is the correct identity; use custom objects for HR person records that are not licenses when needed.

Common Relationship Map (Memorize)

Person Accounts (Awareness)

Person Accounts (when enabled) allow an Account to represent a person, blending Account and Contact behaviors for B2C-style models.

Developer awareness (exam-level):

• Not every org has Person Accounts; behavior and available fields differ when enabled
• Some standard assumptions about separate Account vs Contact records change
• Integrations and packages must detect and handle Person Account orgs carefully
• You do not need deep admin setup steps for PDI, but you must not design as if every person is always a Contact under a business Account in every org

Extend vs Replace Standard Objects

Anti-patterns:

• Customer__c + Person__c cloning Account/Contact
• Support_Ticket__c cloning Case without a strong reason
• Storing opportunities as tasks or free-text on Account

Schema Implications for SOQL

1. Use standard API names—Account, CloseDate, StageName, not labels.
2. Relationship navigation—Contact.Account.Name, Case.Contact.Email.
3. Child subqueries—use correct child relationship names (for example, Opportunities under Account, Contacts under Account—verify in schema, do not invent plurals blindly).
4. Polymorphic fields—OwnerId (User vs Queue), WhoId/WhatId on Task/Event require type-aware querying patterns.
5. Lead vs Contact—queries must target the object that actually holds the record at that lifecycle stage.
6. Selectivity—filter on indexed standard fields (Id, lookups, some status fields) for governor-friendly code.
7. Record types—filter or branch on RecordType.DeveloperName when processes diverge.

SELECT Id, Name, StageName, Account.Name,
  (SELECT Quantity, UnitPrice FROM OpportunityLineItems)
FROM Opportunity
WHERE IsClosed = false AND AccountId = :accountId

Practical Scenario Mapping

• “Qualify inbound interest before we create a customer record” → Lead, then convert.
• “Track a dollar deal with stages and close date” → Opportunity under Account.
• “Person at the company who receives support emails” → Contact.
• “Open service issue with priority and status” → Case.
• “Spring webinar and who responded” → Campaign + Campaign Member.
• “Custom warranty claim against a customer” → Custom object related to Account/Contact/Asset—not a new CRM core.

Internalize the standard schema so every later topic—sharing, SOQL, triggers, LWC data services—has a stable backbone. Custom objects extend the model; they should not casually replace it.