ExamFinch.com My Study

Study guide

3.1 Objects, Fields & Schema Design

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

3.1 Objects, Fields & Schema Design

Key Takeaways Explain This Topic AI

Standard objects ship with Salesforce; custom objects (API name ending in __c) store org-specific data and support full schema configuration

Field types, Required, Unique, and External ID attributes drive validation, integration matching, and upsert behavior

Record types segment picklists, page layouts, and business processes on the same object without duplicating schema

Schema Builder visualizes objects and relationships; Object Manager is the detailed configuration surface for fields, page layouts, and record types

Given requirements, prefer standard objects when they fit, then add custom fields or custom objects only when the standard model cannot represent the data

Last updated: August 2026

3.1 Objects, Fields & Schema Design

Quick Answer: Salesforce data models combine standard objects (Account, Contact, Opportunity, Case, and many others) with custom objects you create for org-specific data. You shape each object with field types and attributes (Required, Unique, External ID), optionally segment UI and picklists with record types , and validate the design in Schema Builder before coding against it.

Data modeling is a core Developer Fundamentals skill on Platform Developer I. The exam expects you to read a business scenario, pick the right objects and fields, and know what each design choice implies for UI, automation, and Apex—not just memorize Object Manager clicks.

Standard vs Custom Objects

Standard objects are platform-provided entities with built-in fields, relationships, and often special behavior (Lead conversion, Opportunity stages, Case assignment). Use them when the business concept maps to CRM or platform concepts Salesforce already models well.

Custom objects store data that has no suitable standard home. Their API names end in __c (for example, Invoice__c ). Custom objects get:

  • Custom fields, validation rules, and page layouts
  • Optional Allow Reports , Allow Activities , Track Field History , and Allow Search settings
  • Optional Enable History and Enable Feed Tracking for audit and Chatter-style collaboration
  • A standard Name field (text or auto-number) that appears in lookups and list views

Decision Prefer when

Standard object Concept matches Account, Contact, Opportunity, Case, Lead, Campaign, Product, etc.

  • Custom field on standard You need extra attributes on a standard entity
  • Custom object New entity with its own lifecycle, ownership, and relationships

Custom metadata / settings Configuration data (not transactional business records)—covered more in architecture discussions

Exam mindset: Do not invent a parallel “Customer__c” when Account already models customers. Extend standard first; create custom only when the entity is truly separate.

Field Types That Matter for Developers

Field type choices constrain SOQL, Apex types, validation, and integrations.

  • Field type Typical use Developer note
  • Text / Text Area / Long Text Area Names, notes Long Text Area is not filterable/sortable in all contexts
  • Number / Currency / Percent Quantities and money Currency respects multi-currency orgs
  • Checkbox Boolean flags Apex maps to Boolean; default often false
  • Date / DateTime Deadlines, timestamps Time zones affect DateTime display and comparison
  • Picklist / Multi-Select Picklist Controlled vocabularies Multi-select has limited formula/SOQL patterns
  • Lookup / Master-Detail Relationships Covered in depth in the next section
  • Formula Derived values Read-only; not writable via DML; limited in some filters
  • Roll-Up Summary Aggregates on master-detail parents Declarative aggregate; not available on pure lookups
  • Auto Number Sequential IDs Display format + starting number; not for external system keys alone
  • Email / Phone / URL Contact channels Client-side formatting and validation helpers
  • Geolocation Lat/long pairs Compound field patterns in API/Apex
  • Required, Unique, and External ID

These attributes appear constantly in exam scenarios:

Required: Field must have a value on create/edit through UI and API (with some exceptions for defaults and layout-only required). Enforcing requiredness at the schema level is stronger than layout-only required.

Unique: No two records may share the same value (case sensitivity depends on field config). Useful for natural keys such as employee numbers.

External ID: Marks a field as a known key from an external system. Enables upsert matching in Data Loader and the API, and improves some integration patterns. Text, Number, Email, and Auto Number can be External IDs; combinations of Unique + External ID are common for stable keys.

Key Point: External ID is about matching and integration , not automatically making a field the Salesforce Id. Salesforce still has its own 15/18-character record Id as the primary key.

Record Types

Record types let one object support multiple business processes without cloning the object. Each record type can:

  • Offer different picklist values (for example, Opportunity stages or Case types)
  • Assign different page layouts per profile/app
  • Drive business processes (Opportunity, Case, Lead, Solution standard processes)

Record types do not create separate database tables. All records still live on the same object and share the same fields; visibility of values and layout presentation changes. Sharing rules, OWD, and Apex still operate on the object as a whole unless your code branches on RecordTypeId or developer name.

  • Use record types when Avoid when
  • Same entity, different processes or layouts Completely different entities (use separate objects)
  • Picklist subsets by line of business You only need field-level security or a simple page layout
  • Users must create different “kinds” of the same object You only need a formula or validation rule difference
  • Designing From Requirements

Given a scenario, walk a fixed checklist:

Identify nouns → candidate objects (standard first).

Identify attributes → fields and types; mark keys as Unique/External ID when systems integrate.

Identify relationships → parent-child cardinality (next section).

Identify process variants → record types vs separate objects vs status picklists.

Identify security → OWD, sharing, FLS/CRUD (affects later Apex security topics).

Validate volume and reporting → indexes (External ID/Unique help), report types, roll-ups.

Example: “Track warranty claims against products sold on Opportunities.” Prefer Case or a custom Warranty_Claim__c related to Asset / Product and Account—not a free-floating spreadsheet object with duplicated customer names.

Schema Builder and Object Manager

Schema Builder is a canvas that shows objects, fields, and relationships graphically. Use it to:

  • Sketch and communicate the data model
  • Create custom objects and some field types quickly
  • See relationship lines between objects

Object Manager (Setup) remains the full control surface for field-level details, page layouts, compact layouts, record types, buttons, and search layouts. Developers often design in Schema Builder, then refine field attributes and layouts in Object Manager.

For source-driven development, schema also lives in metadata ( CustomObject , CustomField ) and is deployed with change sets, Salesforce CLI, or packaging. API names chosen at create time are hard to change later without breaking Apex, flows, and integrations—treat naming as permanent.

Naming and API Stability

Labels are UI-friendly and can change; API names are what Apex, SOQL, and integrations bind to.

Custom objects/fields: My_Object__c , Status__c .

Relationship names control child subquery aliases and __r navigation (next sections).

Avoid renaming API names after code ships; plan External ID fields early for integration keys.

  • Key Design Pitfalls
  • Modeling many-to-many as free-text names instead of a junction object
  • Using Long Text Area for values that must be filtered or unique
  • Making layout-required fields that integrations leave blank (prefer schema Required only when truly mandatory)
  • Overusing record types when a single picklist or separate objects would be clearer
  • Ignoring standard objects and recreating CRM core (Accounts, Contacts) as custom

Master object/field design first; relationship types and Apex implications build directly on these choices.