Field Types and When to Use Them
By the end of this lesson, you'll be able to:
- Choose the right field type for a given data requirement
- Explain the tradeoffs between Picklist, Text, and Formula fields for the same conceptual data
Prerequisites: Standard vs. Custom Objects
Constrained input: Picklist vs. Text
A free-text field for something like "Status" invites inconsistent values ("Open", "open", "OPEN", "Opened") that break reports and filters. A Picklist constrains input to a defined set of values, keeping data clean and reportable — reach for Text only when the values are genuinely open-ended, like a name or description.
Computed fields: Formula and Roll-Up Summary
A Formula field computes its value from other fields on the same record (or related records via traversal) and is always read-only, recalculated automatically — never store a value that could instead be a formula. A Roll-Up Summary field aggregates values from child records (COUNT, SUM, MIN, MAX) across a master-detail relationship specifically — it requires master-detail, not lookup.
A reliably filterable Picklist field
SELECT Id, StageName, Amount, Probability
FROM Opportunity
WHERE StageName = 'Closed Won'StageName is a Picklist, constrained to a known set of stage values — this is exactly why WHERE StageName = 'Closed Won' works reliably, rather than needing to guard against typos and casing variants.
Exercise
A custom object 'Order__c' needs a field showing the total value of all its related Order_Item__c records. What field type fits, and what relationship type does it require?
Show hint
Think about aggregating child records, and which relationship type roll-up summaries need.
Field Types and When to Use Them — Quick Check
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Salesforce offers many field types beyond plain Text — Picklist for a constrained set of values, Formula for computed read-only values, Roll-Up Summary for aggregating child records — and choosing the right one up front avoids painful data-quality problems later.