Scenario 02: BrightFuture Foundation

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Scenario Snapshot

Field	Detail
Start here	This question page
Difficulty	Beginner
Industry	Education and Nonprofit
Heavy domains	Integration and Data
Recommended prep time	150 minutes total: 90 min preparation + 30 min presentation + 30 min Q&A
Coverage available	Question + Solution
Study flow	Attempt this page first, then review the sibling solution page after your own attempt.

Recommended Approach

Print this scenario. Read it twice using the Two-Pass Reading Method: first for understanding and a second time specifically hunting for implicit requirements. Then build your architecture within a focused 90-minute prep window before presenting.

Project Overview

BrightFuture Foundation is a nonprofit running after-school tutoring and enrichment programs for students in low-income communities across three cities in the Pacific Northwest. The organization was founded 11 years ago with a single program site; it now operates 18 sites across Seattle, Portland, and Spokane. Funding comes from a mix of individual donors, corporate sponsors, and state grants. Programs serve students from grades K through 12 with tutoring, STEM clubs, and arts programming running Monday through Friday after school hours.

Attribute	Detail
Full-time staff	42 (12 program staff, 8 fundraising, 6 operations, 8 admin, 4 tech, 4 leadership)
Regular volunteers	~310 active (tutors, mentors, event helpers)
Program sites	18 across Seattle, Portland, and Spokane
Students enrolled	~2,400 per school year
Annual budget	$3.1M (45% individual donors, 25% corporate, 22% state/federal grants, 8% events)
Donor records	~28,000 total (active and lapsed)

The Executive Director has secured a $380,000 implementation budget over 14 months to consolidate three disconnected tools onto Agentforce Nonprofit (formerly Nonprofit Cloud). The goal is a single system of record for constituents, programs, and fundraising that allows staff to answer questions about impact without pulling data from multiple places.

Stakeholder Quotes

Maria Chen, Executive Director: “Right now I cannot tell you how many of our donors are also volunteers without asking three different people to each pull a report and manually combine them. We have people who give us $5,000 a year and also tutor twice a week, and they exist as two completely separate contacts in two systems with no connection between them. That has to change.”

David Okonkwo, Programs Director: “Enrollment is tracked in a spreadsheet shared over Google Drive. If two site coordinators edit it at the same time we end up with conflicting versions. I have had situations where a student showed up on the first day and there was no record of their enrollment at all because it got overwritten. We also have no consistent way to track attendance after students are enrolled. Each site does it differently.”

Rosa Fuentes, Development Manager: “We send about 4,000 emails a month through Mailchimp. The list is manually exported from our donor database every time, which takes about two hours because the export format does not match what Mailchimp needs. And when someone unsubscribes in Mailchimp, we have no way to know unless we log in and check. That information never makes it back to the donor record.”

Current Systems and Pain Points

Donor Database (Little Green Light)

Little Green Light (LGL) is a cloud-based donor management tool used by small nonprofits. BrightFuture has used it for 6 years and has ~28,000 constituent records: individual donors, corporate contacts, foundation contacts, and a small number of volunteers who were also tracked as donors.

Data volumes: 28,000 contacts, ~41,000 gift records going back 6 years, ~800 recurring gift records.

Pain points:

• No API access on the current pricing tier; all data exports are manual CSV downloads.
• Recurring gift records are tracked as notes rather than structured data, making reporting unreliable.
• About 4,200 records have a volunteer flag set manually, but the volunteer data itself lives in a separate system with no structured link.
• Field-level data quality is inconsistent: roughly 15% of records have missing or malformed phone numbers, and about 8% have no valid email address.

Volunteer Tracking (VolunteerLocal)

VolunteerLocal is a SaaS platform used to manage volunteer sign-ups, shift scheduling, and hour tracking. Site coordinators post shifts; volunteers register online. Hour logs are kept within VolunteerLocal, and coordinators download a monthly CSV to compile the organization’s total volunteer impact report.

Data volumes: ~310 active volunteers, ~4,800 shift records per year, ~9,200 logged volunteer hours per year.

Pain points:

• Volunteer records and donor records are maintained separately with no automated matching. Staff manually cross-reference by name and email to identify overlap, a process that takes 3-4 hours each quarter.
• No webhook or API access for outbound events on the current subscription tier.
• No attendance tracking capability: shifts are confirmed as complete by coordinators, but individual no-shows are not consistently logged.
• VolunteerLocal has no integration with Mailchimp, so volunteer-specific communications require a separate manual export.

Program Enrollment (Google Sheets)

Program enrollment and student attendance are tracked in a shared Google Sheets workbook. Each site coordinator maintains tabs for their own site. A central admin manually consolidates all site tabs into a summary workbook each month.

Data volumes: ~2,400 active student enrollments per school year, ~18,000 attendance records per month across all sites.

Pain points:

• No access control below the workbook level: all coordinators can see all sites’ data.
• Version conflicts occur several times per semester when coordinators edit simultaneously.
• The consolidation step takes approximately 4 hours each month and is fully manual.
• No structured link between student/family records and donor records, even though some families are also donors.

Business Requirements

Unified Data Model

1. All constituent records (donors, volunteers, corporate contacts, grant contacts, and enrolled families) must be managed in a single system with a unified contact and account model.
2. A constituent who is both a donor and a volunteer must exist as one record. The solution must support a single person having both a giving history and a volunteer history without creating duplicate records.
3. Deduplication logic must handle name variations (e.g., “Robert” vs. “Bob”), mismatched email addresses, and cases where the same person appears in all three source systems with slightly different contact details.
4. After migration, constituent records must carry a complete history: all gifts from LGL, all volunteer shifts from VolunteerLocal, and any program enrollment connections where families are linked to donor records.
5. Recurring gift data currently stored as notes in LGL must be converted into structured recurring donation records with amount, frequency, next payment date, and payment method type.
6. Constituent records must support soft credits to track matching gifts from employers and credit gifts made jointly by household members.

Integration Architecture

7. Stripe payment processing must be connected via webhook so that when a donor completes a gift on the public donation page, a gift record is created or updated in Salesforce within 2 minutes with no manual import step.
8. Stripe webhook events must include: successful payment, failed payment, recurring gift created, recurring gift canceled, and payment method updated.
9. When a Stripe webhook event arrives for a donor email that already exists in Salesforce, the gift must be attached to the matching contact. When no match exists, a new contact record must be created automatically with a flag for staff review.
10. Mailchimp must stay connected as the email delivery platform. Audience segments in Mailchimp must be driveable from Salesforce so that staff can build a segment in Salesforce and have it available for a Mailchimp campaign without a manual export step.
11. When a subscriber unsubscribes or hard-bounces in Mailchimp, that status must update the corresponding Salesforce contact within 24 hours so that the contact is not included in future campaign audiences.
12. All integration error events (failed webhook deliveries, unmatched Stripe contacts, Mailchimp sync failures) must be visible to the admin team in a single place with enough detail to resolve the issue manually if needed.

Program Management

13. Program enrollment must move from Google Sheets into Salesforce. Each enrollment record must link a student to a specific program, site, school year, and enrollment status (enrolled, waitlisted, withdrawn, completed).
14. Attendance must be recorded at the student-program level with a date and a present/absent flag. Site coordinators must be able to record attendance for their own site without seeing other sites’ enrollment data.
15. Program outcomes tracking must support at minimum: pre and post reading level assessment scores per student, attendance rate calculation, and a program completion flag at the end of each school year.
16. The Programs Director must be able to see a consolidated view across all 18 sites without manually combining any data.

Reporting and Analytics

17. The Executive Director needs a dashboard showing: total active donors this year vs. last year, total volunteer hours this year vs. last year, students currently enrolled, and year-to-date funds raised against target, all in one view without navigating to multiple reports.
18. The Development team needs a donor retention report showing donors who gave last year but have not yet given this year, segmented by gift size range, so that lapsed donor outreach can be prioritized.
19. The Programs team needs a monthly attendance summary per site showing attendance rate by program, with the ability to drill into individual student records for any student below 70% attendance.
20. Impact reporting must connect giving to program delivery: for a given school year, show total dollars raised, total students served, and total volunteer hours contributed, with the ability to break this down by city.
21. Grant reporting must be supported by the data model: grant funders require a report each quarter showing student enrollment counts, attendance rates, and outcome scores for the programs their grant funds. The solution must make it possible for staff to pull this data without custom development for each funder.
22. Volunteer impact reports must show total hours by volunteer, hours by site, and hours by program type, and must be exportable so that volunteers who need documentation for employer matching or school service hours can receive a letter or PDF summary.

Constraints

• Total implementation budget is $380,000, covering licenses, implementation services, and any third-party tools. There is no contingency budget.
• Go-live must occur before the start of the next school year enrollment period, which opens in approximately 11 months. The enrollment workflow in Salesforce must be ready before that window.
• The technology team is four people: one Salesforce admin (6 months of Salesforce experience), one general IT staff member, and two part-time contractors. There is no in-house developer.
• Staff training time is limited. Site coordinators and program staff are not technical users. Any solution requiring more than two hours of onboarding per staff member will face adoption resistance.
• BrightFuture is a 501(c)(3) and qualifies for the Salesforce Power of Us program (10 free Agentforce Nonprofit CRM licenses on Enterprise Edition). Additional licenses or add-ons must fit within the stated budget.
• The organization cannot afford a migration-related outage during the end-of-year giving campaign (November 15 through December 31). Any cutover that touches the donation workflow must happen outside this window.

Implicit Requirements

Watch for these areas when building your solution:

• Constituent deduplication scope: The three source systems will have overlapping records with no shared unique identifier. A survivorship rule and a merge strategy must be part of your solution, not an afterthought.
• No developer on staff: Any custom code or Apex will need an implementation partner for both build and future maintenance. Declarative-first design is not just a preference here; it is a staffing constraint.
• Stripe is event-driven, Mailchimp is not: These two integrations need different patterns. Stripe sends webhooks; Salesforce must listen and process. Mailchimp is queried or pushed on a schedule. Treat them differently.
• Data privacy for minors: Student enrollment records contain information about minors. Sharing model and access controls must ensure that student records are not visible to volunteers or donors who have no program affiliation.
• Agentforce Nonprofit data model: The scenario calls for Agentforce Nonprofit (formerly Nonprofit Cloud). The constituent model (Household Accounts, Contacts, Opportunities for gifts) differs from standard Salesforce. Your architecture should reflect this, not ignore it.

Deliverables Checklist

Prepare the following before reviewing the solution page:

• Data model diagram showing key objects and relationships (constituents, gifts, volunteer records, program enrollments, integrations)
• Integration architecture diagram showing Stripe webhook flow and Mailchimp sync flow with directionality and error handling
• Deduplication and migration strategy: source systems, matching rules, survivorship logic, cutover sequence
• Sharing and access model: who can see what, particularly program staff, site coordinators, volunteers, and the development team
• Constituent model decision: Agentforce Nonprofit Household Account model, with rationale
• Key assumptions you made and which implicit requirements you identified unprompted

Time Management: 150-Minute Practice Session

Prep , first 30 min: Read the scenario once for understanding. Read it again marking implicit requirements. Sketch your data model and integration flows on paper before building diagrams.

Prep , middle 30 min: Design your architecture. Settle the constituent model (Agentforce Nonprofit Household Account), the deduplication strategy, and the two integration patterns (Stripe webhook vs. Mailchimp scheduled sync).

Prep , final 30 min: Build your artifacts. Prioritize the data model diagram, integration architecture diagram, and sharing model , these are the most likely presentation targets.

Presentation (30 min): Walk through your architecture as if presenting to the review board. Cover data model, integration design, migration approach, and access model. Keep each section to 5-6 minutes.

Q&A (30 min): Anticipate questions on: deduplication edge cases, what happens when a Stripe webhook arrives for an unknown email, how you handle student data privacy, and why you chose Agentforce Nonprofit as the platform.

Ready to Check?

When you have completed your own solution, compare it with the reference solution.

Related Topics

• Two-Pass Reading Method
• 9 Essential Artifacts
• Mini-Scenario Library
• Domain 3: Data
• Domain 5: Integration

---

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.