ExamFinch.com My Study

Study guide

4.1 Formula Fields & Roll-Up Summaries

Practice this exam

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

4.1 Formula Fields & Roll-Up Summaries

Key Takeaways Explain This Topic AI

Formula fields calculate read-only values from the same record or related parents (cross-object); they cannot be written by Apex DML or user edit

Roll-up summary fields (COUNT, SUM, MIN, MAX) exist only on the master of a master-detail relationship—not on pure lookup parents

Choose formulas for simple derived display, roll-ups for parent aggregates on master-detail, Flow/Apex when rules exceed formula limits or need write-back

Exam trap: requesting a roll-up on a lookup relationship fails natively—use Flow, Apex, or redesign to master-detail when appropriate

Cross-object formulas traverse parent relationships (__r path) with compile-size and spanning limits; not every parent chain is legal or free

Last updated: August 2026

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.

  • Characteristic Implication
  • Read-only Not settable in UI, API, or Apex DML
  • No storage of independent input Source data lives in other fields
  • Recalculated by platform Always reflects current source fields after save/read rules
  • Limited procedural logic No loops, no SOQL, no multi-record writes

Filter/sort caveats Some formula types or long text-like formulas are restricted in list views, SOQL filters, or indexes

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:

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

No aggregate over children —a parent formula cannot SUM all child amounts. That is a roll-up summary (or automation) problem.

Character and compile-size limits —complex nested IF / CASE trees hit limits; simplify or move logic to Flow/Apex.

Not for long procedural workflows —approvals, multi-step updates, callouts, and bulk child processing are out of scope.

Reporting/SOQL constraints —some formulas cannot be filtered or sorted the way stored fields can; performance-sensitive filters often prefer stored or indexed fields.

Cross-object only along relationships —you cannot “look sideways” to an unrelated object without a relationship path.

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:

  • Operation Meaning Typical use
  • COUNT Number of detail records (optionally filtered) Count of open lines, related claims
  • SUM Total of a numeric/currency field on details Invoice total, total quantity
  • MIN Smallest value among details Earliest due date, lowest score
  • MAX Largest value among details Latest activity date, highest amount

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:

  • Need Prefer
  • Display math or parent field on same/child record Formula (including cross-object)
  • COUNT/SUM/MIN/MAX of master-detail children on parent Roll-up summary

Aggregate over lookup children, or complex filtered multi-object logic with write-back Record-triggered Flow (often first)

Heavy bulk logic, complex recursion control, callouts, or logic formulas cannot express Apex (trigger/service)

One-time stamp that must never change when sources change Automation that writes a stored field , not a live formula

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

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.

Formula for child aggregates on parent: Formula cannot query children; choose roll-up (if MD) or automation.

Editable calculated field: Formulas are not editable; if users must override, store a field and optionally default it with automation.

Cross-object without relationship: Invalid; create a relationship first.

Using formula to replace validation: Formulas can help display, but validation rules (and Flow/Apex) enforce; do not confuse display with enforcement.

Assuming roll-up filter supports every field type: Filters have limits; exotic detail fields may force automation instead.

Design Checklist for Developers

Is the value purely derived and always live? → Formula.

Is it an aggregate of MD children? → Roll-up summary.

Does it require DML on other records or lookup aggregation? → Flow, then Apex if needed.

Will reporting need a stable historical value? → Stored field + automation stamp.

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.