Capstone Requirements and Architecture Planning

A stakeholder request: "Build a Customer Success Command Center for support reps to manage open Cases and see the related Account and Opportunity context in one place, usable from both desktop and the Salesforce Mobile App."

This single scenario drives all four lessons in this module — planning here, a real Apex data layer next, real components after that, then tests and deployment to close the loop.

1. View and filter open Cases.
2. Update a Case's status inline, without leaving the workspace.
3. View a summary of the related Account, including its open Opportunities.
4. Create a new Case directly from the workspace.
5. Work correctly on both desktop and the Salesforce Mobile App.

Requirement (5) alone, and the reality of who uses this feature and how, drives several explicit non-functional requirements — each tracing directly back to a specific module in this course:

• Security — every operation must respect CRUD/FLS/sharing via AccessLevel.USER_MODE (Module 12), not system-mode defaults.
• Performance — avoid redundant server calls; reuse LDS caching and normalized wire parameters where possible (Module 13).
• Mobile support — declare supportedFormFactors and use a responsive SLDS layout from the start (Module 18).
• Testability — both Jest and Apex test coverage for anything shipped (Module 14).

Apex layers (Module 16): CaseSelector/AccountSelector for query isolation, a CommandCenterService for the actual business logic, and a thin CommandCenterController as the LWC-facing contract.

Component tree (Module 5's composition, Module 9's structure): a parent commandCenter component orchestrating two children — caseList (a datatable, Module 10) and accountSummary (an LDS-backed view, Module 6) — plus a "New Case" modal (Module 9).

Sketching this out before writing any code is deliberate — it's what lets Lessons 2 and 3 implement each piece with a clear, agreed shape to build toward, rather than improvising the architecture as code is written.