Design the Requirement

Over this module you'll build a real CRM automation, end to end:

"Whenever an Opportunity is marked Closed Won, automatically add its Amount to a Total_Won_Revenue__c field on the related Account, so sales managers can see each account's total closed business without running a report."

This is a genuinely common real-world Salesforce request — and this module builds it the right way: designed, bulkified, validated, and tested, using everything from Modules 22-25.

The plain request above is a good starting point, but it has gaps a developer has to fill in before writing code:

• Which object, which event? Opportunity, on after update (the Amount only needs rolling up once the Opportunity is actually saved as Closed Won — Module 24's before/after distinction matters here).
• What if the Opportunity's Stage changes away from Closed Won later? The requirement as stated doesn't say — a real requirement needs this answered explicitly (this module's decision: subtract it back out).
• What if Amount is blank? Treat it as 0, so the rollup never breaks on missing data.

Writing code against an ambiguous requirement means guessing — and a guess that's wrong isn't discovered until a stakeholder sees the finished feature behave unexpectedly. Explicitly naming and resolving each gap now (as this lesson just did) means the rest of this module's lessons build on a requirement everyone would actually agree with, not an assumption.