Upload Dataset Stages

Slate provides a self-service method for importing both historical and live data.

When importing data, determine whether you will use a predefined Source Format or an ad hoc import to upload your file.  If you have not formulated a data import strategy, review recommendations for Importing Data of various types from external sources. 

  1. Select Database on the navigation bar
  2. In the Import section, select Sources / Upload Dataset.
  3. Select Upload Dataset.

  4. From the File Format list, select the desired file format under either the Predefined Formats or Custom Formats heading.

    Source Formats appear in the Predefined Formats list.

  5. If desired, select a current Folder or select Other to add a folder.

  6. Add a sample file, then select Upload.
    • The sample file should exactly match the format that you intend to send Slate.
    • Slate will process the file at this time. When completed, the status on the Upload Dataset main page will change from Pending to Completed or Awaiting Activation.
  7. When the file has uploaded, selecting the name of the Source Format opens the Remap stage, where source fields can be mapped to destination fields within Slate.
  8. When you are satisfied with how the file is mapped, go back to the new Source Format in the Admin Tool and set the Remap Active setting to Active.  Slate will then process any files uploaded on or after the Remap Effective date using the remap settings that you defined.  Any additional files that are uploaded to Slate using the new Source Format will also use the Source Format and remap settings that you configured using these steps.

Once the file has been brought into Slate, it's critical to map to destination fields and tell Slate where the data in the file should live. This is done by selecting the Build Import button.

Refer to the following sections for additional information on data import stages.

 

Field Mappings

The Field Mappings stage allows you to assign incoming fields with destinations in your Slate database. When creating your own source format, no destination fields are pre-mapped.

Here, Source Fields contain the values that your team uploaded to Slate. These fields must be assigned a Destination if your team intends to import those values to Slate. Otherwise, unassigned source fields will not be imported. Destinations can be left unassigned if there are source fields that your team does not want to import to your Slate database.

While assigning destinations, you will run into fields marked as 'Unique IDs.' These fields are used by Slate in subsequent imports for matching purposes.

Field Mappings

 

Set the Destination

To set the field destination, select a data row. A dialog appears with the items or settings:

  • Source: Displays the column name (such as Unique ID or First Name) from the incoming file.
  • Sample Value: Displays a sample data point from the file from that particular column (such as 653451).
  • Destination: First, select the scope of the field. Once chosen, select the specific field from that category to map to. For more information on field scopes, refer to the Fields and Prompts documentation article.
  • Destinations 2 and 3: To map an incoming data value to multiple fields in Slate, set destinations in destinations 2 and 3. Repeat the steps from the first destination mapping.
  • Overwrite: If some of the persons or data points being brought in already exist in Slate, select this box to prevent the import from overwriting existing data points.
  • Unsafe Override: If a field is marked "safe" at the field level, select this box to override this functionality.
  • Delimiter: If multiple data values exist in a particular column (such as multiple academic interests or courses), indicate how these values are delimited, and by what delimiter. Once a selection is made, Slate will parse these values out individually, as opposed to storing multiple data values in one field. This will be important at the Prompt Value Mappings stage.
  • Group: Groups are critical if bringing in multiple data values relating to a singular, larger item associated with a given person (such as a relationship of that person, a person's school, or a person's job).

    For example, if information about a person's parents was imported, and for each parent, the following data points existed:
    • First Name
    • Last Name
    • Birthdate
    • Email
    • Gender

...then for each set of data points for each parent, the same exact fields would be mapped twice (such as Relationship > First, Relationship > Last, or Relationship > Birthdate).
The difference, though, is that all of Parent 1's data points would be assigned a value of Group 1. All of Parent 2's data points would get assigned to Group 2, and so on. Each group would correspond to one clustering of data points associated with one larger item (such as a parent, a school, or a job). Groups are how Slate associates multiple data points with one larger whole item. 

  • Null Handling: By default, Slate only imports information that exists in the source file. However, occasionally a blank or null source value actually indicates valuable data. If you enable custom null handling on a free text field, Slate will set the field value to null if the source value is null. If you enable custom null handling on a prompt-driven field, Slate provides the opportunity to map a null source value to the desired destination value in the Prompt Value Mappings stage.

    If Null Handling is enabled on a mapped field, the mapping appears in the Field Mappings Stage regardless of Remap Date.  This will be helpful if the column heading of a source file changes from one year to the next.  If the remap date is updated, and a previously-mapped column heading does not exist on a new source file, the field mapping will appear with a sample value of "Deprecated (Null Handling)" so that the field can be unmapped.

 

Important

Sometimes it is not necessary to select a destination in Slate. For example, if the uploaded file does not have data values in a column (indicated by no sample data appearing (for example, in the "Home Address 3" and "Lucky Number" rows above)), there may be no need to select a Slate destination.

Additionally, another option is to not map to a field in Slate (like the "Favorite Color" row) even when a data value exists, because that data value may not be needed on a particular person's record at this time. If so, do not select a Slate destination for that data.

 

Field Fusions Stage

Field fusions provide the option for combining multiple source data points and mapping to a single destination field.  Data point options include up to two static values (Prefix or Suffix) and up to three source fields.  The data points are concatenated and separated by a hyphen (-). Missing data points are replaced with the string "NULL".

While field fusions will not be used in most imports, they are helpful when the concatenation of two data points is needed to map into one unique field.   

An example of field fusion is the creation of the Common Application application-scoped ID when using the CommonApp Source Format.  Since the Common Application only provides a unique ID number for each person (and not for each application, such as when a student applies in consecutive years), a field fusion allows for the creation of a unique application-scoped ID field value.

This field fusion is already included by Technolutions on the Source Format available in the Source Format Library. Do not change or edit this mapping. The field fusion combines the Common App ID source field value with the year as a Suffix, in order to create a unique application-scoped ID (for example, "Common App ID-2020").

To create a static mapping, follow these steps:

  1. Go to the Field Fusions stage.
  2. Select New Field Fusion.
  3. Enter text if adding a Prefix to the fused value (optional).
  4. Select up to three Source Fields from the list to create the sequence of fused values.
  5. Enter text if adding a Suffix to the fused value (optional).

 Tip

Field Fusions are available only for source formats, not for ad-hoc imports. You will also need to use Append Values to map Field Fusion values.

 

Prompt Value Mappings Stage

Data from the file may contain values that do not exactly match existing prompts in Slate. The Prompt Value Mappings stage provides an opportunity to specify the exact destination prompt value in Slate for each incoming source value. 

Only those fields associated with prompt lists in Slate appear at the Prompt Value Mappings stage. Fields that are "text" fields (for example, First Name, Last Name, Email, and Unique ID) will not appear in the Prompt Value Mappings stage since they are all unique and are not associated with a set list of prompts.

Initially, the fields present in the Prompt Value Mappings stage do not reflect all of the related data points from the incoming file. If this is the case, the following warning appears:

This source has fields for which values have not yet been populated. Click "Refresh Values" above to scan the source files to identify possible values.

To remedy this, select Refresh Values. This pulls all of the sample values from the source file into the Prompt Value Mappings stage. Once Refresh Values is selected, the previous warning message will go away.

Once the values are populated, proceed to map incoming data values to the appropriate prompt values in Slate. For each field at this stage, a Mapped and an Unmapped column appear. The numbers in each column indicate how many incoming values from the source data file have been mapped to prompts values in Slate.

For instance, if the source file brought in a person's academic interest, and a user wanted to map the source values to prompt values in Slate, they would take the following action:

  1. Select the corresponding field (in this case, a person's academic interest).
  2. A dialog appears to display incoming source values on the left. Initially, the Destination Value column will be blank since they have not been mapped.
  3. Select Guess Below. If Slate can match incoming data values with existing prompts, it will do so. This will save time as opposed to manually assigning each incoming value with a prompt in Slate.

    Also, some incoming data points may not need to be represented in Slate, as in the Field Mappings Stage, so don't feel compelled to map each and every prompt value if they are not critical.
  4. Once mapped, incoming source values appear on the left and their corresponding prompt values in Slate appear on the right.

 

Append Values

Initial incoming data files may not contain every prompt value that will be imported over time. However, if prompt values for these "future" incoming data points already exist in Slate, then users will want to take advantage of the Append Values button (visible in the lower right corner when mapping prompt values).

Append Values enables these future source values to be added and mapped to at this time. Using this method, there may not be a need to return to the Prompt Value Mappings stage each time a new source value is brought in. (However, periodically checking in on incoming source formats is recommended to be sure that there are no data points that need to be mapped or updated.)

Select Append Values and add any or all possible source values that could be imported for a field in the future. Slate will eliminate any duplicate values that already exist in Slate. Be sure to add only one value per line. 

Once added, select Append and continue to map these newly added data points as appropriate.

 

Static Mappings Stage

The Static Mappings stage provides the option to assign a static (hard) value.

  • For example, if each incoming record in a data file is a prospect, this can be set as a "static" value for each record in the file so that every record will be assigned the status of Prospect.
  • Continuing, if each incoming address in a data file should be marked as a mailing address, this can also be easily accomplished.

To create a static mapping, follow these steps:

  1. Go to the Static Mappings stage.
  2. Select New Static Mapping.
  3. For Destination select:
    • The field scope/category.
    • The specific field itself.
    • The value of that particular field.
  4. When setting a static mapping, depending on the field chosen, more options may appear:
    • Overwrite: Selecting this prevents Slate from overwriting any current data values that may already exist in the chosen field.
    • Unsafe Override: If the chosen field is set to "safe" at the field level, selecting this temporarily makes the field "unsafe" for this data import, allowing Slate to import potential new data values into the field.

 

Review & Run Import Stage

After all of the data mappings are complete, the final step is the Review & Run Import Stage. Here any potential warnings about incorrect configurations appear in the Pre-Flight Checks area. Examples of some errors users may see are: 

  • Error: Application fields have been mapped, but an application round has not been specified.
    • NOTE: When bringing in applications, a round must be mapped; otherwise Slate does not know which application to create and/or update. 
  • Warning: One or more fields have been mapped to prompt destinations where a translation has not been provided: example field name (XX values).
    • NOTE: Any fields where potential issues exist will be listed after the ":" in the warning above along with the number of values corresponding to that field.

Once all warnings and errors have been reviewed and addressed, select Run Import to begin processing the data file.

 

Retroactive Refresh Stage

The Retroactive Refresh stage provides the ability to select destination fields to refresh (left column below) and the recent sources from which to re-run an import ("Sources" section of the image below). When refreshing data fields that are a part of a set (such as an address), include all related components. If refreshing data fields that are part of a field group (such as group 1 or group 2 with a school record), include any identifying key data points to prevent the creation of duplicate records.

Retroactive Refresh Stage

Some common examples of when to use Retroactive Refresh are:

  1. If a field was brought in with an old data file and was previously unmapped because this particular data point was not needed at that time. However, it is now needed for a partner's process, so the field and value mappings are now mapped.

    If a field becomes mapped, partners should go to the Retroactive Refresh stage and select that particular field and associated source files and select Retroactive Refresh. Once this is complete, any previous data values that were present for this old, unmapped field will now live on associated records in the newly mapped field.
  2. Another example of when to use retroactive refresh would be if a value mapping was incorrect.

    Perhaps for an academic interest field, the prompt value of "English" was accidentally mapped to "Biology" in the Value Mappings stage. Once the error is discovered, and if the appropriate correction is made in the Prompt Value Mappings stage, then the academic interest field can be refreshed on the appropriate source files, and the imported data points for the academic interest field will again be remapped. Thus, those records that previously were incorrectly assigned "Biology" would now be assigned "English.'"

Important

Exercise caution when using the Retroactive Refresh function, since this process will reset data values to what they were when a data file was imported.

For example, if an applicant's entry term field was imported on a data file as "Fall 2020," but had since been updated to "Spring 2021," running a retroactive refresh on the entry term field on the data file where an applicant came in would revert this entry term field back to "Fall 2020."

 

Importing Process

Upon initiating, the file enters an import queue. For most imports, the processing time will take between 10-15 minutes.

Once Slate has processed the imported data file, the file's status will update, uploaded record data will display, and additional action buttons will appear. New buttons that will now appear are:

  • New Query: Select to build a query specifically from the data imported with this file.
  • Batch Management: Select to batch manage the records from this upload (similar to the method in Query Builder). For instance, if selected, users can batch update a particular field for all records in the upload, retroactively refresh all records, build a deliver mailing around the records uploaded, or assign a tag.
  • Import Fails: If data fails to merge into a record, the data row details for these failures appear here.
  • Batch Acquire Documents: If any documents from a document import cannot be matched to a record, the documents can be accessed in Batch Acquire here.

If any rows could not be assigned to an existing record, a tab called Unassigned Rows appears. By selecting an unassigned row, the row can be manually assigned to an existing record, or a new record can be created.

Important

Uploads get sourced! There’s no need to make a new interaction for uploaded datasets. Slate does this!

Once the import is executed, a new Source code data line is added to a person’s Interaction tab.

 

 Tip

Upload Dataset includes several destination mappings that are only used in special cases:

  • Record > Person Status (Force Update): Allows for the update of a person status, even if the new status is an earlier status.  For example, to force update an Inquiry back to a Prospect status.  (Note: value mapping is required.)
  • Status History > Status and Timestamp: Allows for the import of historical statuses and corresponding timestamps.  For example, if importing Applicants, these mappings can be used to import their Prospect and Inquiry statuses with timestamps.  (Note: grouping and value mapping are required.)
  • System > Custom: Skip Import: Allows a record to be skipped based on the value in the source field.  (Note: value mapping is required.)
Was this article helpful?
5 out of 12 found this helpful