3.1 Custom Objects & Custom Field Types

Custom Objects & Custom Field Types

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:

1. 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).
2. Object Name (API Name): The unique programmatic identifier used in SOQL queries, Flow formulas, and external API integrations (Property__c).
3. 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.
4. 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.

• 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.

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.

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.