Importing Qualitative Data
- 16 Nov 2023
- 5 minute read
- Print
- DarkLight
- PDF
Importing Qualitative Data
- Updated 16 Nov 2023
- 5 minute read
- Print
- DarkLight
- PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Exporting Qualitative Data from an External System
Important
Core data must be imported prior to qualitative data.
Remember to include a unique ID from your external system when importing into Slate. This ID will be used to match qualitative data with the associated records in Slate.
The unique ID should be the first export column of this import.
The following is a recommended format through which to export data from an external system:
Unique ID | Entry Term | Race | Academic Interests | Athletic Interests |
|---|---|---|---|---|
653451 | Fall 2020 | White | BIO, CHEM, PHY | Basketball, Tennis |
854278 | Fall 2020 | Black, Asian | PSYCH, PHIL | Tennis |
324786 | Spring 2021 | Hispanic, Black | ENG | Frisbee, Golf |
324786 | Fall 2022 |
| CHEM |
|
Important
Remember to make the first export column the unique ID used to identify records in the external system.
Now that core data has been imported (with this ID), Slate will be able to match qualitative data with the Slate record that was created through the core data import.
At this stage, make certain that all qualitative data imports contain the same unique ID column included in the core data import and that other column names are appropriately descriptive. Knowing the type of data that is stored in each column will help ensure the right Slate destinations are selected when building the import.
It is also important that value formats can be easily interpreted. For example, some columns may contain short export codes while other columns may contain longer, more descriptive names. It's possible to clean up this data when setup up the value mappings in Slate, but this can only be done if users are able to understand those values.
No names?
There is no need to include personal data in the qualitative data import thanks to the unique ID field. The unique ID field is all Slate needs to match on a record.
Importing Qualitative Data from an External System
Follow the same import steps used when uploading core data. Once the file has been uploaded, click the Build Import button to begin the process of mapping fields and values.
Does a field need a tab?
A field does not need to be on a custom tab in order to make it available for destination mapping. All custom fields without a tab assignment will be organized with the Other prefix at the bottom of the list: Other - field name
Clean Up the Data
It is possible to manipulate import data to store in a more meaningful and strategic way in Slate. That is, destination mappings do not always need to be a one-to-one relationship. For example, there may be multiple types of data stored in a single column when exporting external data:
Unique ID | Entry Term | Race | Academic Interests | Athletic Interests |
|---|---|---|---|---|
894512 | Fall 2023 | Hispanic, White | BIO, CHEM, PHY | Basketball, Tennis |
In the above example, a Hispanic value is being stored in the Race column, along with other ethnicity values (such as White).
A better practice is to store this data as two separate fields in Slate: one field to store the Hispanic value and one field to store the race values.
Best Practice
When determining race/ethnicity fields use the IPEDS Reporting Categories model and store Hispanic information in a separate field.
Clean up this type of data by setting multiple Slate destinations on the Set Destinations tab. In this instance, a best practice recommendation is to map this particular incoming data column in the following way:
Set the first destination to Race.
Set the second destination to Hispanic
Be sure to select the proper delimiter for both fields (such as the "," in this instance).
Expand and Collapse Data Strategically!
It's possible to map to a field in Slate that stores multiple values by either having a single, delimited column or multiple columns that are all mapped to the same destination field in Slate.
For example, if there are three academic interest fields in an external system and a single academic interest field that will be used to store multiple values in Slate, upload the values using three columns that are all mapped to the same academic interest field in Slate, like so:
External Data | Map Destination to -> | Slate Field | |
Export Column 1: |
| Academic Interests | |
Export Column 2: |
| ||
Export Column 3: |
| ||
Additionally, if multiple values are stored in a single field in an external system, it is also possible to map this multi-valued field to a Slate destination field that is also configured to store multiple values:
External Data | Map Destination to -> | Slate Field | |
Export Column: |
|
| |
When mapping to a field in Slate that is configured to store a single value, do not send delimited values in a single column. Instead, send one value per column.
For example, if an external system currently stores academic interests in a single field, but a change in process necessitates storing a single value in three distinct Slate fields: Academic Interest 1, Academic Interest 2, and Academic Interest 3 then data must be sent in multiple columns:
External Data | Map Destination to -> | Slate Fields | |
Export Column 1: |
|
| |
Export Column 2: |
|
|
|
Export Column 3: |
|
|
|
For the above examples, where academic interests are being imported, it is not possible to send delimited values within a single column to multiple Slate destinations.
Value Mappings
Specify the destination values in Slate for source values from the file. Pay special attention to source values that have been mapped to more than one Slate destination. For instance:
Race - Destination 1 Mapping (Details - Race)
Race - Destination 2 Mapping (Details - Hispanic)
Again, at the Value Mappings stage incoming source fields can map to same destination fields which may or may not use different prompt values. For example:
In this example, the incoming Race source field is being mapped to both Race as well as Hispanic in Slate. For the Race field, the Hispanic incoming source value is left unmapped as it does not apply to the Race field.
Continuing, the incoming race values provided (i.e. Asian, Black, White, etc.) are left unmapped in the Hispanic field, and only the Hispanic incoming source value is mapped to a Yes value.
Review Stage
Proceed to the Review Stage when satisfied with the field and value mapping configurations. Be sure to double check any Pre-Flight Check errors that may display to ensure that data imports correctly.
When ready, click Run Import and Slate will then import the data in the file to the records that were imported during the core data import, matching on records using the unique field value.
Was this article helpful?
