Option 1: Standard Fetch

The standard fetch approach requires one data file that contains all potential applicants that may use the Terra Dotta system. The standard approach was designed for simplicity, requiring only one point of integration. The disadvantages of the standard approach center on the overhead and security concerns that accompany the export of potentially thousands of rows of personal data to a system that may only use a small fraction of that data. 

Option 2: Deferred Fetch

The deferred fetch approach splits the data into two files: Core Data File and Custom Data File. The Core Data File contains only core data (UUUID, First name, Last name, Email, DOB*, Gender*, Confidentiality Indicator*) for ALL potential applicants that may use the Terra Dotta system. The Custom Data File contains the rest of an applicant's information, but only for ACTIVE applicants.

Once a user has an active application in the Terra Dotta system, their profile will be populated with Core Data only. Then the user’s UUUID will be written by a nightly scheduled task to the Terra Dotta Applicant Pool file. The pool file format is a single column text file with no header row using the [CR][LF] end of line characters.

You will pick up this pool file each night for provisioning of the additional information in the Custom Data File. The additional information will be loaded into an applicant's profile the following day.

• Typically a deferred-fetch approach will take more planning and analysis and therefore more time to implement.
• With the deferred-fetch approach, you would want to flag all current applicants for import from the SIS (both new and current), as the application is set to refresh parameters throughout the process for any full applicant.
• Does the data resource which will provide the core applicant data required by the system contain core attributes? (UUUID, First Name, Last Name, DOB, email, gender, and confidentiality indicator) The core data source will be delivered via a tab delimited flat file. Gender, DOB, and confidentiality indicator can remain null upon initial fetch. The SIS import is able to populate them on the next refresh.
• If you have any process requirements (materials or questionnaires) in the initial application phase which are deployed based upon an applicant parameter being pulled from the SIS, then these requirements would not be deployed to the student until after the SIS import. In this scenario, the applicant would not see the full set of application requirements upon initial login.

While best practice from a data perspective would be to implement a deferred fetch process, the process does limit certain functions within the application. We have clients who have implemented both approaches.

HR Data

The same options apply to HR data as to SIS. HR data may be transferred in a separate flat file, or it may be included in the same file as the SIS data with a flag to indicate who should be considered as HR.

1. Must contain the entire eligible population of potential staff users.
2. Terra Dotta software is indifferent to the name, datatype and content of Custom Data Fields. Datatype and compatibility are limited to what the software can render and store in a varchar (500) field.
3. Column header names should not contain spaces or special characters except for underscores. 

Data file Specifications:

Data should be provisioned via a flat file and should meet the specifications outlined below:

• Single record per user. (UUUIDs may not be duplicated in any single file)
• All core required fields present and populated. (In deferred-fetch, required core information and custom information are sent in separate files keyed on UUUID.)
• Tab-delimited (tsv) with any empty/null columns delimited with the appropriate number of tabs to maintain column alignment.
• A header row with column descriptors is required. The header names are predefined and will be provided by Terra Dotta. Headers should not contain spaces or special characters except for underscores.
• Field values must be trimmed. No space or other padding of field values is permitted.
• Fields are single-valued. Any multivalued data will be imported as single values (will not be parsed). Core fields may not contain multiple values.
• Row delimiter can be either LF or CRLF but must be consistent.

Data File Naming Conventions:

Terra Dotta does require a standard file name and your Integration Analyst will confirm the file name in your Technical Integration case. The standard file naming conventions are as follows:

Standard Fetch

Data File Option 1: This option allows student/applicant and faculty/staff information to be sent separately. NOTE: the student/applicant file would include all of the record's information, while the faculty/staff file would only include core data.

• sis_user_info.txt - if the file contains all information for students/applicants
• hr_user_info_core.txt - if the file contains core information for faculty/staff only

Data File Option 2: This option allows student/applicant and faculty/staff information to be sent together in a joint file. NOTE: The joint file allows you to send all of the record's information in a single file. You may include additional information for faculty/staff such as campus phone number, title, department, etc.

• sis_hr_user_info.txt - if the file contains combined SIS (student/applicant) and HR (faculty/staff) user records. This file must include a column flagging HR (faculty/staff) users.

Deferred-Fetch

• Custom Data File:
  • sis_user_info_custom.txt - this file contains the rest of the applicant's information

• Core Data File
  • Option 1: This option allows student/applicant and faculty/staff information to be sent separately.
    • sis_user_info_core.txt - if the file contains core information for students only
    • hr_user_info_core.txt - if the file contains core information for faculty/staff only
  • Option 2:
    • sis_hr_user_info_core.txt - if the file contains combined SIS (student/applicant) and HR (faculty/staff) user records. This file must include a column flagging HR (faculty/staff) users

Data should be classified as either core or custom data.

Core Data:

Core data fields are required pieces of information for any record provided via the integration. 

Custom Data:

Custom data fields are additional pieces of information for any record provided via the integration. The mappings template below provides a list of standard student/applicant information fields included in a standard integration with Terra Dotta software from institution student information systems

Preview the Study Abroad Mappings Template