Solution 02: BookBridge Education Foundation

AI-Generated Content — Use for Reference Only

This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.

Solution Context

Heavy domains: D5 Integration, D6 Dev Lifecycle | Difficulty: Beginner Time budget: 180 minutes | Key frameworks: 9 Essential Artifacts, Five-Finger Method

Attempt the Scenario First

If you have not yet worked through the scenario paper, stop here. Set a 180-minute timer and build your own solution before reading this one.

Assumptions

Salesforce Nonprofit Cloud (NPC) — current-generation platform built on Industries Cloud (not legacy NPSP). Pre-built donation management, constituent modeling, and grant tracking at nonprofit pricing
MuleSoft Composer for integration middleware — visual middleware for an 8-person team with no integration experience. Rejected Anypoint Platform (budget $1.2M/18 months cannot absorb enterprise licensing). Rejected point-to-point (6+ systems = 15 possible connections = unmaintainable)
Single Experience Cloud site for school and volunteer portals with audience-based visibility — reduces licensing cost vs two separate sites
Retain Stripe for payment processing — working system, no benefit to replacing during migration
Keep ShelfTrack Cloud as the warehouse system — working SaaS with documented API; integrate, do not replace

Key Architectural Decisions

Decision 1: Hub-and-Spoke Integration (D5 — HEAVY)

MuleSoft Composer as the central hub because BookBridge has 6 systems with different protocols and anticipates adding 2-3 per year (Req 41). Every system connects to the hub, not to each other. Adding a new system requires one connection.

System	Protocol	Pattern	Direction	Volume
Stripe	Webhooks + REST	Event-Driven	Inbound	2K-12K/day
ShelfTrack	REST v3.1 + Webhooks	Event-Driven + Polling	Bidirectional	~4,700/day
School Districts	SFTP + CSV	Batch ETL	Inbound	Monthly (15 districts)
QuickBooks	REST + OAuth 2.0	Scheduled Batch	Outbound	Weekly
MailChimp	REST v3.0 + Webhooks	Event-Driven + Batch	Bidirectional	~2.5M emails/mo
Eventbrite	REST + Webhooks	Event-Driven	Inbound	~120 events/yr

Judge Signal

Judges want each integration classified by protocol, pattern, and direction. Saying “we’ll integrate everything with MuleSoft” without this breakdown will fail. They also want to see the SFTP challenge addressed specifically — it is a different protocol class from REST.

Decision 2: SFTP Staging Pipeline (D5)

Composer with staging object pattern for the 15 district SFTP feeds, each in a different format (Req 36).

Composer connects to each district’s SFTP on schedule
District-specific transformation mapping (15 mappings) transforms files
Records land in District_Data_Staging__c staging object
Validation Flow checks for anomalies (>50% student count drop, missing fields)
Clean records promote to production School__c; flagged records route to manual review

Staging decouples ingestion from consumption — a bad file is contained in staging, not production. Note: if 15 mappings exceed Composer’s capabilities, escalate to Anypoint for this integration while retaining Composer for simpler REST integrations.

Decision 3: Year-End Campaign Resilience + Environment Strategy (D5 + D6 — HEAVY)

Async event-driven donation processing for the year-end spike (12K/day, ~750/hour): Stripe webhooks received by Composer, pushed as Platform Events into Salesforce with built-in replay (72-hour retention). Migration must NOT happen during November-January — recommend spring cutover with old GiveHub running through one complete year-end cycle.

4-environment strategy with DevOps Center for a team new to Salesforce development (grew from 3 to 8 in 6 months):

Environment	Type	Purpose
DEV (x3)	Developer Pro Sandboxes	Individual developer work
QA/TEST	Partial Copy	Integration testing, QA validation
UAT	Partial Copy	Business stakeholder acceptance
PROD	Production	Live system

Chose DevOps Center over custom CI/CD (GitHub Actions + SFDX) because the team has zero prior experience. DevOps Center provides visual work item tracking and deployment pipeline as a stepping stone. 2-week release cadence with QA gate, UAT business approval, and rollback plan per release.

Judge Signal

Dev lifecycle judges want to see you acknowledge the team maturity gap. Prescribing enterprise-grade CI/CD for a team that just learned what a sandbox is will be viewed as tone-deaf.

Critical Diagrams

Integration Architecture (Hub-and-Spoke)

graph TB
    subgraph External["External Systems"]
        Stripe[Stripe]
        ST[ShelfTrack Cloud]
        SFTP[15 School Districts SFTP]
        QB[QuickBooks Online]
        MC[MailChimp]
        EB[Eventbrite]
    end

    subgraph Hub["MuleSoft Composer — Integration Hub"]
        DH[Donation Handler]
        WH[Warehouse Sync]
        ETL[District ETL]
        FIN[Finance Sync]
        ERR[Error Handler + Retry]
    end

    subgraph SF["Salesforce Nonprofit Cloud"]
        PE[Platform Events]
        Core[Core Objects]
        Staging[Staging Objects]
        EC[Experience Cloud Portal]
    end

    subgraph Legend
        direction LR
        NEW[🟢 NEW - Being Built]
        KEEP[⚪ KEEPING - No Changes]
        RETIRE[🔴 RETIRING - Decommissioning]
        INT[🟠 INTEGRATION LAYER]
    end

    Stripe -->|Webhooks real-time| DH
    ST <-->|REST + Webhooks bidirectional| WH
    SFTP -->|SFTP batch monthly| ETL
    QB <-->|REST scheduled weekly| FIN
    MC <-->|REST + Webhooks bidirectional| Hub
    EB -->|Webhooks event-driven| Hub

    DH -->|Platform Events| PE
    WH -->|Platform Events| PE
    ETL -->|Batch load| Staging
    FIN <-->|REST sync| Core
    PE --> Core
    Staging -->|Validation Flow| Core
    Core --> EC
    ERR -.->|Retry queue| DH

    style PE fill:#cce5ff,stroke:#0d6efd
    style Core fill:#cce5ff,stroke:#0d6efd
    style Staging fill:#cce5ff,stroke:#0d6efd
    style EC fill:#cce5ff,stroke:#0d6efd
    style DH fill:#fff3cd,stroke:#fd7e14
    style WH fill:#fff3cd,stroke:#fd7e14
    style ETL fill:#fff3cd,stroke:#fd7e14
    style FIN fill:#fff3cd,stroke:#fd7e14
    style ERR fill:#fff3cd,stroke:#fd7e14
    style Stripe fill:#e9ecef,stroke:#6c757d
    style ST fill:#e9ecef,stroke:#6c757d
    style SFTP fill:#e9ecef,stroke:#6c757d
    style QB fill:#e9ecef,stroke:#6c757d
    style MC fill:#e9ecef,stroke:#6c757d
    style EB fill:#e9ecef,stroke:#6c757d

CI/CD Pipeline

graph LR
    DEV[Dev Sandboxes x3] -->|Commit| GH[GitHub Feature Branches]
    GH -->|DevOps Center Promote| QA[QA Sandbox]
    QA --> AT{Tests Pass?}
    AT -->|Yes| UAT[UAT Sandbox]
    AT -->|No| DEV
    UAT --> BIZ{Stakeholder Approval?}
    BIZ -->|Approved| PROD[Production]
    BIZ -->|Rejected| DEV

    style QA fill:#e3f2fd,stroke:#1565c0
    style PROD fill:#fce4ec,stroke:#c62828

Identity & SSO Flow

sequenceDiagram
    participant Staff as BookBridge Staff
    participant Browser as Browser
    participant Google as Google Workspace<br/>(IdP)
    participant SF as Salesforce NPC

    Staff->>Browser: Navigate to Salesforce
    Browser->>Google: Redirect (SP-initiated SAML 2.0)
    Google->>Google: Authenticate (Google MFA)
    Google->>Browser: SAML Assertion (Federation ID = Google email)
    Browser->>SF: POST SAML to ACS URL
    SF->>SF: Match Federation ID → User record
    SF->>Browser: Session Cookie + Redirect

sequenceDiagram
    participant ExtUser as School Partner /<br/>Volunteer
    participant Browser as Browser
    participant SF as Experience Cloud Portal

    ExtUser->>Browser: Navigate to Portal
    Browser->>SF: Login page (email + password)
    SF->>SF: Authenticate (optional MFA)
    SF->>SF: Assign portal profile<br/>(School Partner or Volunteer)
    SF->>SF: Apply sharing: audience-based visibility
    SF->>Browser: Session Cookie + Portal Home

SSO Design Rationale

Internal staff (120 employees): SAML 2.0 SP-initiated SSO via Google Workspace (standard for nonprofits using Google for Nonprofits). Google handles MFA. Federation ID is the Google email address. If BookBridge later moves to Microsoft 365 or Okta, only the IdP metadata needs updating.

School partners and volunteers: Username/password through Experience Cloud (single site with audience-based visibility). School contacts submit book requests and track shipments; volunteers view participation history and download hour certifications. No SSO for external users — the diverse partner base (2,500 schools, 800 volunteers) makes a shared IdP impractical. Self-registration with email verification is enabled for new school contacts.

Integration Error Handling

Each integration has specific error handling tailored to its pattern, volume, and business criticality.

Integration	Pattern	Retry	DLQ	Monitor	Fallback
Stripe → Donations	Webhook → Composer → Platform Event	3x exponential (2s, 15s, 120s)	`Integration_Error__c` with full Stripe payload + event ID	Email alert to tech team on 3rd failure; Slack notification for >10 failures/hour	Stripe retries webhooks for up to 72 hours; Platform Event replay (72-hour window); manual reprocess UI
ShelfTrack (bidirectional)	REST + Webhooks via Composer	3x exponential (5s, 30s, 300s)	`Integration_Error__c` with payload + ShelfTrack transaction ID	Daily digest of failed syncs to warehouse manager + tech team	Queue failed records; ShelfTrack webhook retry (configurable); manual reconciliation report
School Districts SFTP	Batch ETL via Composer → Staging object	1 automatic re-fetch per district after 24 hours	`District_Data_Staging__c` with `Status__c = Validation_Failed`	Monthly summary of failed/flagged records to programs team	Bad files quarantined in staging; clean records still promote; manual review queue for anomalies
QuickBooks (outbound)	Scheduled batch REST via Composer	2x retry (immediate + 1 hour)	`Integration_Error__c` with journal entry payload	Email to finance director on any failure (weekly financial data is sensitive)	Finance team manually enters weekly summary CSV (current process) as interim fallback
MailChimp (bidirectional)	REST + Webhooks via Composer	3x exponential (5s, 30s, 120s)	`Integration_Error__c` with contact/campaign IDs	Weekly digest of sync failures to marketing team	Segments can be manually exported as CSV (current process) while integration is restored
Eventbrite (inbound)	Webhooks via Composer	3x exponential (2s, 15s, 120s)	`Integration_Error__c` with event/attendee payload	Alert on registration sync failures during active event windows	Eventbrite retains all data; manual CSV export available; volunteer hours tracked in backup Google Sheet per city

Year-End Campaign — Elevated Monitoring

During December 15-31 (year-end campaign, up to 12K donations/day), the Stripe integration monitoring threshold drops from 10 failures/hour to 3 failures/hour for immediate alerting. A dedicated on-call rotation covers the integration layer. Platform Event replay (72-hour window) provides the safety net — no donation data is lost even if processing is delayed.

Governance & DevOps

Environment Strategy

flowchart LR
    DEV1[Dev Sandbox 1<br/>Developer Pro] --> QA[QA / Integration<br/>Partial Copy]
    DEV2[Dev Sandbox 2<br/>Developer Pro] --> QA
    DEV3[Dev Sandbox 3<br/>Developer Pro] --> QA
    QA --> AT{Automated Tests<br/>+ QA Analyst}
    AT -->|Pass| UAT[UAT<br/>Partial Copy]
    AT -->|Fail| DEV1
    UAT --> BIZ{Business Stakeholder<br/>Approval}
    BIZ -->|Approved| PROD[Production]
    BIZ -->|Rejected| DEV1

    style QA fill:#e3f2fd,stroke:#1565c0
    style UAT fill:#fff3cd,stroke:#fd7e14
    style PROD fill:#fce4ec,stroke:#c62828

Sandbox Strategy

Sandbox	Type	Purpose	Notes
DEV-1, DEV-2, DEV-3	Developer Pro	Individual developer work (team of 8, 3 active sandboxes)	Seed data with synthetic donors, schools, inventory
QA/TEST	Partial Copy	Integration testing with Composer sandbox connections, QA validation	Connected to ShelfTrack staging, Stripe test mode, MailChimp test list
UAT	Partial Copy	Business stakeholder acceptance	Programs, fundraising, and warehouse staff validate workflows

Partial Copy (not Full Copy) for both QA and UAT is appropriate for BookBridge — the nonprofit budget ($1.2M) does not justify Full Copy licensing, and Partial Copy with sampled data provides sufficient test coverage for the data volumes involved.

Branching Strategy

main — production-ready; deploys to Production via DevOps Center
develop — integration branch; auto-deploys to QA sandbox
feature/[work-item]-description — individual feature branches in Dev sandboxes
Pull requests require 1 peer review (team is learning; reviews double as knowledge transfer)
Merges to main require QA analyst sign-off + business stakeholder UAT approval

Testing Strategy

Test Type	Environment	Scope	Criteria
Apex Unit Tests	Developer sandboxes	Custom Apex, triggers, batch jobs	>75% coverage; mock callouts for all Composer-invoked APIs
Integration Tests	QA	All 6 system connections via Composer sandbox	End-to-end data flow validated; error handling exercised
Load Testing	QA	Stripe webhook processing at peak volume	Simulate 12K donations/day (year-end); validate Platform Event processing
UAT	UAT	Donor management, book requests, volunteer workflows	Business users validate real-world scenarios; 3-day UAT per release

CoE / Post-Go-Live Governance

Team Growth Path: The 8-person tech team (from 3 six months ago) needs structure, not overhead. DevOps Center provides visual deployment tracking as a stepping stone. Plan to evaluate migration to GitHub Actions + SFDX at the 12-month mark once the team has foundational skills.

Release Cadence:

Standard releases: Bi-weekly (2-week sprints) aligned with DevOps Center work items
Hotfixes: Same-day path for critical defects (e.g., donation processing failures)
Blackout window: No production deployments November 1 through January 15 (year-end campaign + reconciliation period)

Onboarding: Development process documented in a runbook (Req 48) covering sandbox setup, branching conventions, deployment steps, and integration testing procedures. Target: new team member onboards within 5 business days.

Ongoing Governance: CTO reviews all integration changes; QA analyst gates all deployments; monthly tech debt review to prevent the “GiveHub problem” (undocumented, untested custom code) from recurring.

Requirements Addressed

✅ Unified constituent profiles — Single Contact record linking donor, volunteer, and event data (Reqs 1-2, 13)
✅ Zero-downtime donation processing — Stripe webhooks → Platform Events with 72-hour replay; spring cutover avoids December (Req 3)
✅ Hub-and-spoke integration — MuleSoft Composer central hub for 6 systems, extensible for 2-3 new/year (Reqs 33-40)
✅ SFTP district data ingestion — District-specific ETL mappings with staging object and validation (Reqs 20, 35)
✅ Book lifecycle tracking — Donation → warehouse → distribution chain linked via Composer sync with ShelfTrack (Reqs 8-12)
✅ School/volunteer portal — Single Experience Cloud site with audience-based visibility (Reqs 24, 26)
✅ Structured dev process — DevOps Center with 4-environment strategy; QA + stakeholder gates (Reqs 41-48)
✅ Donor deduplication — Fuzzy matching across GiveHub, MailChimp, and Eventbrite with survivorship rules (Reqs 16, 19)

Risk Assessment

Risk	Impact	Prob	Mitigation
Year-end donation processing failure	CRITICAL	MED	Async Platform Events with replay; no cutover Nov-Jan; load test at 2x peak (24K/day)
Team overwhelm (simultaneous process + platform change)	HIGH	HIGH	Phased rollout: environments first (Mo 1-2), core platform (Mo 3-8), integrations one-at-a-time (Mo 9-14)
SFTP format changes break ingestion	MED	HIGH	District-specific mappings isolated; staging object catches bad data; monitoring alerts on validation failures
GiveHub security vulnerability before decommission	HIGH	MED	Rails 5.2 EOL; implement WAF rules; accelerate Stripe-direct to reduce GiveHub to read-only

Domain Scoring Notes

D5 Integration (HEAVY): Classify EACH integration by protocol/pattern/direction/volume. Address SFTP separately from REST. Explain error handling per integration individually — “MuleSoft handles errors” is not sufficient.
D6 Dev Lifecycle (HEAVY): Design CI/CD for the team’s current maturity. Acknowledge the maturity gap. Include onboarding documentation, release process, and automated testing strategy (mock callouts in sandboxes).
D3 Data (MED): Unified constituent model — single Contact for a person who is both donor and volunteer (Req 13). Donor deduplication across 3 systems.
D1 System Arch (LIGHT): Mention Power of Us program (10 free licenses) to show budget awareness.

Reporting Approach

Standard Salesforce reports and dashboards cover the Executive Director dashboard (Req 27), campaign performance (Req 28), and grant funder reports (Req 32). The impact reporting chain (donation → books → schools → students, Req 29) requires cross-object report types linking Donation, Inventory, Distribution, and School records. The automated monthly reconciliation (Req 30) is a scheduled Apex batch comparing platform totals against Stripe settlements and QBO journal entries. If the board quarterly report (Req 31) or cross-system impact analytics demand more sophisticated visualization, consider CRM Analytics (included in some nonprofit bundles) for cross-source dashboards.

What Would Fail

Point-to-point integrations for everything — 6 systems growing to 9 means up to 36 connections. Req 41 explicitly requires accommodating new connections without re-architecture. Hub-and-spoke is the only defensible answer.
Treating SFTP the same as REST APIs — The 15 district feeds are batch, schema-less, and arrive on different schedules. Lumping them with REST integrations shows you did not read the scenario. Judges expect a specific staging and transformation strategy.
Prescribing enterprise CI/CD for a beginner team — Jenkins, GitHub Actions + SFDX, and feature-flag management for a team that was deploying to production manually 3 months ago is tone-deaf. Start with DevOps Center, then evolve.

Self-Scoring Checklist

Did I classify every integration by protocol, pattern, direction, and volume?
Did I justify middleware vs point-to-point with a specific rationale?
Did I handle the SFTP feeds differently from the REST APIs?
Did I design the CI/CD for the team’s current maturity level?
Did I avoid the December cutover window?
Did I present a unified constituent model (not separate donor/volunteer)?
Did I include error handling for each integration?