Salesforce BA Zero to Hero Module 15 — Capstone Project (XYZ Company)
🏆 Salesforce BA Zero to Hero — Module 15 of 15 — CAPSTONE
The Capstone Project — XYZ Company
Discount Approval Governance Initiative
Every concept, every artifact, every exercise from this entire course, brought together into one complete, realistic BA deliverable package. This is where it all clicks into place.
Module 15 of 15 (plus Module 0 bonus) · Phase 4: Testing & Delivery · FINAL MODULE
📋 The Capstone Brief
XYZ Company's discount approval process is currently informal and email-based, with no consistent governance, no audit trail, and no clear visibility into pending decisions. This is the exact same project you have been building piece by piece across every module's exercises throughout this entire course. This Capstone pulls every one of those pieces together into a single, coherent, end-to-end deliverable package — the genuine shape of real BA project work, not a disconnected collection of exercises.
✓ A complete project brief and stakeholder map, planned before any documentation begins
✓ Genuine elicitation findings and stakeholder management artifacts
✓ A traced process map and confirmed Gap Analysis
✓ Formal, signed-off BRD/FRD documentation with full technical grounding
✓ An organized, sprint-ready backlog executed through real Scrum ceremonies
✓ A complete UAT cycle and a genuine, adopted launch
✓ A full look back at everything this course covered, end to end
📋 The 7 Project Phases
Phase 1 of 7
The Brief & Stakeholder Map
Every real project begins with scope discipline before any documentation work starts. XYZ Company's VP of Sales has flagged that discount approvals are "a mess" — vague, unstructured, and exactly the kind of starting point a genuine BA project begins from.
📚 Modules Used in This Phase
Module 1 (the project lifecycle this entire Capstone follows, end to end), Module 3 (stakeholder mapping across the 5 genuine categories — direct users, decision makers, indirectly affected teams, technical stakeholders, external stakeholders).
| Stakeholder Category | Specific Stakeholder | Power/Interest |
|---|---|---|
| Decision Maker | VP of Sales | High Power, High Interest — Manage Closely |
| Direct Users | Sales Reps, Sales Managers | Lower Power, High Interest — Keep Informed |
| Indirectly Affected | Finance (margin impact), Legal (compliance consistency) | High Power, Lower Interest — Keep Satisfied |
| Technical Stakeholder | Salesforce Admin (XYZ Company's internal Admin) | Responsible for Build (Module 3 RACI) |
🛠️ Why This Phase Matters to Everything That Follows
This stakeholder map is not a formality — every subsequent phase of this Capstone references it directly. The Power/Interest classification determines exactly how much engagement effort each stakeholder receives throughout the rest of the project, precisely the discipline Module 3 built.
⚠️ A Decision Worth Defending
Notice Legal and Finance are included despite never being mentioned in the original vague complaint from the VP. A weaker BA would map only the obviously visible stakeholders (VP, Sales Reps) and miss these indirectly affected teams entirely — exactly the "missed stakeholder" failure mode Module 3 specifically warned produces costly, avoidable friction later.
Phase 2 of 7
Elicitation & Stakeholder Management
With stakeholders mapped, genuine Discovery begins — structured interviews surfacing the real underlying problem behind the VP's vague "it's a mess" complaint, and navigating the genuine conflicting priorities this process touches.
📚 Modules Used in This Phase
Module 2 (the 5-stage interview structure, open questions, the "stated solution vs underlying problem" discipline), Module 3 (RACI for the threshold decision, navigating the genuine Sales-vs-Finance priority conflict).
| RACI Role | Stakeholder | Decision |
|---|---|---|
| Responsible | BA | Gathers input, drafts the recommendation |
| Accountable | VP of Sales | Owns the final discount threshold decision — exactly one decision-maker |
| Consulted | Sales Managers, Finance | Genuine input shapes the recommendation before finalizing |
| Informed | Sales Reps | Notified of the final threshold once decided |
KEY ELICITATION FINDING — synthesized and validated
SYNTHESIS: Three distinct pain points surfaced across multiple
stakeholder interviews:
1. No audit trail — approval decisions live only in email,
with no permanent record (Finance and Legal's core concern)
2. No visibility — Sales Reps cannot see where a pending
request stands without manually following up
3. Single-tier approval — currently ANY discount, regardless
of size, goes to the same approver, with no escalation
for genuinely large discounts (VP's specific concern)
VALIDATED with the VP directly: "Yes, that's exactly it."🛠️ Navigating the Genuine Conflict
Sales wanted minimal friction at submission; Finance wanted thorough data captured at approval time. Applying Module 3's conflict-navigation framework: the underlying shared goal was accurate, healthy business tracking — the resolution kept submission lightweight while requiring full justification only for discounts crossing the VP-escalation threshold, satisfying both genuine underlying needs without simply picking a side.
Phase 3 of 7
Process Mapping & Gap Analysis
The validated findings from Phase 2 get translated into a visual As-Is/To-Be process map, then rigorously checked against genuine Salesforce platform capability through a structured Fit-Gap workshop.
📚 Modules Used in This Phase
Module 5 (swimlane diagrams, the traceable As-Is to To-Be improvement discipline), Module 6 (the 3 gap categories, the Effort vs Value prioritization framework, the Fit-Gap workshop structure with a real technical expert).
| To-Be Element | Fit/Gap Category | Priority |
|---|---|---|
| Auto-route by discount threshold | Configuration Gap (standard Approval Process) | Quick Win |
| Display real-time approval status | Configuration Gap (Highlights Panel field) | Quick Win |
| Permanent audit log of every decision | Configuration Gap (Master-Detail + Roll-Up, recall Module 8) | Quick Win |
| Proprietary 7-factor risk-scoring model | Customization Gap (genuinely unique business logic) | Reconsider — deferred as fast-follow |
🛠️ The Genuine Technical Grounding Behind This Gap Analysis
The audit log requirement was confirmed as a Configuration Gap specifically because it needs a Roll-Up Summary showing pending discount value on the parent Opportunity — which, per Module 8's reasoning, requires a Master-Detail relationship between Discount_Request__c and Opportunity. This was explicitly flagged and confirmed acceptable with the VP during the Fit-Gap workshop, including the cascade-delete implication that comes with it.
⚠️ The Deferred Gap, Handled Honestly
The risk-scoring model was communicated to the VP using Module 6's full honesty framework: stated plainly as genuinely needing custom development, with the specific technical reason (proprietary, business-unique logic) explained, a realistic timeline impact quantified, and a constructive path forward offered — treated as a fast-follow after initial launch, not a launch blocker.
Phase 4 of 7
Formal Documentation — BRD/FRD
Everything validated so far gets formalized into signed-off documentation — grounded in genuine data model reasoning and visually validated through wireframing before a single line of automation gets built.
📚 Modules Used in This Phase
Module 7 (BRD/FRD structure, shall/must precision, full traceability), Module 8 (the Master-Detail relationship justification, the Picklist-over-Text reasoning for Rejection Reason), Module 9 (the wireframe, properly zone-labeled and annotated).
BRD EXCERPT — Executive Summary & Scope
EXECUTIVE SUMMARY: Currently, large customer discounts above
20% are approved through an informal, untracked email process,
leading to inconsistent decision-making and no audit trail.
This project implements a formal, automated approval workflow
within Salesforce, ensuring consistent governance and full
visibility into discount decisions.
IN SCOPE: Automated approval routing by threshold; real-time
status visibility; permanent audit trail of all decisions.
OUT OF SCOPE: The proprietary 7-factor risk-scoring model
(deferred fast-follow per Phase 3's Gap Analysis).FRD EXCERPT — Traced, Technically-Grounded Requirement
FR-001: The system shall automatically route a Discount Request
to the Sales Manager when the discount is 15-30%, and to the
VP of Sales when the discount exceeds 30%.
[Traces to BRD Objective: Ensure consistent governance]
DATA REQUIREMENTS: New object Discount_Request__c, Master-Detail
to Opportunity (enables Roll-Up Summary of pending discount
value — Module 8 reasoning). Field Rejection_Reason__c as
Picklist, not Text (enables reliable reporting — Module 8).🛠️ The Complete Traceability Chain
FR-001 traces back to the BRD's "consistent governance" objective, forward to User Story US-001 ("As a Sales Rep, I want my request auto-routed..."), and forward again to Test Case TC-001 ("verify correct routing at 15%, 20%, 30% thresholds") — the exact 4-column Traceability Matrix discipline Module 7 built, now applied genuinely end-to-end.
⚠️ Sign-Off Done Properly
This BRD/FRD was circulated to the VP a full week before the formal sign-off meeting, with explicit direction toward the Scope and Success Criteria sections — never a same-day "please approve" request. The VP's questions during review (specifically about the audit log's cascade-delete implication) were exactly the kind of substantive pushback Module 7 said a genuine sign-off process should welcome, not avoid.
Phase 5 of 7
Backlog & Sprint Execution
The signed-off FRD gets translated into an organized, build-ready backlog, and that backlog gets executed through real Scrum ceremonies — with the BA reading the actual build output to verify it genuinely matches what was specified.
📚 Modules Used in This Phase
Module 10 (reading the Approval Process configuration against the original RACI), Module 11 (Epic organization, the complete build-ready story package), Module 14 (Sprint Planning prep, Backlog Refinement, the BA's Standup updates).
| Epic | Story | Sprint |
|---|---|---|
| Approval Workflow | US-001: Auto-route by discount threshold | Sprint 1 |
| Approval Workflow | US-003: Approve/Reject actions with notification | Sprint 1 |
| Audit & Compliance | US-002: Permanent audit log of all decisions | Sprint 2 |
| Future Enhancement | US-007: Risk-scoring model (deferred Gap) | Backlog — not yet scheduled |
BUILD VERIFICATION — Module 10's reading skill, applied live
Reviewing the built Approval Process against the original RACI
(Phase 2): the Admin's first build had only ONE approval step
with a single approver type.
CAUGHT MISMATCH: this did not match the documented two-tier
structure (Sales Manager at 15-30%, VP above 30%) — exactly the
kind of finding Module 10 taught catching BEFORE formal UAT,
not after. Root cause: the original story slightly under-specified
the escalation tier. Logged and corrected before Sprint Review.🛠️ A Genuine Standup Update from This Sprint
"Yesterday I confirmed the two-tier approval threshold with the VP — no more ambiguity there. Today I'm finalizing the updated Acceptance Criteria and reviewing the corrected Approval Process build. No blockers." — exactly Module 14's brief, specific standup discipline.
Phase 6 of 7
UAT, Launch & Adoption
Technical verification (Phase 5) confirms the build matches the spec. Now real business users — the same stakeholders from Phase 1's map — confirm it genuinely solves their actual problem, followed by a deliberate rollout ensuring the solution is not just built, but genuinely used.
📚 Modules Used in This Phase
Module 12 (test scripts traced from Acceptance Criteria, the Bug/Missed Requirement/New Request triage, concrete Exit Criteria), Module 13 (the pre-launch communication plan, Champion identification, post-launch adoption measurement).
| UAT Finding | Triage Category | Resolution |
|---|---|---|
| 25% request routed to VP, not Sales Manager | Bug — contradicts signed-off AC | Fixed before launch (was the Phase 5 mismatch, re-verified) |
| No way to edit a request before approval | Missed Requirement | Logged for fast-follow sprint, not launch-blocking |
| "Could we add a Slack notification too?" | New Request | Added to backlog (Module 11), not urgent |
PRE-LAUNCH COMMUNICATION — connected to the original pain point
"Starting next month, discount approvals are moving out of
email and into Salesforce directly. If you've ever lost track
of a pending approval or had to chase someone down, this is
built specifically to fix that — you'll see exactly where your
request stands at every step, automatically."🛠️ The Champion Strategy
A genuinely engaged Sales Rep from UAT, who asked thoughtful questions and seemed naturally enthusiastic about the fix, became the rollout Champion — exactly Module 13's "choose based on genuine peer credibility, not formal authority" principle. Their authentic peer endorsement carried more weight with hesitant colleagues than any message from the BA or VP could.
⚠️ Two Weeks Post-Launch — The Honest Adoption Check
A usage report confirmed 80% of Sales Reps had submitted at least one request through the new system, with zero confirmed instances of approval emails still circulating outside it — a genuine adoption success, actively measured per Module 13's discipline, not assumed from an absence of complaints.
Phase 7 of 7
Reflection — The Complete Journey
Let us trace this single, continuous project one final time, module by module, exactly as Module 11's Concept 7 taught — to see the complete, connected practice this entire course has built.
| Module | What It Contributed to This Capstone |
|---|---|
| M1 — Lifecycle | The overall Discovery→Hypercare structure this entire Capstone followed |
| M2-M3 — Elicitation & Stakeholders | The validated synthesis findings and the RACI navigating the Sales-Finance conflict |
| M4 — User Stories | Every Acceptance Criterion underpinning the FRD and test scripts |
| M5-M6 — Process Mapping & Gap Analysis | The As-Is/To-Be map and the honest, categorized Fit-Gap findings |
| M7 — BRD/FRD | The signed-off, fully traced formal documentation |
| M8-M9 — Data Model & Wireframing | The Master-Detail justification and the visually validated record page |
| M10-M11 — Reading Tools & Backlog | The caught approval-tier mismatch and the organized, build-ready Epics |
| M12-M14 — UAT, Adoption & Scrum | The triaged findings, the Champion-driven launch, and the Sprint rhythm executing it all |
🛠️ Your Final Challenge
Do not just read this Capstone — build your own complete version, end to end, for a project of your own genuine choosing. Write the real stakeholder map, conduct real (or realistic, imagined) interviews, draft the actual BRD/FRD, build the actual backlog, and write the actual test scripts. That extension, built entirely using only what this course taught you, is the real, portfolio-ready proof you have genuinely mastered the Salesforce Business Analyst practice.
⚠️ One Last, Honest Note
A real XYZ Company project would also need deeper compliance review, more extensive edge-case testing, and likely several rounds of stakeholder negotiation this Capstone deliberately kept focused rather than exhaustive. Treat this as a strong, complete foundation — and the natural next step in your real growth as a Salesforce Business Analyst.
☕
☕ Enjoyed this article?
SF Interview Pro is 100% free and maintained by a Salesforce professional. No ads, no paywalls, and no signup required. If this guide helped you prepare for an interview, earn a certification, or grow your Salesforce career, consider buying me a coffee! ☕💜
🇮🇳 UPI (India)
Pay by QR
GPay · PhonePe · Paytm · BHIM
New interview questions every week 🚀
Follow for fresh Salesforce Q&A, free courses, and real interview experiences — straight from the trenches.
👥 Follow on LinkedIn