Data Feed Guide: Person Types

Overview

As part of your upgrade to Student Success & Engagement Enterprise, you will begin to use the following five Person Types to organize and interact with different types of people on campus.

1. Prospect
2. Applicant
3. Student
4. Staff
5. Faculty

Person Types are used to group records (people) into spaces that can be worked with by staff in different roles or departments. The What are Person Types? article provides additional information. Person Types may seem similar to roles, and the people in each role/Person Type may often overlap. However,

• Person Types determine what is displayed on a person record when staff users are viewing person records with a certain Person Type, whereas
• Roles determine a user’s security permissions and what they can view/use throughout the SS&E platform.

The terminology or definition for each of these enrollment stages may not match exactly what you use on campus, however each Person Type has unique functionality within SS&E. For the purpose of SS&E Enterprise features:

1. Prospect - someone you are recruiting to submit an application
2. Applicant - someone you are trying to enroll in classes
3. Student - someone who is registered for or currently taking classes

Person Types Related Feeds

Person

• PersonType is a field on the person datafeed.
• It becomes a required field at your Enterprise Launch, and all person records must have at least one Person Type in order to import or be updated.
• A person may have multiple Person Types. This can be achieved using the multi-value field separator of “::”, for example, “STUDENT::STAFF”.
• A person record typically keeps the last Person Type they had. For example, former staff would keep the Staff Person Type and therefore remain in the Staff list.
• If a person has multiple Person Types and no longer meets the criteria for one of them, it will be removed.
• If a person no longer meets the defined criteria for any Person Types, they may be given a placeholder Person Type (“NOTYPE”) in the Accelerate query or View. The record will still fail to import with an Import Error, but you can conclude that this is because they do not meet the criteria for any valid Person Type. When they again meet the criteria for a valid Person Type, the record will import again with the new Person Type.
• Person Types can be added or removed manually in the People & Roles list in SS&E Administration.
• Most of the time, prospects are not in the SIS and therefore are not imported via the SIS Import. There may be exceptions to this if the institution wishes to engage current students as prospects for other programs.

Assigning Person Types in Enterprise Upgrades

The System Administrators (typically the Student Success and Enrollment teams) will need to define the criteria for each Person Type, based on who they want to work with in different stages of the student’s enrollment and education. The Data Lead, typically the IT team, will need to use these definitions to create the Person Types lists, either in the Views or in the CSV extracts.

CSV File Setup

For institutions using the CSV method, Person Types are imported using multiple Person Type CSV files.

• Create one CSV file/extract for each type, "person_type_student.csv", "person_type_applicant.csv", "person_type_prospect.csv", "person_type_staff.csv", "person_type_faculty.csv", etc. with one column–the ID of each person who should have that type.
• The file should have a single row for each person.
• A person with multiple types will have a record in multiple files.
• The logic to join the Person Type to the person feed will be written in Accelerate by the Watermark Technical Services team.
• Typically prospects are not included in the SIS Import, with some exceptions.

Direct Database Setup

For institutions using Direct Database Connection, the personType field in the person view or query must be formatted according to the SIS Import Definitions. A person with multiple types should have all types in the same field delimited with double colon :: e.g. "STUDENT::FACULTY".

1. SQL Queries in Accelerate: Depending on the tables used in the Person Types logic, it may be helpful to use a setupQuery in Accelerate to define the types, and then join that to the person mainQuery (Watermark Technical Services can provide guidance/assistance on this as needed).
2. SQL Views: Depending on the tables used in the Person Types logic, it may be helpful to define Person Types in a separate view and then join that to the person View.

Best Practices

• Some campuses have found it helpful to bring in departments/roles that are knowledgeable with current business processes and definitions, such as the Registrar.
• Direct communication between the campus technical team and the campus implementation project team is key to ensure how data is presented and used within SS&E.
• Reviewing the data within your Test environment will help to fine tune Person Type definitions.
• Identify people with unique scenarios that can be used to validate the Person Type definitions within your institution's SS&E Test instance. Watermark recommends at least 5 students and encourages 10-20 people to be reviewed with the new data entering the system, including Person Type definitions. Testing prior to Launching in Production will promote a healthier adoption.
• Pay special attention to anyone who would be in overlapping groups, e.g. high school students, continuing education students (if applicable) who are current students, but who you may want to also work with as applicants for their post-secondary degree.
• In addition to reviewing new data feed information, also review new Person Types. If you have persons that have recently applied, become staff, faculty, student. Review the people and ensure they have the right types in the Administration People Screen as well as in the UI under the appropriate list of Applicant, Student, Staff, Faculty, and (optionally) Prospect.

For more information about Person Types and Enterprise in SS&E, please see the following articles:

• What are Person Types?

Example Definitions - Colleague

Below are some examples of definitions and logic used by other Colleague institutions.

Example 1

isFaculty:

All Of:

• where used contains FACULTY
• hrpCurrentStatus is not blank
• hrpCurrentStatus is not "SE"
• At least one of:
  • hrpEffectTermDate is blank
  • hrpEffectTermDate is after or the same as today's date

isStaff:

All of:

• hrpCurrentStatus is not blank
• hrpCurrentStatus is not "SE"
• At least one of:
  • hrpEffectTermDate is blank
  • hrpEffectTermDate is after or the same as today's date
• At least one of:
  • where used contains STAFF
  • where used contains EMPLOYES
  • where used contains HRPER

isStudent:

All of:

• where used contains STUDENTS
• has an A, N or W credit (CU) registration within the last 365 days.
  • Note: In your case you may want to also include CE

isApplicant:

All of:

• where used contains APPLICANTS
• has an application within that last 365 days that is not a WD status

Based on the results of the definitions above

APPLICANT

• not isFaculty
• not isStaff
• not isStudent
• isApplicant

STUDENT

• not isFaculty
• not isStaff
• isStudent
• not isApplicant

STUDENT::APPLICANT

• not isFaculty
• not isStaff
• isStudent
• isApplicant

STAFF

• not isFaculty
• isStaff
• not isStudent
• not isApplicant

STAFF::APPLICANT

• not isFaculty
• isStaff
• not isStudent
• isApplicant

STAFF::STUDENT

• not isFaculty
• isStaff
• isStudent
• not isApplicant

STAFF::STUDENT::APPLICANT

• not isFaculty
• isStaff
• isStudent
• isApplicant

FACULTY

• isFaculty
• not isStaff
• not isStudent
• not isApplicant

FACULTY::APPLICANT

• isFaculty
• not isStaff
• not isStudent
• isApplicant

FACULTY::STUDENT

• isFaculty
• not isStaff
• isStudent
• not isApplicant

FACULTY::STUDENT::APPLICANT

• isFaculty
• not isStaff
• isStudent
• isApplicant

FACULTY::STAFF

• isFaculty
• isStaff
• not isStudent
• not isApplicant

FACULTY::STAFF::APPLICANT

• isFaculty
• isStaff
• not isStudent
• isApplicant

FACULTY::STAFF::STUDENT

• isFaculty
• isStaff
• isStudent
• not isApplicant

FACULTY::STAFF::STUDENT::APPLICANT

• isFaculty
• isStaff
• isStudent
• not isApplicant

NOTYPE - filtered out with accelerate

• not isFaculty
• not isStaff
• not isStudent
• not isApplicant

Example 2

APPLICANT Type:

• Criteria:
  • Has a current application status that is NOT 'WD'
    AND
  • WHERE USED = 'APP'
    AND
  • Is not considered a student based on the student criteria
• NOTE: Mutually exclusive with STUDENT

STUDENT Type:

• Criteria:
  • Has an application with a current status of MS or AD. (This should already be available in the person_application.csv file.)
    AND
  • Has a program association with an end date that is null or in the future. (This information should already be in the person_degree_program.csv file.)
• NOTE: Mutually exclusive with APPLICANT

STAFF Type:

• Criteria:
  • WHERE USED = 'STA' and 'EMP'
• NOTE: Student workers should not be considered a STAFF person type. They should not have the STA in their WHERE USED list.
• QUESTION: When a person separates from the institution will the where used record be removed or is there an end date that should be considered (you mentioned a term date). If a date needs to be considered then that information will need to be added to the END of the person_roles.csv file.

FACULTY Type::

• Criteria:
  • WHERE USED = 'FAC'

Multiple Types:

• A user can have multiple types if they meet the criteria for the type with the exception of being both STUDENT and APPLICANT