Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction to workflow 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 various aspects are discussed below.

Use Case 1. Application Start (Import from Snapp)

Define scenario.

Discuss when to use and not use this pattern.

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 profile in Snapp, 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 applications 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 applications 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 from Snapp)

Define scenario.

Discuss merging concerns w/in an application.

Discuss when to use and not use this pattern.

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

Define scenario.

Discuss how merge works on the Snapp side.

Discuss when to use and not use this pattern.

Use Case 4. Application Completion (Export to Snapp)

Define scenario.

Cover again how merge works on the Snapp side.

Discuss when to use and not use this pattern.

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

Define scenario, benefits.

Discuss when to use and not use this pattern.

Include Page
_Sidebar - Snapp Developer Toolkit
_Sidebar - Snapp Developer Toolkit