Advanced 30 min read

Design the Data Aggregation

By the end of this lesson, you'll be able to:

Design what "account health" means as a concrete, computable set of metrics
Identify which pieces of data each metric requires
Sketch the service-layer methods needed before writing any Apex

Prerequisites: Module 34: "Apex for Lightning Web Components"

What we're building

"Given an Account, show a support manager a single 'health' view:
open Case count, average Case resolution time, total Closed Won
revenue, and days since the last Contact activity — all in one
dashboard component."

This is a genuinely realistic feature: an LWC needs one aggregated view built from several different pieces of data, exposed through Module 34's @AuraEnabled boundary, secured per Module 28, and tested per Module 31.

Defining each metric concretely

Open Case count — COUNT() of Case where AccountId matches and IsClosed = false (Module 20's aggregate functions).
Average Case resolution time — average days between CreatedDate and ClosedDate across closed Cases for this Account.
Total Closed Won revenue — Total_Won_Revenue__c, already computed by Module 26's rollup.
Days since last Contact activity — days between today and the most recent Contact.LastActivityDate among this Account's Contacts.

Stating each metric this precisely — not just "show account health" — is Module 26's "Design the Requirement" discipline, essential before any aggregation logic can be written correctly.

Sketching the service layer

AccountHealthService
  - getOpenCaseCount(accountId)
  - getAverageResolutionDays(accountId)
  - getTotalWonRevenue(accountId)
  - getDaysSinceLastActivity(accountId)
  - getHealthSummary(accountId) — combines all four into one wrapper

One focused method per metric, plus a combining method — this shape lets each metric be tested individually (Module 31) while still offering one simple call for the LWC controller to use.

Exercise

As a comment, write the precise SOQL-aggregate-function definition for "average Case resolution time" the way Lesson 1 defined the other three metrics.

Show hint

Think in terms of AVG() and a date-difference expression.

APEX

Design the Data Aggregation Quiz

1. Why define each health metric this precisely before writing any Apex?

Vague requirements like "show account health" can't be implemented correctly or tested meaningfully Apex requires a written specification document to compile It has no real benefit beyond documentation Precise definitions are only needed for currency fields

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

This module builds a Client Health Dashboard — an LWC-facing feature summarizing an Account's overall health from several signals at once, designed and built with this course's full discipline: service layer, security, tests, performance, and review.

← Handling Errors Gracefully for the UI Build the Service Layer →