ExamFinch.com My Study

Study guide

4.2 Core CRM Objects & Standard Schema

Practice this exam

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

4.2 Core CRM Objects & Standard Schema

Key Takeaways Explain This Topic AI

Core CRM objects—Account, Contact, Opportunity, Lead, Case, Campaign, User—ship with standard fields, relationships, and special platform behaviors

Common relationships include Account–Contact, Account/Contact–Opportunity, Lead conversion targets, Case to Account/Contact, and Campaign influence patterns

Person Accounts merge person and business account concepts when enabled; developers must know they change Account/Contact modeling

Prefer extending standard objects with fields, record types, and related customs over replacing CRM core with parallel custom objects

SOQL and Apex bind to standard API names and relationship names; knowing schema shape prevents incorrect joins and broken subqueries

Last updated: August 2026

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)

  • From To Pattern
  • Contact Account Lookup ( AccountId )
  • Opportunity Account Lookup ( AccountId )
  • Opportunity Contact Via Opportunity Contact Role (M:N style)
  • Case Account / Contact Lookups
  • Lead (none permanent) Converts into Account/Contact/Opportunity
  • Campaign Member Campaign + Lead/Contact Membership junction pattern
  • Most records User OwnerId
  • Account Account Hierarchy ParentId
  • 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

Approach When

Custom fields on standard Extra attributes on Account, Opportunity, Case, etc.

  • Record types / page layouts Different processes or UI on the same object
  • Related custom object New entity related to CRM core (Warranty_Claim__c → Asset/Account)

Replace with custom only Concept truly is not CRM standard (manufacturing run, IoT reading)—still relate to Account/Contact when the customer dimension exists

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

Use standard API names — Account , CloseDate , StageName , not labels.

Relationship navigation — Contact.Account.Name , Case.Contact.Email .

Child subqueries —use correct child relationship names (for example, Opportunities under Account, Contacts under Account—verify in schema, do not invent plurals blindly).

Polymorphic fields — OwnerId (User vs Queue), WhoId / WhatId on Task/Event require type-aware querying patterns.

Lead vs Contact —queries must target the object that actually holds the record at that lifecycle stage.

Selectivity —filter on indexed standard fields (Id, lookups, some status fields) for governor-friendly code.

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.