4.1 Formula Fields & Roll-Up Summaries

4.1 Formula Fields & Roll-Up Summaries

Quick Answer: Formula fields derive a read-only value on a record from other fields (including parent fields via cross-object formulas). Roll-up summary fields aggregate child detail records onto a master-detail parent with COUNT, SUM, MIN, or MAX. Neither is a substitute for every calculation—when you need write-back, complex branching, or aggregates over lookups, use Flow or Apex instead.

Platform Developer I treats formula and roll-up design as core Developer Fundamentals. You must know what each feature can do, where it stops, and how those limits push you toward declarative automation or code.

Formula Fields: Capabilities

A formula field is a field type whose value is computed by the platform whenever the record is read (or when dependent values change, depending on context). Users and Apex treat it as read-only: you query it, you display it, you do not assign it in DML.

Typical uses:

• Concatenate or format display values (full name style strings, status badges)
• Simple math (discounted price, days open, margin percent)
• Boolean flags for UI, validation helpers, and report filters (Is_Overdue__c)
• Reference parent attributes without duplicating data (Account type on a child)
• Drive conditional page layouts indirectly via other tools that read the formula result

Return types include Checkbox, Currency, Date, DateTime, Number, Percent, Text, and Time (availability depends on edition and field context). Formula expressions use Salesforce formula syntax: operators, functions (IF, CASE, ISBLANK, TEXT, DATEVALUE, VLOOKUP is not the spreadsheet VLOOKUP—know platform function names), and field references.

Cross-Object Formulas

A cross-object formula references fields on a related parent (and sometimes further up a relationship chain) from the child record.

Examples:

• On Invoice_Line__c, show Invoice__r.Account__r.Name or a billing status from the parent invoice
• On Opportunity, surface Account industry or a custom parent field without duplicating it

Rules of thumb for the exam:

• You traverse parent relationships (lookup or master-detail), not arbitrary sibling queries
• The formula lives on the object where the result should appear (usually the child or a related object with a path to the parent)
• Spanning multiple relationships increases compile size and can hit spanning relationship limits—formulas are not free recursion over the entire schema
• If the parent is optional (lookup can be blank), guard with ISBLANK / BLANKVALUE patterns so formulas do not surface errors for null parents

Cross-object formulas are excellent for display and simple derived flags. They are poor for enforcing multi-record business processes that must create, update, or delete other records.

Formula Limitations (High-Yield)

Know these failure modes—they appear as “why won’t this work?” scenarios:

1. Cannot write derived data back to another field via the formula itself (use Flow/Apex to stamp values when you need a stored, editable, or historically frozen value).
2. No aggregate over children—a parent formula cannot SUM all child amounts. That is a roll-up summary (or automation) problem.
3. Character and compile-size limits—complex nested IF/CASE trees hit limits; simplify or move logic to Flow/Apex.
4. Not for long procedural workflows—approvals, multi-step updates, callouts, and bulk child processing are out of scope.
5. Reporting/SOQL constraints—some formulas cannot be filtered or sorted the way stored fields can; performance-sensitive filters often prefer stored or indexed fields.
6. Cross-object only along relationships—you cannot “look sideways” to an unrelated object without a relationship path.
7. Time and determinism—formulas that depend on NOW() or TODAY() are dynamic; do not treat them as immutable audit values.

Key Point: Formulas answer “what should this field show given related fields?” They do not answer “what records should I create or update?”

Roll-Up Summary Fields

A roll-up summary field is defined on the master object in a master-detail relationship. It aggregates values from the detail (child) records.

Supported aggregate operations:

Optional filter criteria on the roll-up restrict which detail records participate (for example, only lines where Status__c = 'Active'). Filters make roll-ups far more useful than unfiltered totals.

Critical platform rule (exam trap):

• Roll-up summary fields require a master-detail relationship.
• They are not available on a parent that is only linked by lookup.
• If the business insists on a lookup (independent ownership, optional parent, no cascade delete), you cannot “just add a roll-up.” You redesign the relationship, or you implement aggregation with Flow, Apex, or an AppExchange helper.

Also remember: roll-ups maintain values on the master when detail records change. That maintenance can fire updates on the parent, which can cascade into automation—design triggers and flows with bulk and recursion in mind (covered more under automation chapters).

Formulas vs Roll-Ups vs Flow vs Apex

Use a decision ladder on every derived-data requirement:

Examples:

• “Show Account billing city on a custom child for list views” → cross-object formula.
• “Total of Invoice Line amounts on Invoice where lines are master-detail” → roll-up SUM.
• “Total of related Cases on Account where Case is lookup to Account” → not a native roll-up; use Flow/Apex (or reconsider data model).
• “When Opportunity closes, write a snapshot of calculated discount to a locked field” → Flow/Apex writes a normal field; formula alone keeps recalculating.

Exam Traps and Decision Patterns

1. RUS on lookup: Scenario describes optional parent or lookup and asks for a roll-up—correct answer is that native RUS is unavailable; pick Flow/Apex or change to master-detail if coupling is acceptable.
2. Formula for child aggregates on parent: Formula cannot query children; choose roll-up (if MD) or automation.
3. Editable calculated field: Formulas are not editable; if users must override, store a field and optionally default it with automation.
4. Cross-object without relationship: Invalid; create a relationship first.
5. Using formula to replace validation: Formulas can help display, but validation rules (and Flow/Apex) enforce; do not confuse display with enforcement.
6. Assuming roll-up filter supports every field type: Filters have limits; exotic detail fields may force automation instead.

Design Checklist for Developers

1. Is the value purely derived and always live? → Formula.
2. Is it an aggregate of MD children? → Roll-up summary.
3. Does it require DML on other records or lookup aggregation? → Flow, then Apex if needed.
4. Will reporting need a stable historical value? → Stored field + automation stamp.
5. Does master-detail semantics (cascade, sharing, required parent) match the business? If not, do not force MD only to get a roll-up.

Master these boundaries and you avoid both over-engineering with Apex and under-engineering with formulas that cannot do the job. The platform rewards the smallest feature that correctly owns the calculation.