About this data
Contacts are set up and managed in Illuminate’s fully relational database. The model used for contacts in Illuminate allows for one contact to be linked to multiple students.
About this import
The contacts.txt file is how contacts are associated to students. For Illuminate Data and Assessment (DnA) and Illuminate Special Education (ISE) your contacts.txt file should be uploaded nightly. The nature of the contact dataset makes it a very difficult dataset to update with nightly imports. So in DnA and ISE, every time your contact data is imported it is replaced. For Illuminate Student Information (ISI) the contact data should be imported only with the initial data loads. Any subsequent contact changes should be managed through the user interface.
The unique key on a contact record is: Import Student ID, Contact Last Name, and Contact First Name. These three fields together are what constitute a unique contact record. However, because there is not a reliable identifier for the contact record beyond first and last name, this dataset cannot be updated. Only replaced. Furthermore, if a client - DnA, ISI, or ISE - is utilizing the student/parent portal, a contacts.txt import will only work to add contacts, not replace.
- Import Student ID
- Student Last Name
- Student First Name
- Birth Date
- Contact Last Name
- Contact First Name
Import Student ID is the key identifier for this dataset. The Import Student ID should be a unique value for each student. It is not required that the value is the Student Information System (SIS) ID. It is required that for the entire installation the value is guaranteed to be unique. Traditionally, in a single district instance, the Import Student ID is the SIS generated student ID. In installations that span multiple districts, such as a consortium or a county, the Import Student ID is usually the State Student ID because this value is expected to be unique across multiple SIS.
Student Last Name, Student First Name, and Birth Date are actually “soft” requirements within this dataset. It is expected that every student should have these additional three basic data elements available in this file. In the programs.txt file, these fields are only used to assist in troubleshooting data. Ensuring that the data is available in the file allows for more efficient troubleshooting when reviewing import logs. This data is required to be present in the import file, however, the fields are not imported. These fields are updated only through the studemo.txt import.
Contact Last Name and Contact First Name create the actual contact record that is associated to the student. They are the only two required fields to link a contact record to a student. However, without additional data, the contact record will be very limited.
If any of the required fields are not provided or if any of the required fields do not align to the designated field types or values, the entire record will not import. Problems with required fields will generate import errors.
Whether or not a field is required refers to basic, minimal operation of the system. With only the required fields your Illuminate installation will work, however, it may not be configured optimally. Additionally, beyond minimal functionality and basic reporting, in an ISI as much data as can possibly be provided should be imported. Many non required fields are used in basic reports and compliance reporting.
Non-required but recommended fields
- State Student ID
- Address 2
- Phone 1
- Phone 1 Type
- Phone 2
- Phone 2 Type
- Legal Guardian
- Primary Contact
- Contact Type
- Contact ID
- Email Address
- Correspondence Language
- Emergency Contact
- Family/Household ID
State Student ID is the student’s unique identifier for state data reporting. It is used extensively as an alternate identifier for students. It is strongly recommended that this information is provided. In this import this ID is used solely for troubleshooting and student identifying information. It is not updated or imported from this file. It is only updated or importing via the studemo.txt import.
Address, Address 2, City, State, and Zip represent the full address for the contact. This data is not required but is strongly recommended. The contact address data is applied to the student and becomes the student address in Illuminate when certain contact requirements are met.
Phone 1, Phone 1 Type, Phone 2, Phone 2 Type, and Email Address are various contact methods for this contact record.
Legal Guardian, Primary Contact, and Emergency Contact are all boolean fields to identify essential contact attributes for this contact record.
Contact Type should align to a the Contact Type code table in your Illuminate installation. Generally, this field will help to identify how the contact is related to the student (mother, father, doctor, etc.)
Correspondence Language is the language ID, from the code tables, and should designate the preferred correspondence language for this contact record.
Contact ID and Family/Household ID, if available, are additional identifiers for the contact record. The Contact ID should be the internal identifier of the contact. The Family/Household ID represents the “family” record in systems that support the concept of households.
- Student Middle Name
- Restraining Order
- Receives Mail
- Mailing Address 1
- Mailing Address 2
- Mailing Address City
- Mailing Address State
- Mailing Address Zip Code
- Phone 1 Unlisted
- Phone 2 Unlisted
- Employer/Occupation (free text)
- Job Title (free text)
- Address (free text)
- Military (y/n)
- Civilian (y/n)
- Active Duty (y/n)
- Branch of service (free text)
Contacts are not updatable:
- Because of the nature of the contact import, contact data cannot be updated. Because most systems, when contact data is exported, do not allow for or provide a unique key for a contact the Illuminate contact import does not perform any sort of updates.
- When contact data is imported, there are two options: Replace or Append. Replace will first delete all contact data for any students in the import file and them perform the import. Append is completely additive. It will simply insert records based on the data that is in the import file. Append can very easily generate duplicate contact records.
- Since contacts cannot be updated, for ISI installations, contact data management should all be done directly in ISI. Since ISI is the system of record, the tools within ISI should be used to manage contact data. There is no capability for mass file based contact updates in ISI.
Contacts.txt will not import if contacts are used for portal access:
- Portal access is typically created in ISI using contacts. Because of how the contact import works using the Replace option, contact data is wiped out and the replaced with contents from the import file. If this is done in an ISI installation where the parent portal is enabled, then parent portal credentials will be removed.
- In order to ensure a successful parent portal experience, the contact import is disabled if even one parent portal account is tied to a contact.
- There are only two options for importing contact data into an ISI installation:
- Delete all parent portal accounts and trigger an import
- Import unique records in Append mode.