This order reflects genuine, unavoidable dependencies, not an arbitrary convention. The security foundation must come first because every later phase assumes it already exists — an Approval Process needs Roles and Queues to route to, a Dashboard's Run As decision only makes sense against an already-defined Sharing Model, and building automation before access is correctly scoped risks that automation running against a genuinely insecure foundation. The data model must exist before validation and automation, since a Validation Rule or Flow referencing a custom field cannot be built, let alone deployed, against a field that does not yet exist — this is the exact same dependency logic covered in Module 23's deployment ordering, just applied to the build sequence itself rather than the deployment sequence. Reporting and UI naturally come after automation because reports and dashboards are meant to surface the RESULTS of business processes that need to already be running to have meaningful data to show. And deployment discipline comes last specifically because it validates and ships everything that came before it — deploying prematurely, before the full picture is understood, risks exactly the kind of partial, poorly-sequenced rollout Module 23 warned against.

At minimum, this scenario requires Module 15's Before-Save vs After-Save distinction and Order of Execution understanding, since the Probability field update needed to happen efficiently on the same record before the record even saves, while the Approval submission itself needed After-Save capability to actually invoke an Action. It requires Module 17's Approval Process design, specifically the Entry Criteria and Step Criteria distinction, to correctly route the deal through Manager Review always, but Finance Review only conditionally above the 35% threshold. It requires Module 5's Sharing Model and Queue configuration from the security foundation, since the Finance Review step specifically needed a genuine Finance Approvers Queue to route to, which only exists because of foundational work done much earlier. It also genuinely requires Module 16's Invocable Actions, specifically Submit for Approval, to let a Flow automatically trigger the approval submission rather than requiring a manual click. No single module alone could have delivered this working end-to-end process — it is genuinely the product of several modules' concepts operating together correctly.

"Does it work when I test it myself" only validates functional correctness in the exact, narrow conditions of a single Admin's own manual testing — it says nothing about whether the implementation is safe to actually deploy to a real Production org without breaking existing functionality, nothing about whether the org's overall security posture remains sound after all these changes, and nothing about whether the change was rolled out with appropriate testing gates rather than an undisciplined, ad-hoc process. Phase 6 specifically adds the standard of genuine deployment and security readiness: confirming every deployment dependency is correctly identified and validated before committing to Production, as covered in Module 23, and running a comprehensive security audit, as covered in Module 24, verifying that nothing built across the other five phases has inadvertently introduced a data exposure risk, an overly broad Sharing setting, or a hardcoded credential. This is precisely the difference between a working prototype an Admin is personally satisfied with, and a genuinely production-ready implementation a real business could safely depend on — the latter standard is what Phase 6 specifically exists to enforce.

"Run as Specified User" is appropriate here because the explicit business requirement is that every Executive viewing this Dashboard should see the SAME, complete, company-wide picture, regardless of their own individual record-level access — an Executive should not see a partial, individually-restricted view simply because of where they happen to sit in the Role Hierarchy built in the Phase 1 foundation. This directly connects to Module 5's Sharing Model concepts from that foundational phase: without "Run as Specified User," the Dashboard would default to respecting each individual viewer's own record-level access exactly like a Report does, meaning an Executive whose own access happened to be narrower for some reason would see an incomplete, misleadingly partial picture on what is meant to be a definitive company-wide overview. Choosing a genuinely appropriate, broad-access Specified User deliberately overrides this per-viewer behavior specifically because the business need — one consistent, complete picture for every Executive — genuinely calls for it, which is exactly the kind of deliberate, justified Run As decision Module 20 distinguished from a careless, unexamined choice of the same setting.

This behavior comes from Module 21's Dynamic Forms combined with Component Visibility Rules, applied during Phase 5 of this Capstone. The Discount field was placed directly onto the Lightning Record Page using Dynamic Forms, organized into its own Field Section, rather than being embedded inside one fixed, always-visible Page Layout block. A Component Visibility Rule was then attached specifically to that Field Section, with a filter condition checking the current record's StageName field, configured to only display the section when StageName is Negotiation or a later stage. This means the Lightning Page dynamically evaluates this condition against each specific record being viewed — an Opportunity still at an earlier stage like Prospecting genuinely does not meet the condition, so the section remains hidden for that record specifically, while a different Opportunity that has genuinely progressed to Negotiation or beyond meets the condition and displays the section automatically, with zero manual intervention or separate Page Layout required to achieve this per-record, context-aware behavior.

Competence as a Salesforce Administrator is fundamentally about understanding how these individually-learnable features genuinely INTERACT and DEPEND on each other, not simply knowing the location and immediate function of each one in isolation. This Capstone itself demonstrates the point: knowing how to build a Validation Rule, an Approval Process, and a Dashboard are each individually teachable in an afternoon, but genuinely understanding that a Before-Save Flow will resolve a value BEFORE a Validation Rule ever evaluates it, that an Approval Process's record locking behavior interacts with a Dashboard's Run As setting in ways that affect what different viewers ultimately see, or that a Custom Report Type decision made at the very start of a reporting effort can silently block an entire class of later analysis — this is the genuinely deeper competence that separates someone who has memorized individual features from someone who can actually architect a coherent, working system. It also means treating security, data quality, and deployment discipline as continuous, ongoing responsibilities rather than one-time setup tasks completed early and then forgotten, since a real, evolving business genuinely changes in ways that can quietly undermine even a perfectly-built initial implementation if nobody continues paying attention. Competence, ultimately, is the ability to hold the whole system in mind at once — exactly what this Capstone was designed to prove you can now genuinely do.