Importing Current Applicant Data
- 15 Nov 2023
- 7 minute read
- Print
- DarkLight
- PDF
Importing Current Applicant Data
- Updated 15 Nov 2023
- 7 minute read
- Print
- DarkLight
- PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Slate supports the uploading of current application data. However, prior to importing current application data, you may first wish to import current prospect data.
Segment Application Data
Import current application data the same way current prospect data was imported (separate uploads for core data, qualitative data, school data, etc.)
Additionally, it is best to include a separate upload for application-specific information (see segment F below). However, before beginning this process, configure an application period and application round in Slate.
Current Application Data |
|
|---|---|
A - Core Data | This upload establishes the base of the applicant record in Slate, including the unique field used as a key for subsequent data uploads. |
B - Qualitative Data | Once the unique field value is stored in Slate, that value becomes the only required data point needed to match additional information with a student record. |
C - School Data |
|
D - Test Score Data |
|
E - Interaction Data |
|
F - Application Data | This upload creates applications for person records. |
With data imports A-E, use the same procedure used for importing current prospect data.
Important
Don’t Skip A-E! Upload Core, Qualitative, School, Score, and Interaction data for applicants before uploading the remainder of application data. Earlier imports are intended to establish the base of the record, which will make importing application data more manageable.
Create a Unique Application-Scoped Field
Many institutions have a unique application ID stored in their external system. Creating a new application-scoped unique field in Slate to store this ID is the most effective way to import application information. Once a unique field exists, it can be used as a key to match external system records with internal Slate records. To create this unique application field:
Select Database on the top navigation bar and select Fields.
Select Insert.
Enter the following configurations:
Status: Set to Active.
Dataset: Leave blank.
Scope: Important! Set to Application.
ID: This should be lower case, with no spaces.
Name: This will be the display name of the field.
Prompt: Since these fields will be unique, they will not be associated with a prompt list.
Tab (optional): Include this field on a custom tab for easy viewing.
Value: Set to Store Value (bit/language/etc.)
Multiple: Set to Single Value since these fields will contain only one data value.
Unique: Set to Value contains a unique ID which identifies a single record for merging. This setting is crucial for all application ID fields in order to differentiate applicant records.
What if no application ID is stored in an external system?
The round configurations created in Slate are used to match imported data with applicant records.
Exporting Application Data from an External System
Export application data from an external system in a useful format. For example, an undergraduate institution may export application data in this format:
Unique ID | App ID | Plan | App Term | Submitted | App Major | Minor |
|---|---|---|---|---|---|---|
653451 | 43568 | Regular Decision | Fall 2019 | 7/20/2017 | Chemistry | French |
854278 | 86590 | Early Decision | Fall 2019 | 6/01/2017 | English | Art |
453780 | 23815 | Regular Decision | Fall 2019 | 6/03/2017 | Philosophy | English |
147934 | 34947 | Transfer | Spring 2020 | 7/01/2017 | Art | Flute |
While a graduate institution may export application data in this format:
Unique ID | App ID | School | Degree | App Term | Submitted | Program |
|---|---|---|---|---|---|---|
653451 | 43568 | Education | MA | Fall 2018 | 7/20/2017 | Comp. Ed. |
854278 | 86590 | Nursing | LPN | Fall 2019 | 6/01/2017 | Anesthesia |
453780 | 23815 | Business | MBA | Fall 2019 | 6/03/2017 | Executive |
147934 | 34947 | General | PhD | Spring 2020 | 7/01/2017 | Literature |
147934 | 23712 | General | PhD | Spring 2019 | 07/01/2017 | English |
Each unique application must be exported from an external system as its own data row.
For example, the student above (Unique ID 147934) has two separate applications: one for the PhD in Literature (App ID 34947) and one for the PhD program in English (App ID 23712).
Best Practice
Take time to make sure that the necessary fields are built in Slate before getting started with an application data import.
Go to the Dashboard to make new application-scoped fields, so that there will be a destination in Slate for incoming data.
The first column of the application data export should be reserved for the Unique ID used in steps A-E. Application data exports must include:
Required Export Columns |
|---|
Unique ID |
Rounds |
Consider adding these exports:
Best Practice Export Columns |
|---|
Created Date |
Submitted Date or Submitted Flag (Y/N) |
Include data columns for any application-specific data to be imported (for example, Entry Term, Major, and Minor).
No Submission Data?
If no submission data is included with the application upload, applications are stored in Slate as “Unsubmitted” by default.
However, if a Submitted Flag = Y column is mapped, the date of the import serves as the date of application submission.
Importing Application Data from an External System
To upload the file, follow the same upload steps used when uploading previous datasets. Application data is mapped to Slate destinations under the Application Fields category:
Source = sample value | Destination |
|
Unique ID = 653451 | Fields Details - Campus ID | Set the proper destination using the unique ID so Slate can match applications with the correct applicant. |
App ID = 43568 | Application Fields App: Application ID | Map the imported application ID to the unique, application-scoped field made in Slate. |
Plan = Regular Decision | Application Fields App: Round | Setting the App: Round destination will ensure that applications are created for imported records. |
Type = Freshmen | Application Fields App: Student Type |
|
App Term = Fall 2019 | Application Fields App: Term |
|
Submitted = 7/20/2017 | Application Fields App: Submitted Date |
|
App Minor = French | Application Fields App: Minor |
|
Value Mappings
Use the lists in the destination value column to define the destination value mappings:
Source Value (Plan) | Destination Value (App:Round) |
|---|---|
Regular Decision | Regular Decision |
Early Decision | Early Decision |
Transfer | Transfer |
RD | Regular Decision |
Important
Check The Rounds! Make certain that all rounds are configured correctly in Slate before setting up the value mappings. Also, check to make sure that imported values are mapped to the appropriate application round.
Additionally, it's possible to clean up imported data at this step. For example, if data being imported could be a combination of names and codes, mapping these values to one Round in Slate will result in a cleaner instance.
App: Round Destination
When configuring Slate destinations for application data (Fields Stage), use the App: Round destination to create applications.
App: Round - allows users to map to a specific application round in Slate. Mapping to the App: Round destination is done from one of the source columns in the imported application data. This ensures that each application in the import is created in Slate.
Unique ID | App ID | Admission Plan | App Term | Submitted | Imported data like the example to the left and mapping Admission Plan > App: Round would allow Regular Decision applications, Early Decision applications, and Transfer applications to all be generated. |
653451 | 43568 | Regular Decision | Fall 2018 | 7/20/2017 | |
854278 | 86590 | Early Decision | Fall 2018 | 6/1/2017 | |
453780 | 23815 | Regular Decision | Fall 2018 | 6/3/2017 | |
147934 | 34947 | Transfer | Spring 2019 | 7/1/2017 |
Or include App: Round as a Static Value
Alternatively, App: Round can be added as a static value when setting up mappings. However, only include App: Round as a static value if all of the applications in the import are associated with one particular application round (that is, every application record in the uploaded file is a Regular Decision application).
Slate Default Behavior
It is important to understand the Slate default behavior when importing application data:
Use App: Round to | Slate Default Behavior |
|---|---|
Create Applications | The application round that is mapped determines the round of the application. |
Update Existing | If mapping to a particular round, and a record already has an application in that round, Slate updates the existing application in that round rather than creating a new application. |
What if Round isn't mapped, but other application fields are? | |
|---|---|
Records with an existing | If a person record in Slate already has an application in an active period, then Slate imports the data to that application. |
Records without an existing | The application data will not be imported. All applications must have a round. An application cannot be created if a round has not been mapped. |
Note: If round is mapped at the Fields Stage, but the values were not mapped at the Value Mappings stage, it is as if round was not mapped at all.
App: Round Override Destination
In addition to mapping one of the source columns to App: Round, it is also possible to map another column to the App: Round Override destination. App: Round Override allows users to map a specific application round to override the App: Round mapping for specific records.
For example, imported application data may look like this:
Application ID | Admissions Plan | Student Type |
|---|---|---|
653451 | ED | Freshman |
854278 | RD | Transfer |
453780 | RD | Freshman |
453780 | RD | Freshman |
The Problem:
If the Admissions Plan column is mapped to App: Round it's not possible to determine who should be in the Freshman round and who should be in the Transfer round. Notice that the Student Type column indicates that some RD applications are Freshmen and others are Transfer.
The Solution:
Set the Admissions Plan destination to App: Round and the Student Type destination to App: Round Override. Then, at the Value Mappings stage, set the following mappings:
Source Value (Admissions Plan) | Destination Value (App: Round) |
|---|---|
ED | 2018 Early Decision |
RD | 2018 Regular Decision |
Source Value (Admissions Plan) | Destination Value (App: Round Override) |
|---|---|
Freshmen |
|
Transfer | 2018 Transfer |
Note: In the example above, 'Freshmen' is left unmapped, since it does not correspond directly to a particular round. However, 'Transfer' is mapped because it corresponds to the Transfer round.
As a result, records with the Student Type value of 'Freshman' have the application round determined by the App: Round mappings (from the Admissions Plan column). Records with the Student Type value of 'Transfer' have the application round determined by the App: Round Override mappings (from the Student Type column).
The App: Round Override destination should only be used when configuring fields during the Fields stage, step 1 of the import process.
It is unnecessary to add App: Round Override as a Static Value. If all applications in an import should belong to a specific round, adding a Static Value for App: Round is sufficient.
Review Stage
Proceed to the Review Stage once all Field, Value, and Static Mapping configurations have been checked. Be sure to double check any Pre-Flight Check errors that may display to ensure data imports correctly.
When ready, select Run Import.
If a unique application ID is included in the initial import, include that application ID in subsequent uploads. Slate matches on the person and the application when this unique application ID is mapped to the corresponding unique application ID field in Slate.
If no application ID field exists, it is best practice to map a round for subsequent application data uploads.
Was this article helpful?
