Use Cases & Implementation Patterns

This section discusses the use cases for Scholar Snapp integration and their related integration patterns.

The Snapp Central API is flexible and allows you to import from Snapp or export to Snapp at any point in the scholarship application lifecycle. However, each use case represents a different scenario that comes with special concerns and considerations. The canonical use cases are:

The various aspects are discussed below.

Use Case 1. Application Start (Import from Snapp)

In this use case, your application will provide a means of importing a Snapp Profile before the student starts filling out your program's application form.

An applicant starting a new application on your website is a great opportunity to connect to the Snapp Central API. If the applicant already has a Snapp Profile built up, they can almost certainly fill in core data (like their name, contact information, demographic information), and may be able to auto-populate other fields (such as essays, ACT and SAT scores, GPA, financial information, etc.).

Which scholarship application systems benefit from this use case?

• Applications that collect "typical" data, such as name, contact information, academic history, financial information, essays, and similar. A student can potentially auto-fill a significant portion of this common information from their Snapp profile.
• Applications that start relatively late in the yearly cycle. Many scholarship providers push data to Snapp at application completion time. This means that students' Snapp Profiles accrue more and more data as the application season progresses.

Which scholarship application systems may not benefit from this use case?

• Applications that have largely unique data requirements. If the only "typical" thing about your scholarship application is that you ask for the student's name, then students will not see a lot of benefit from importing from Snapp.
• Applications that start and end very early in the year. Students who use Snapp benefit from a network effect: as time passes, more data can be populated in their Snapp Profile. This means that applications that start relatively early (e.g., late summer, early fall) will likely serve students who have not yet built up enough of a Snapp Profile to populate your application.

Use Case 2. Application In Progress - Import (Import from Snapp)

In this use case, your application offers a means to pull data from Snapp, potentially adding new data or merging updated data, at any point in your application's process.

Most application forms are completed over multiple visits. Students gather information like their transcript, FAFSA form, SAR, and so forth over time, and save their work as they progress. Since applicants do this in multiple application forms, they can leverage the new data entered in another application back into your application.

Which scholarship application systems benefit from this use case?

• Application systems that have complex, time-consuming, common data points that tend to be entered in batches. The FAFSA, transcript, and essay data points in the Snapp Profile are all good examples.

Which scholarship application systems may not benefit from this use case?

• Application systems that do not have adequate analysis and development capacity. Merging Snapp Profile data with existing data in a partially completed application form isn't rocket science – but it does take analysis to figure out when to add information, when to overwrite existing information with new data, and so forth. It takes programming time to implement and test the merging process, and some user interface and user experience development time to ensure that the applicant has appropriate control over and feedback about the process. So, we don't want to discourage you from implementing this use case – just be aware of what you're getting into.

Use Case 3. Application In Progress - Export (Export to Snapp)

In this use case, your application offers a means to send data back to Snapp – thus allowing a student to reuse new information in other programs' scholarship application forms.

Which scholarship application systems benefit from this use case?

• Application systems that have complex, time-consuming, common data points that tend to be entered in batches. The FAFSA, transcript, and essay data points in the Snapp Profile are all good examples.

Which scholarship application systems may not benefit from this use case?

• Application systems with online forms that are completed relatively quickly.
• Application systems that only collect summary data.
• Use Case 2, above, notes the potential difficulties in merging new data into an existing application. From your perspective, this use case – which sends data to Snapp – is much easier. In this case, the Snapp Central API has the responsibility to merge the data thoughtfully and correctly. However, this use case does require a non-zero amount of user interface and user experience work, so those applications with limited development resources may not find this appropriate for their situation.

Use Case 4. Application Completion (Export to Snapp)

In this use case, your application offers a means to send data back to Snapp – thus allowing a student to populate their Snapp Profile with the most data that your application can provide.

Which scholarship application systems benefit from this use case?

• We encourage every scholarship provider to implement this use case – even if they implement no others.
• This is where your scholarship program can really do a solid for your applicants. Further, it's the technically easiest – you simply have to package up and emit your data.

Which scholarship application systems may not benefit from this use case?

• None.

Use Case 5. Application Status Change (Export to Snapp)

In this use case, your application provides an opportunity to export data to Snapp in the context of notifying a scholar about a change in status. For example, no scholarship provider wants to send the "We regret to inform you that your application has been declined. With so many excellent candidates..." e-mail, but every scholarship provider does it. This use case provides a means to connect candidates with other scholarship opportunities.

Which scholarship application systems benefit from this use case?

• Scholarship programs that provide a notification about a status change, e.g., that an application has been declined.

Which scholarship application systems may not benefit from this use case?

• Scholarship programs that don't notify students about a change in status, e.g., that an application has been declined.
• Scholarship programs that close their online presence as soon as the application period has elapsed.