Before making Slate a system of record, a need may exist to import person data from an old prospect system, a student information system, or an institutional database system into Slate. To accomplish this, use Sources/Upload Dataset.
Before using Sources/Upload Dataset to migrate data from another system, you should develop a data migration strategy. Our best practice recommendation is to first upload records relevant to current business needs. Record data should be separated by the data type and brought in after the person record has been created one data type at a time. It is also not generally necessary to immediately import all records or data points from external systems into Slate.
Overall Process
There are several steps to follow in this process:
- Review data in your current system and determine which values need to be imported to Slate for current business operations or reporting.
- Create fields in Slate for all necessary incoming data. You do not need to bring in all the data at this time. If, at a later point, it is determined that certain values are required in Slate, data can be brought in at that time.
- Break up existing records into groups, prioritizing current prospect records.
- Segment incoming data for current prospect records into five different files by data type. Essential demographic data will need to be imported first.
- Create five sample files with 20 record rows each.
- Bring in the sample file with essential demographic data using Sources/Upload Dataset.
- Ad hoc files can be imported to your Production database using File Format - New Spreadsheet/Datafile. Mappings established using this configuration will be available as an import template for 90 days (deadline reset on use).
- Mappings established using custom Source Formats will remain available forever. Custom Source Formats can also be built in your Test database and Suitcased into Production. How to create a custom Source Format is explained here.
- Map the sample file. This process is explained here. Pro Tip- establish Static Mappings: Destination Tags - Test Record to mark these as sample records.
- If mappings are established in Production, refresh Test and Run Import in Test.
- Evaluate new records and update mappings in Production if necessary.
- Refresh Test and repeat steps 7-9 as many times as necessary.
- Repeat steps 6-9 with the 4 remaining sample files.
- When you are ready to go-live in Slate, migrate all necessary records from your pre-Slate system using the 5 import templates.
Import Current Records First
Import current prospect data first. Current prospect and applicant records can be separated into even more specific groups determined by term or program, for example, if it is helpful. Historical records can be imported after go-live if they are not currently necessary in your process.
| External Data | |
|---|---|
|
Current Prospect Data Records with a current or future entry term and no application. |
Make this data the primary focus so Slate can successfully be "turned on" as the system of record. |
|
Current Applicant Data Records with a current or future entry term and at least one application. |
After populating Slate with prospect records, attention can be turned to current applicant data. |
|
Historical Applicant Data Records with a past entry term and at least one application from a previous cycle. |
This data should be addressed at a later date (near the end of year one in the Slate cycle). |
|
Historical Prospect Data Records with a past entry term and no application. |
This data should be addressed at a later date (near the end of year one in the Slate cycle). |
Segment the Data
Our best practice recommendation is to upload current prospect data in five separate stages, starting with key demographic values (Core Data) and a person-scoped unique identifier which should be mapped to a Slate field configured as Unique for Merging. This data import will establish the person record in Slate.
Each subsequent upload should include the unique identifier, allowing the incoming data to match and update the appropriate person record in Slate created during the Core Data import. If a unique identifier is not available, subsequent imports need to include Slate person matching criteria (First, Last, and DOB or Email).
This staged approach will enable you to evaluate the import mappings more effectively and determine if there are any issues.
| Current Prospect Data | |
|---|---|
|
1 - Core Data Unique field, Name, Date of Birth, Email, Gender, Address, Phone, etc. (other destinations in “Student Record”) |
This upload will establish the base of the person record in Slate, including the unique field used as a key for subsequent data uploads. |
|
2 - Qualitative Data Unique field, Entry Term, Race, Academic Interests, Athletic Interests, etc. (other destinations in “Fields”) |
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. |
|
3 - School Data Unique field, School Information |
|
|
4 - Test Score Data Unique field, Scores |
|
|
5 - Interaction Data Unique field, Interactions |
Creating a Unique ID Person-Scoped Field
In addition to the Person and Application scoped system IDs and the record GUID generated automatically in Slate, Slate allows the creation of custom text fields that can hold external IDs or other unique record-specific values. External IDs stored in Slate can be used for matching on import and play a critical part in integrations.
The default unique for merging setting for a text field is Do not use value for merging. When set to Value contains a unique ID which identifies a single record for merging, Slate will use the value of the custom field to match onto records in the dataset.
To create a Unique for Merging field, create a Text field using the Field Editor, then update the Unique for Merging Setting to Value contains a unique ID which identifies a single record for merging.
Make a list of the unique ID fields used on your campus that may need to be created in Slate and used to establish a record match on import. Some common examples include:
- Banner ID
- EmplID
- Colleague ID
- Campus ID
Note: only one unique identifier is needed to match incoming data to a record in Slate. Once Slate establishes a record match using the order detailed in Matching Criteria for Person Records, subsequent matching criteria will be ignored. If multiple external IDs are included in the incoming file, Slate will randomly use the first one processed on import to establish a record match.
An application-specific ID or round mapping can be used to match imported application data with applicant records. You can read more about importing application data here.
Exporting Core Data from an External System
The core data import is essential because this data will:
- Build the base of the person record
- Establish the unique key that will be used for future dataset matching
Export core data from any existing systems such as Excel spreadsheets, tab-delimited text files, or CSV text files.
| Unique ID | First | Middle | Last | DOB | |
|---|---|---|---|---|---|
| 653451 | Alexander | Stephens | Hamilton | ahamil@email.com | 2/2/1999 |
| 854278 | Sarah | Wilbur | Washington | gwash@email.com | 10/24/2000 |
| 453780 | William | Howard | Taft | wtaft@email.com | 9/15/1985 |
| 147934 | Tammy | Jay | Jefferson | tjeff@email.com | 3/21/1997 |
The first column of the export should be reserved for the unique ID used to identify records in an external system, and core data should include:
| REQUIRED EXPORT COLUMNS: | |
| Unique ID | First Name |
| Last Name | |
| Birthdate | |
These data points ensure that Slate can match future dataset uploads as well as form submissions (such as events or interviews) with a prospect record.
Consider adding optional core data exports from this list:
| REQUIRED EXPORT COLUMNS FOR INTERACTION MATCHING: | |||
| Prefix | Suffix | Preferred Name | Middle Name |
| Mailing Address Street | Mailing City | Mailing Postal | Address Effective |
| Address Expires | Permanent Street | Permanent City | Permanent Postal |
| Citizenship 1 | Citizenship 2 | Permanent Resident | Phone Number |
| Mobile Number | Evening Number | Sex | |
Importing Core Data from an External System
- Select Database on the top navigation bar and select Upload Dataset.
- Upload the file.
- Enter the following configurations:
- File Format: New Spreadsheet/Data File.
- File Type: Excel Spreadsheet (or other file appropriate for the data file).
- Destination Scope: Persons/Dataset Record.
- Record Type: Persons/Applications.
- Unsafe: Leave this cleared at this time. Unsafe uploads will be covered in the next few sections.
- Update Only: Leave this cleared at this time. "Allow record creation" means that Slate will create a new record for any records in the dataset that do not match records in Slate. "Update only" means that the Source Format will not create new records, and the dataset will only update records that it matches.
- Dedupe Records: By default, Slate creates a new record for every row if Allow record creation is selected and an existing match cannot be found. If Dedupe records is selected, Slate will evaluate the source file and dedupe records with the source based on an exact match of First Name, Last Name, Email, and Birthdate.
- Hide: Leave as Create source interactions unless the source format will be used for a daily feed from an SIS, for example. With only a few exceptions, allowing source interactions to display on a timeline.
- Upload/Add File: Select the file for upload and select Upload.
After the upload processes, the file upload details page appears.
Buttons:
- Edit (upper right): Select Edit to rename the file, adjust or assign a folder to the file, or delete the file once it has processed.
- Download (middle right): Select to download the uploaded file.
- Build Import (middle right): Select to begin mapping data points to the appropriate fields in Slate.
Additional File Data Points Shown:
- Folder: If the file has been placed into a folder, it is listed here
- User: The user who uploaded the file
- Format: The format of the file (such as spreadsheet or CSV file)
- Status: Displays the current status of the file import
- File Name: Displays the name of the source file uploaded for import
- File Size: The size of the data file
- File Uploaded: Displays the date and time of the initial file upload
Once a file processes, the following data points also appear:
- Rows Imported: Indicates the number of rows (excluding the header row) imported (commonly one row per record)
- Load Runtime: When the file begins processing
- Remap Runtime: When the file finishes processing
When the file processes correctly, a section called Sampling of Imported Records displays the first 50 rows or related records imported from the file.
Uploading the file is only the first step. Data must still be mapped to the destination fields in Slate by building the import. Refer to the Upload Dataset Stages article for guidance on building the import and field mappings.