1. Watermark
  2. Student Success & Engagement (SSE)
  3. SS&E - IT Resources
  4. SS&E - SIS Integration

Data Feed Guide: Person Types

Updated

Overview

In preparation for your upgrade to Student Success & Engagement Enterprise, you have been asked to think about the five person types are available for your campus to use and that can be displayed: 

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

Person Types are used to group records (people) into spaces that can be worked with by staff in different roles. Here is a help center article that provides additional information. Access over seeing other users is determined by role; for example, anyone with a role that allows visibility to view applicants would have access to view anyone with the applicant person type. 

Multiple person types can be added to the same individual. Therefore, you can create multiple reports exporting separate files (e.g. person_type_student.csv, person_type_faculty.csv, etc.). We can write logic to join them in the Accelerate configuration query. For example, someone in the staff file and the student file would be given this person type: “STUDENT::STAFF”. This will help you define the logic behind these person types the following are examples that other institutions used.

Determining personTypes 

*Please discuss these internally between the Executive Sponsor, Admins and the IT team. This is largely a business decision. Please complete prior to the Kick Off meeting. Your IT team, who will use the responses to then translate your responses into the PersonType on the Person Data Feed. Below you will find three examples from prior institutions as they developed personType definitions. In the first example the Watermark question is on the left and the institution’s response is captured on the right. The second and third examples aim to answer these same questions in a different format. 

Example 1

Watermark Question Institution Response

In general a person's personType(s) should match your definition of each type. For example, at what point is a person considered a ""STUDENT"" at your institution. A person will have a student type if they are currently enrolled, or have been enrolled for any of the past three semesters.
A person can have multiple types. This is accomplished by providing multiple types separated by :: for example STUDENT::FACULTY.  * Once this functionality is enabled in SS&E personType is a required field in the person datafeed, so any user with no personType would fail to be created or updated. Understood
Should a person receive the STUDENT type if they have ever registered for a class regardless of how far in the past? If not, what is the threshold? * Note: There is not an ALUMNI type, so in general once a student they should likely remain a student.  A person will have a student type if they are currently enrolled, or have been enrolled for any of the past three semesters.
Should a person receive the Applicant type if they have ever applied regardless of how far in the past? If not, what is the threshold for the date of their application?  I’ve updated the applicants feed to only include applicants who are not yet students, for the current and past three terms.
Should STUDENT and APPLICANT be allowed on the same user at the same time or should they be mutually exclusive. I’ve updated the feed for students to drop the applicant type once they are enrolled for the current or past three terms.
The feed for students to drop the applicant type once they are enrolled for the current or past three terms. The team decided to give currently employed faculty the faculty type. I’ve updated the feed to include faculty who are teaching the current and/or next future term.

What criteria makes someone a STAFF type?

   * Example: Just a STAFF in WHERE USED?

   * Should student workers be given this type?

   * If not, how can they be identified?

 I’ve updated the staff type to include current employees, and remove any who are current faculty. This might need to be changed to include all employees regardless of faculty status. 
Should someone be able to have the FACULTY and STAFF types at the same time or should the types be mutually exclusive with FACULTY overriding STAFF if they are both? I’ve updated the staff type to include current employees, and remove any who are current faculty. This might need to be changed to include all employees regardless of faculty status. 
Should STAFF/FACULTY also be able to have the STUDENT and/or APPLICANT person type?  The current reports would allow a faculty/staff to also have applicant/student types if they were applicants or students.
Are PROSPECT users in your SIS and if so how are they identified? I looked at the prospects data feed and the result is the same as the applicant's feed. There is a separate prospects file, but it points to applications. That data is the same as what gets pulled from the applicant's file. So this data is redundant. I would suggest not using the prospects type. But it’s up to the team.
Is the PROSPECT type mutually exclusive of APPLICANT and/or STUDENT I looked at the prospects data feed and the result is the same as the applicant's feed. There is a separate prospects file, but it points to applications. That data is the same as what gets pulled from the applicant's file. So this data is redundant. I would suggest not using the prospects type. But it’s up to the team.

 

Example 2

(Colleague-specific)

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 3

(Colleague-specific)

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

CSV File Setup Options

For institutions using the CSV method, there are several ways to set up the CSV files. When adding person types after implementation, it is recommended to create a copy of the existing CSV file, e.g. "test_person.csv" so that the production file is not affected.

  1. Using person CSV file only: Include all valid personTypes on the person record directly in personType field/column at the end of the test_person.csv file (see Import definitions here: SIS Import Definitions for column order, but it's best to copy what is already in the existing person file and add the new columns to the end of the file). A person with multiple types should have delimited with double colon :: e.g. "STUDENT::FACULTY". 
  2. Single personType CSV file: One CSV file named "person_type.csv" with two columns–each person's ID and their person type. The file can have multiple rows for each person. Logic to join to person feed will be written in Accelerate.
  3. Multiple personType CSV files: Separate CSV files for each type, e.g.  "person_type_student.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. Logic to join to person feed will be written in Accelerate.

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 personTypes logic, it may be helpful to use a setupQuery in Accelerate to define the types, and then join that to the person mainQuery (TC can provide guidance/assistance on this as needed).
  2. SQL Views: Depending on the tables used in the personTypes logic, it may be helpful to define personTypes in a separate view and then join that to the person View.

Pro Tips

  1. Other campuses have found it helpful to bring in departments/roles that are knowledgeable with current business processes and definitions, such as the Registrar.  
  2. 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. 
  3. Reviewing the data within your Test environment will help to fine tune person type definitions. 
  4. 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 PersonType definitions.  Testing prior to production will promote a healthier adoption. 
    1. Pay special attention to anyone who would be in overlapping groups, e.g. high school students, continuing ed students (if applicable) who are current students, but who you may want to also work with as applicants for their post-secondary degree. 
  5. In addition to reviewing new data feed information, also review new PersonTypes. If you have persons that have recently applied, become staff, faculty, student. Review the dates and ensure they are visible in the Administration People Screen as well as in the UI under the appropriate label of Applicant, Student, Staff, Faculty. If you are sending in prospects, would do the same, if not n/a.

Articles in this section

See more
How to Contact Support
There are many ways to reach out! Click here for our support options.
Watermark Academy
Click to access the Watermark Academy for consultation, training, and implementation companion courses.
Customer Community
Can’t find the answer? Ask fellow users how they’re making the most of Watermark in our Community!