3.1 Objects, Fields & Schema Design
Key Takeaways
- 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
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
__rnavigation (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.
A team needs a stable key from an ERP to match and upsert Product-related custom records during nightly loads. Which field configuration best supports that pattern?
When should you create a custom object instead of adding fields to a standard object?
What is a primary purpose of record types on an object?