Building a Self-Service Scholarship Status Tracker

BackgroundContext and Problem

The client is a nationally recognized nonprofit foundation focused on scholarship funding and athlete development programs. Every year, the foundation manages a competitive scholarship application cycle that draws applicants from across the country, students who have worked hard to put together an application and are understandably anxious about where they stand.

The problem was straightforward but significant. Once a student submitted an application, they had no way to check in on it. No portal and no automated confirmation beyond the initial submission.

Students emailed the foundation asking for status updates. Staff would then pull up the relevant Salesforce record, manually check the application status, and write out an individual response.

Hours were being pulled away from staff that should have gone toward reviewing applications, communicating with donors, and running the program.

My ContributionRole and Responsibilities

I owned the discovery, solution design, configuration, testing, and delivery from start to finish.

My specific responsibilities included:

• Auditing the existing application intake and case management process in Salesforce to understand how records were structured and where statuses lived
• Designing the end-to-end solution architecture, including the unique identifier logic, the status lookup mechanism, and the email response framework
• Building all components natively in Salesforce with no third-party apps or additional licensing required
• Ensuring the solution was documented and maintainable by non-technical staff after handoff

How It Was BuiltProcess

I spent time understanding the organization's operations. The key design decision came early: applicants needed a way to look themselves up without the foundation exposing sensitive applicant data. I decided to assign each applicant a unique, auto-generated scholarship reference number at the point of submission. This became the single key that connected a student to their record, without requiring them to log in or verify identity in ways that would add friction or overhead for staff.

From there, I built a lightweight web form, accessible from a link, where a student could enter their scholarship number at any point after submitting. With the logic mapped, the flow looked like this:

A few design choices shaped the implementation. I kept the lookup mechanism inside native Salesforce Flow to avoid any external dependency. The entire process lives inside the org and does not require middleware or an API integration to maintain. Status language in the outbound email was written to be clear and reassuring; the goal was not just to close a ticket, it was to give a student an experience that reflected how much the foundation values them as an applicant. I also built the Flow logic to handle edge cases: invalid reference numbers, applications not yet in the system, and statuses that did not yet have a meaningful update to share.

What Was DeliveredSolutions and Deliverables

The final system had four primary components, all built natively within Salesforce:

Together, these four components replaced a manual, staff-dependent process with a zero-touch system that requires no intervention unless something genuinely exceptional happens.

OutcomesImpact and Results

The most immediate outcome was the drop in inbound email volume. Status inquiry emails fell by approximately 90% after the system went live. Staff got that time back, and they were able to prioritize reviewing applications and deepening donor relationships.