Study guide
1.3 Core CRM Standard Objects & Capabilities
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
1.3 Core CRM Standard Objects & Capabilities
Key Takeaways Explain This Topic AI
Standard CRM objects provide rich built-in business logic, automated activity tracking, Chatter collaboration, and integration hooks that custom objects cannot fully replicate without extensive custom development.
Person Accounts unify Account and Contact capabilities to model individual B2C consumers; enabling Person Accounts is permanent and irreversible in a Salesforce org.
The Lead conversion process natively transforms an unqualified prospect into an Account, a Contact, and optionally an Opportunity, leveraging custom Lead Field Mappings to transfer qualification data.
Standard relationship behaviors include cascading deletions, where deleting an Account deletes related Contacts and Opportunities, and Case rules that automate assignment, auto-responses, and SLA escalations.
Last updated: October 2026
Core CRM Standard Objects & Capabilities
Salesforce delivers a comprehensive suite of pre-built, out-of-the-box standard objects designed to support the complete customer relationship lifecycle—from initial marketing campaign generation and lead qualification to sales pipeline closure and ongoing customer support service.
A common architectural anti-pattern among novice app builders is creating custom objects to satisfy requirements that standard CRM objects already fulfill natively. Standard objects come pre-wired with complex business logic, standard controllers, mobile-optimized layouts, Chatter feeds, activity timelines, and seamless integrations across Sales Cloud and Service Cloud. Replicating this functionality with custom objects requires substantial development, maintenance overhead, and custom code.
Accounts: The Foundation of the Data Model
The Account object represents an organization, company, or individual customer and serves as the primary anchor for nearly all transactional records in Salesforce. Accounts operate under two distinct architectural models:
1. Business Accounts (B2B)
Used for business-to-business models where customers are corporate entities, companies, educational institutions, or non-profits.
Relates to multiple Contact records through standard 1-to-many relationships.
Supports Account Hierarchies (parent-child relationships) to model corporate structures and conglomerate subsidiaries.
Enables Account Teams to manage collaborative access permissions across sales, support, and billing personnel.
2. Person Accounts (B2C)
Used for business-to-consumer models where customers are individual consumers, patients, bank clients, or students.
Synthesizes the Account and Contact objects into a single unified record interface.
Architectural Underpinnings: Behind the scenes, Salesforce creates both an Account record and a Contact record linked together. Storage usage reflects this dual nature, consuming 4 KB per record (2 KB Account + 2 KB Contact) rather than standard 2 KB.
Irreversible Activation: Once Person Accounts are enabled in an organization, the feature cannot be disabled or turned off . App builders must thoroughly vet this decision in a sandbox prior to production enablement.
Person Accounts can also relate to Business Accounts as Contacts via the "Contacts to Multiple Accounts" feature.
Contacts & Advanced Relationship Models
Contacts represent individual persons associated with an Account. Key architectural capabilities include:
Standard Relationship: A Contact can have a primary Account; a Contact without an Account is a private contact with special visibility rules. In standard configurations, deleting the parent Account cascades to delete associated Contacts.
Contacts to Multiple Accounts: Allows a single Contact to be related to multiple Business Accounts without creating duplicate Contact records. The system utilizes the standard AccountContactRelation junction object to distinguish between the Direct Account (the primary employer) and Indirect Accounts (advisory roles, board memberships, client engagements).
Contact Roles: Enables associating Contacts with specific functional responsibilities on transactional records—specifically Opportunities , Cases , and Contracts . For example, on an Opportunity, Contact Roles designate individuals as "Decision Maker", "Economic Buyer", "Influencer", or "Technical Evaluator".
Leads & The Lead Conversion Lifecycle
The Lead object serves as an isolated staging area for unqualified prospect inquiries. Keeping raw prospects in the Lead object prevents dirty, unverified data from polluting the core Account and Contact database.
Lead Conversion Mechanics
When a sales representative qualifies a Lead, executing the native Convert action performs a multi-object transaction that creates or updates up to three distinct records:
Account (Mandatory): The system searches for an existing Account based on company name or allows creating a new Account.
Contact (Mandatory): The system searches for an existing Contact based on email/name or creates a new Contact under the selected Account.
Opportunity (Optional): Creates a new Opportunity to begin pipeline tracking, OR the user can check the standard checkbox: "Do not create a new Opportunity upon conversion" if no immediate revenue transaction exists.
Custom Lead Field Mapping
Standard Lead fields automatically transfer to standard Account, Contact, and Opportunity fields upon conversion. However, custom Lead fields require explicit configuration:
Navigate to Object Manager > Lead > Fields & Relationships > Map Lead Fields .
Each custom Lead field can be mapped to one custom Account field, one custom Contact field, and/or one custom Opportunity field.
Data Type Alignment: Mapped fields must share compatible data types (e.g., Text to Text, Picklist to Picklist, Number to Number). Mismatched data types will fail to map.
Important
Converted Lead Immutability: Once converted, the Lead record has its IsConverted system flag set to TRUE and is populated with ConvertedAccountId , ConvertedContactId , and ConvertedOpportunityId . Converted Leads become read-only and disappear from standard Lead list views and searches, unless the user possesses the specialized "View and Edit Converted Leads" permission.
Opportunities & Pipeline Architecture
Opportunities track revenue-generating transactions, potential deals, and sales negotiations:
Stage, Probability & Amount: As an Opportunity moves through its defined Stages (e.g., Prospecting, Qualification, Proposal, Closed Won), Salesforce automatically updates the Probability % and calculates the expected revenue ( Amount * Probability ).
Forecast Categories: Every Stage maps to a Forecast Category: Pipeline , Best Case , Commit , Closed , or Omitted . These categories feed sales executive forecasting reports.
Sales Path: A visual banner displayed at the top of the Opportunity record in Lightning Experience, guiding sales reps through the sales stages with highlighted key fields and customized "Guidance for Success" coaching tips.
Opportunity Products (Line Items): When a deal involves multiple specific products, enabling Opportunity Products ( OpportunityLineItem ) links items from a Price Book ( Pricebook2 and Product2 ) to represent granular quantities, list prices, and total amounts.
Cases & Service Cloud Automation
Cases represent customer service issues, support inquiries, customer feedback, or defect reports:
Support Queues: Prioritize and distribute work among collaborative groups of support agents rather than assigning cases to individual users.
Case Assignment Rules: Automatically evaluate incoming cases (from Web-to-Case, Email-to-Case, or API) against sequential criteria to route the case to the appropriate queue or support specialist.
Auto-Response Rules: Automatically send a personalized, branded email receipt to the customer upon case creation based on criteria (e.g., language, tier, origin).
Case Escalation Rules: Monitor how long a case has remained open against defined Business Hours . If a case breaches an SLA threshold without being resolved, the escalation rule reassigns the case to a supervisor, elevates the priority, and dispatches automated notification emails.
Campaigns & Marketing ROI
Campaigns track outgoing marketing initiatives such as webinars, trade shows, email blasts, and digital advertisements:
Campaign Hierarchy: Organizes related marketing programs into parent-child structures up to 5 levels deep, allowing aggregated reporting on total campaign cost, actual cost, responses, and pipeline generated.
Campaign Members: A standard junction object linking Leads and Contacts to Campaigns, tracking interaction status (e.g., Sent, Responded, Attended, No-Show).
Campaign Influence & ROI: Measures marketing effectiveness by attributing closed-won Opportunity revenue back to primary and secondary campaigns.
Standard Relationship Behaviors & Cascading Rules
Standard objects feature built-in relational behaviors that app builders must consider during data model design:
Standard Object Primary Business Role Standard Automation & Features Cascading & Relational Behaviors
Account Central entity for B2B companies or B2C consumers Account Hierarchy, Account Teams, Person Accounts Deleting an Account cascades to delete related Contacts and Opportunities
Contact Individual person associated with an Account Contacts to Multiple Accounts, Contact Roles Can have a primary Account; contacts without Accounts are private contacts
Lead Unqualified prospect quarantine Web-to-Lead, Lead Assignment, Auto-Response, Lead Conversion Converts into Account, Contact, and optional Opportunity; requires field mapping
Opportunity Revenue deal in active sales negotiation Sales Path, Stages, Forecast Categories, Price Books Child of Account; associated to Contacts via Opportunity Contact Roles
Case Customer service issue or support inquiry Case Queues, Assignment Rules, Auto-Response, Escalation Rules Child of Account and Contact; deletion removes related case comments
Campaign Marketing program or promotional event Campaign Hierarchy (5 levels), Campaign Members, ROI tracking Connects to Leads and Contacts via Campaign Member junction records
Warning
Cascading Delete Risks: Deleting an Account automatically cascades to delete related Contacts, Opportunities, and related activities, subject to Account deletion restrictions. In contrast, deleting a Contact does NOT delete the parent Account. App builders must educate users on this behavior to avoid unintended mass data loss.
Account Deletion Is Not an Unconditional Cascade
Check related records before deleting an Account. Salesforce blocks deletion in cases such as a related Case, missing Account Delete permission, insufficient ownership/hierarchy authority, and certain order/contact relationships. Related Contacts, Opportunities, activities, and other eligible records can be affected when deletion is allowed. Do not infer custom master-detail behavior solely from a standard object's lookup-shaped UI. Export or otherwise preserve the required data and verify both deletion and restore behavior in a sandbox.
Official Source Check
Checked October 19, 2026: Account deletion guidelines .