Study guide
3.1 Custom Objects & Custom Field Types
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
3.1 Custom Objects & Custom Field Types
Key Takeaways Explain This Topic AI
Custom objects represent specialized database tables with an '__c' API suffix, supporting either Text or Auto-Number as their primary Record Name field.
Allow Activities can be disabled on a custom object unless workflow tasks depend on it; disabling removes activity related lists and affected reports, without deleting existing activity records.
Long Text Area and Rich Text Area fields store up to 131,072 characters but cannot be marked as Unique, configured as External IDs, or indexed for search filters.
System-level Required field settings enforce validation across all entry channels including the API, Data Loader, and Flows, unlike page layout requirements which only govern user input on a specific UI layout.
Objects support a maximum of 25 External ID fields restricted to Text, Number, or Email data types, which are automatically indexed to facilitate upsert operations without querying Salesforce record IDs.
Last updated: October 2026
Custom Objects & Custom Field Types
Important
Data modeling forms the architectural foundation of any Salesforce implementation. Designing custom objects and selecting proper field types directly dictates reporting capabilities, user experience, data integrity, and integration scalability across the platform.
Salesforce provides a rich suite of standard objects—such as Account, Contact, Opportunity, Lead, and Case—to support standard business workflows. However, complex enterprise processes inevitably require custom data structures. In the Salesforce multi-tenant relational architecture, a Custom Object maps directly to a custom database table, complete with user-defined attributes, security controls, and relational linkages. Every custom object and custom field is identified in the API by appending the three-character suffix __c to its developer name (for example, Property__c or Square_Footage__c ).
Custom Object Definition & Key Attributes
When creating a custom object through Object Manager or declarative tools, administrators must configure fundamental attributes that govern how records are identified, secured, and surfaced to end users:
Label and Plural Label : The singular label identifies the object across page titles, lookups, and single-record contexts ( Property ), while the plural label names navigation tabs, list views, and related lists ( Properties ).
Object Name (API Name) : The unique programmatic identifier used in SOQL queries, Flow formulas, and external API integrations ( Property__c ).
Record Name : Every custom object requires a primary name field used to display the record in search results, lookup dialogs, and related lists. App builders must select one of two formats:
Text : Accepts up to 80 characters of user-entered text (e.g., Account Name or Project Title). Ideal when users recognize records by an intuitive business name.
Auto-Number : Automatically increments a sequential number using a configured display format (e.g., PROP-{0000} or INV-{YYYY}-{00000} ) and an initial starting number. Ideal for transaction logs, invoices, help desk tickets, or when manual naming would introduce duplicate or arbitrary values.
Deployment Status :
In Development : Keeps the custom object hidden from standard end users. Only administrators and users with the "Customize Application" system permission can view the object, create tabs, or test page layouts. This prevents incomplete schemas from cluttering user navigation during active development.
Deployed : Makes the custom object fully available to all internal and external users whose profiles or permission sets grant object-level access.
Optional Object Features: Optional Features and Their Dependencies
During object creation, an app builder can enable several optional platform features. Understanding which options can be reverted later is a frequent topic on the Platform App Builder exam:
Allow Reports : Enables the object for inclusion in standard reports and custom report types. This setting can be disabled later if reporting is no longer needed.
Allow Activities : Enables users to associate Open Tasks, Scheduled Events, and Activity History with the object.
Warning
Review dependencies before disabling activities: Activities can be turned off unless workflow tasks depend on the object. Disabling removes activity related lists and associated activity reports; it does not delete existing activities.
Track Field History : Enables the system to audit changes to up to 20 custom or standard fields per object (with higher allocations available through the separately licensed Field Audit Trail; verify the org's current entitlement). Tracks old values, new values, the user making the edit, and a date/time stamp. Can be toggled on or off at any time.
Allow in Chatter Groups : Allows users to link records of this custom object to Chatter groups. Can be toggled at will.
Object Creation Options (First-Save Only)
Two specific checkboxes appear only when initially creating a new custom object:
Add Notes and Attachments related list to default page layout : Automatically inserts standard document management components.
Launch New Custom Tab Wizard after saving this custom object : If skipped during creation, the object cannot be accessed directly via app navigation until an administrator navigates to Setup > Tabs and manually provisions a custom tab.
Custom Field Data Types & Technical Specifications
Salesforce supports diverse field data types, each engineered for specific storage, display, and validation behaviors. Selecting the wrong data type early in development can introduce severe technical debt, break downstream integrations, or complicate reporting formulas.
Field Data Type Maximum Size / Capacity Indexing Considerations Primary Exam Considerations
Text Up to 255 characters Depends on index configuration and query selectivity Single-line alphanumeric; can be made Unique and set as an External ID.
Text Area Up to 255 characters Depends on index configuration and query selectivity Multi-line text displayed across separate lines without rich formatting.
Text Area (Long) 256 to 131,072 characters Depends on index configuration and query selectivity Stored as CLOB; cannot be Unique, External ID, or used in roll-up summary filters.
Text Area (Rich) Up to 131,072 characters Depends on index configuration and query selectivity Supports HTML, styling, bullet points, and embedded images; cannot be used in formulas.
Encrypted Text Up to 175 characters Depends on index configuration and query selectivity Classic masking (all characters, or mask last 4); requires "View Encrypted Data" permission.
Number Up to 18 digits total Depends on index configuration and query selectivity Configured as (Integer, Decimal) totaling ≤ \le ≤ 18 digits (e.g., 16, 2). Can be External ID.
Currency Up to 18 digits total Depends on index configuration and query selectivity Displays locale currency symbols; automatically handles multi-currency conversion in orgs.
Percent Up to 18 digits total Depends on index configuration and query selectivity Entered as a percentage; formula references use its fractional value (10% is 0.10). Do not divide that reference by 100 again.
Date Calendar date only Depends on index configuration and query selectivity Displays date picker; internally formatted as YYYY-MM-DD; no time zone conversion.
Date/Time Date and time stamp Depends on index configuration and query selectivity Automatically converts and displays values in the viewing user's configured local time zone.
Checkbox Boolean (True/False) Depends on index configuration and query selectivity Always returns Boolean; default state can be explicitly set to Checked or Unchecked.
URL Up to 255 characters Depends on index configuration and query selectivity Automatically formats input as a clickable hyperlink, prepending http:// if omitted.
Phone Up to 40 characters Depends on index configuration and query selectivity Preserves country formatting; integrates natively with Salesforce CTI click-to-dial systems.
Email Up to 80 characters Depends on index configuration and query selectivity Validates standard email syntax ( user@domain.com ); can be marked as an External ID.
Picklist Defined text entries Depends on index configuration and query selectivity Restricts input to a predefined list; supports Global Picklist Value Sets for reuse.
Multi-Select Picklist Multiple chosen values Depends on index configuration and query selectivity Values stored as semicolon-delimited text; severe formula and reporting constraints.
The Multi-Select Picklist Architecture Trap
Multi-Select Picklists frequently appear as incorrect distractors on scenario questions requiring roll-up summaries, complex cross-object formulas, or analytical reporting. Key platform constraints include:
Formula Complexity : Standard comparison operators ( = , != ) fail on multi-select picklists. App builders must use the specialized INCLUDES(MultiSelect_Field__c, "Target_Value") function, which returns a Boolean.
Roll-Up Summary Exclusion : Multi-select picklists cannot be evaluated in the filter criteria of roll-up summary fields on master-detail relationships.
Data Export & Reporting : In reports and Data Loader extracts, values export as a single string concatenated with semicolons (e.g., Gold;Platinum;VIP ), making relational slicing and parent-child aggregation tedious.
Field Integrity Properties: Required, Unique, and External ID
Data integrity is governed by three critical declarative attributes available on custom field definitions: +-----------------------------------------------------------------------------------+
- | FIELD INTEGRITY ATTRIBUTES |
- +---------------------------+---------------------------+---------------------------+
- | REQUIRED | UNIQUE | EXTERNAL ID |
- | System-level enforcement | Prevents duplicate values | Indexed integration key |
- | Enforced in API & UI | Case-sensitive or ignored | Default 25 fields per object |
- | Blocks Data Loader/Flows | Available on Text/Number | Text, Number, Email only |
- +---------------------------+---------------------------+---------------------------+
- 1. Required (System-Level vs. Page Layout)
A critical distinction on the Platform App Builder exam is the difference between a System-Level Required Field and a Page Layout Required Field :
System-Level Required (Universal Required) : Checked on the custom field definition in Object Manager. This field is enforced universally across all interfaces—including standard UI, Lightning Record Pages, SOAP/REST APIs, Apex code, Salesforce Flow, and Data Loader bulk operations. If a record is imported without a value for a universally required field, the transaction immediately fails.
Page Layout Required : Configured by clicking the wrench icon on a field within the Page Layout editor or setting UI properties in Dynamic Forms. This requirement is only enforced when a user edits or saves the record through that specific UI layout . Imports via Data Loader, automated updates via Flow, or integrations via the API will bypass page layout requirements completely.
Tip
If an exam scenario asks how to ensure a field is populated regardless of whether records are created by end users, imported via Data Loader, or generated by an external integration, the correct declarative answer is setting the field as Required at the Field Definition level (or writing a Validation Rule), not making it required on the page layout.
2. Unique Fields
The Unique checkbox prevents duplicate values from being saved across different records within the same object. App builders can select:
Treat "ABC" and "abc" as different values (case-sensitive) : Allows capital and lowercase variants to coexist as separate records.
Treat "ABC" and "abc" as the same value (case-insensitive) : Rejects "abc" if "ABC" already exists in the database.
Unique fields can be configured on Text, Number, and Email fields.
3. External ID Fields
An External ID is a custom field designated as an external reference identifier from an outside system (such as an ERP customer number, accounting billing ID, or legacy database primary key).
Supported Data Types : Only Text , Number , and Email fields can be configured as External IDs. (Picklists, Dates, and Currencies cannot).
Object Limit : An object can have a maximum of 25 External ID fields .
Automatic Indexing : Designating a field as an External ID automatically flags it for indexing in the underlying database, accelerating search queries, SOQL filters, and report load times.
Upsert Operations : In data loading tools (Data Loader, REST API), the upsert call uses the External ID to match incoming records against existing database records. If a match is found, the existing record is updated; if no match is found, a new record is inserted—eliminating the need to query for Salesforce 18-character record IDs before running migrations.
Official Source Check
Checked October 19, 2026: Activities on custom objects ; External ID field limits .
Checked October 19, 2026: Percent values in formulas .