6.1 Custom Objects & Field Types

Custom Objects & Field Types

Quick Summary: While standard CRM objects like Accounts, Contacts, and Opportunities handle core sales and service lifecycles, real-world businesses require customized data architectures. Custom objects provide tailored database tables identified by the __c API suffix. Every custom object automatically receives essential system fields including a configurable Record Name. Extending these objects with custom fields unlocks diverse data formats—from text and numbers to global picklists, dynamic formula calculations, and relationship-driven roll-up summaries.

Custom Objects: Extending the Salesforce Data Model

Salesforce provides a rich catalog of pre-built standard objects to support standard customer relationship management workflows. However, modern enterprises frequently operate specialized business processes that do not map naturally to standard CRM entities. For example:

• A commercial real estate brokerage needs to track buildings, leases, and maintenance inspections.
• A healthcare organization must track medical equipment, clinical trials, and patient check-ins.
• A software company needs to manage release bug tickets, project milestones, and customer onboarding implementations.

To accommodate these unique operations without writing custom database code, Salesforce provides Custom Objects. A custom object is a custom database table created and managed within the Lightning Platform metadata catalog. Like standard objects, custom objects can store record data, display customized Lightning record pages, trigger automated flows, support analytical reporting, and enforce fine-grained security policies.

Anatomy and Properties of a Custom Object

When an administrator creates a custom object in Setup via the Object Manager, several core properties must be defined:

1. Label: The singular user-facing display name presented throughout the user interface (e.g., Property or Inspection).
2. Plural Label: The plural display name used on tabs, list views, and navigation menus (e.g., Properties or Inspections).
3. Object Name (API Name): The unique programmatic developer identifier used by formulas, APIs, and code. Salesforce automatically appends the custom suffix __c (double underscore lowercase 'c') to distinguish custom entities from standard system entities. For example, a custom object labeled Property receives the API name Property__c.
4. Description: Administrative documentation explaining the business objective and operational purpose of the object.
5. Record Name Field: Every custom object automatically receives a primary naming field (Name). During object configuration, the administrator designates the data type of the Name field:
   • Text: The user manually inputs a name or descriptor when creating the record (e.g., "Downtown Headquarters Tower").
   • Auto-Number: The system automatically generates a sequential, unique alphanumeric tracking string using a specified display format (e.g., PROP-{0000} generates PROP-0001, PROP-0002, PROP-0003).

Standard System Fields Auto-Generated on All Custom Objects

Whenever a custom object is created, the Salesforce platform automatically provisions seven foundational system fields. These fields are managed entirely by the underlying platform runtime and guarantee auditability, traceability, and identity across the database:

+--------------------------------------------------------------------------+
|              Auto-Generated System Fields on Custom Objects              |
|                                                                          |
| [Id]               ---> 15/18-character immutable global unique record ID|
| [Name]             ---> Primary display label (User Text or Auto-Number) |
| [CreatedById]      ---> Lookup to the User who generated the record      |
| [CreatedDate]      ---> System timestamp recorded when record was saved  |
| [LastModifiedById] ---> Lookup to the User who last edited the record    |
| [LastModifiedDate] ---> System timestamp of the most recent save action  |
| [OwnerId]          ---> User or Queue assigned record ownership          |
+--------------------------------------------------------------------------+

• Record ID (Id): An immutable, globally unique string of 15 characters (case-sensitive, used in the browser URL) or 18 characters (case-insensitive, used in external APIs and data import tools).
• Record Name (Name): The default identifier displayed at the top of the record header and in lookup search dialogues.
• CreatedById & CreatedDate: Audit fields tracking the exact user account and timestamp when the record entered the database.
• LastModifiedById & LastModifiedDate: Audit fields recording who made the most recent update and when.
• OwnerId: Designates the individual User or collaborative Queue that possesses ownership rights over the record. (Note: OwnerId is present on all standalone custom objects and objects linked via Lookup, but is omitted if the object resides on the detail side of a Master-Detail relationship).

---

Custom Fields and Core Data Types

To capture specific business metrics, administrators extend standard and custom objects with Custom Fields. Like custom objects, all custom fields carry the __c API name suffix (for example, Square_Footage__c or Commission_Rate__c). Choosing the appropriate field data type is vital for ensuring data integrity, providing intuitive input widgets, and facilitating accurate reporting.

Text and Alphanumeric Types

• Text: Stores up to 255 alphanumeric characters on a single line. Suitable for short entries such as serial numbers, tracking codes, or brief titles.
• Text Area: Stores up to 255 characters displayed across multiple lines on a record page, ideal for short street addresses or summary descriptions.
• Text Area (Long): Accommodates up to 131,072 characters across multiple lines. Ideal for detailed resolution notes, project specifications, or legal disclaimers.
• Text Area (Rich): Stores up to 131,072 characters and includes a full formatting toolbar in the UI, allowing users to format text (bold, italics, underlines), insert bulleted and numbered lists, embed web links, and paste inline images.
• Text (Encrypted): Stores up to 175 characters of sensitive alphanumeric data (such as social security numbers or credit card tokens) masked with mask characters (e.g., asterisks or Xs) for unauthorized users.

Numeric, Currency, and Percentage Types

• Number: Stores real numbers with configurable total digits (precision) and decimal places (scale). Can represent integers or decimal fractions, and can be positive, negative, or zero.
• Currency: Formats numbers with a currency symbol (e.g., $1,250.00). If an organization enables Multi-Currency, currency fields automatically handle currency codes and historical corporate exchange rate conversions.
• Percent: Displays numbers with a percent sign (%). A user who enters 15 sees 15%, and formulas and validation rules treat that value as the decimal 0.15.

Temporal Types

• Date: Stores a calendar date without a timestamp (formatted as YYYY-MM-DD). Provides an interactive calendar pop-up widget in the Lightning interface.
• Date/Time: Stores a calendar date paired with an exact time. All Date/Time values are stored in Coordinated Universal Time (UTC) at the database layer and automatically converted to the viewing user's local time zone based on their Personal Settings.
• Time: Stores a time of day independent of a specific date (e.g., 08:30:00.000), useful for business hours or shift start times.

Boolean and Selection Types

• Checkbox: Stores a simple boolean value: TRUE (checked) or FALSE (unchecked). Administrators configure whether the default state is checked or unchecked.
• Picklist: A single-select dropdown menu presenting a predefined list of valid text choices. Picklists prevent typographical errors and enforce standardized data entry.
• Multi-Select Picklist: Allows users to select multiple options from a predefined list. Selected values are stored in the database as a single string separated by semicolons (;).

+--------------------------------------------------------------------------+
|                       Picklist Architecture                              |
|                                                                          |
| [Local Picklist]               ---> Defined exclusively on one object    |
| [Global Picklist Value Set]    ---> Defined once in Setup; shared across |
|                                     multiple custom picklist fields      |
| [Controlling / Dependent Pair] ---> Parent picklist/checkbox filters     |
|                                     child picklist choices dynamically   |
+--------------------------------------------------------------------------+

Local vs. Global Picklist Value Sets

• Local Picklist: The list of permitted options is created directly on that specific field within the object's field definition. Modifying options on one local picklist has no effect on any other field.
• Global Picklist Value Set: A centralized, reusable collection of picklist values configured in Setup. Multiple picklist fields across different standard and custom objects can share this single value set (e.g., a standardized corporate list of Countries or Business Units). If an administrator adds or deactivates a value in the global set, the change immediately takes effect across all fields referencing that set.

Controlling vs. Dependent Picklists

To guide users through complex data entry workflows, administrators can establish a Controlling-Dependent relationship between two fields. The option selected in the Controlling Field dynamically filters the available choices displayed in the Dependent Field.

• Controlling Field Rules: Can be a standard or custom Picklist, or a standard or custom Checkbox. (A Multi-Select Picklist cannot be a controlling field).
• Dependent Field Rules: Must be a custom Picklist or a custom Multi-Select Picklist. (Standard picklists cannot be dependent fields).
• Example: A controlling picklist Vehicle_Make__c with values Toyota, Ford, and BMW dictates the options available in dependent picklist Vehicle_Model__c. Selecting Toyota exposes Camry, Corolla, and RAV4, while hiding models from other manufacturers.

---

Dynamic Calculations: Formula Fields vs. Roll-Up Summary Fields

Salesforce provides two declarative mechanisms for computing calculated values without custom Apex code: Formula Fields and Roll-Up Summary Fields. Understanding their differences is a major exam objective.

+-------------------------------------------------------------------------+
| FORMULA FIELD (Same Record or Parent via Lookup)                        |
| - Read-only dynamic calculation evaluated at view/query runtime         |
| - Evaluates math, logical (IF/CASE), date, and text operations          |
| - Cross-Object Formulas traverse up to 10 relationship levels upward    |
+-------------------------------------------------------------------------+
| ROLL-UP SUMMARY FIELD (Summarizes Child Records on Master)              |
| - Aggregates child records onto a parent record (COUNT, SUM, MIN, MAX)  |
| - Strictly requires a Master-Detail relationship                        |
| - Recomputes automatically when child records are created, edited, deleted|
+-------------------------------------------------------------------------+

1. Formula Fields

A Formula Field is a read-only field whose value is calculated dynamically at runtime using a formula expression. Formula fields support numeric, currency, percent, date, text, checkbox, and time return types.

• Dynamic On-the-Fly Calculation: Formula fields do not store static values in the database table (unless deterministic and indexed). Instead, the platform computes the formula whenever the record is opened, queried, or included in a report.
• Functions and Operators: Formulas support mathematical operators (+, -, *, /), logical operators (AND, OR, NOT), conditional logic (IF, CASE), date functions (TODAY(), NOW(), ADDMONTHS()), and text functions (TEXT(), ISPICKVAL(), CONCATENATE()).
• Cross-Object Formulas: A formula can reference fields from related parent records up to 10 relationship levels away using relationship dot notation. For instance, on a custom Inspection__c record, a formula can pull the property owner's phone number using Property__r.Account__r.Phone.

2. Roll-Up Summary Fields

A Roll-Up Summary Field is a read-only field on a parent record that calculates summary metrics across related child records.

• Strict Master-Detail Prerequisite: A roll-up summary field can only be created when the parent and child objects are connected by a Master-Detail relationship. Roll-up summary fields cannot be created across a standard Lookup relationship! Salesforce also supports roll-ups on a few built-in standard pairs: Accounts can summarize related Opportunities, Opportunities can summarize Opportunity Products, and Campaigns can summarize Campaign Members.
• Four Core Aggregate Functions:
  1. COUNT: Calculates the total number of related child detail records.
  2. SUM: Adds together the numeric or currency values of a specific field across all child detail records.
  3. MIN: Finds the lowest numerical value, earliest date, or earliest time among related child detail records.
  4. MAX: Finds the highest numerical value, latest date, or latest time among related child detail records.
• Filter Criteria: Administrators can apply filter criteria to include only child records that meet specific conditions (for example, summing the Amount__c of child detail invoices where Status__c = 'Paid').
• Automatic Recalculation: Whenever a child detail record is inserted, updated, deleted, or undeleted, the platform automatically recalculates the roll-up summary value on the master record.

---

Comprehensive Field Types Reference Table