Retention Standards

Retention Standards

Updated on February 15, 2018 <draft edit in progress>

Index:

  1. What is the Retention Core?
  2. Retention Core Connectors
  3. Retention API Documentation – SWAGGER
  4. Retention Integration Architecture
  5. Retention Transactions (overview)
  6. How to use the APIs
  7. Retention Core Object Descriptions
  8. Retention Core ERD
  9. Retention Core Object Details and Primary Keys

 

 

 

1. What is the Retention Core?

The Retention Core is the central component in the NoodleBus for all the retention and advising related connectors. All the connectors pass through the central core to:

  • Standardize the data and manage the client’s translations and configurations
  • Manage the routing of the data to other systems
  • Monitor and report on the transaction statuses
  • Relay information to supported analytics platforms

 

 

 

2. Retention Core Connectors

The Retention Core is designed with standard API connectors to handle data that needs to flow between:

  • Student Information Systems (SIS)
  • Learning Management Systems (LMS)
  • Retention and Early Alert Systems
  • Retention Analytics Systems (such as Noodles Analytics for OPM)

 

 

 

3. API Documentation:

 

 

 

4. Retention Integration Architecture:

 

 

 

5.Retention Transactions (overview)

Catalog Info:

  • Get Terms – Institution and Term info
  • Get Sections – Section/Catalog info by term

 

Faculty and Staff:

  • Get Staff – Staff/Faculty/Advisors
  • Get Advising Relationship – Advising Relationship
  • Get Teaching – Teaching

 

Student Academic Records

  • Get Students – Students/student programs/Student Term info
  • Get Enrollments – Student enrollments and grades for current and transcripted sections and terms.

 

Student Engagement

  • Get Assignments – Assignments (LMS Only)
  • Get Attendance – Attendance (LMS Only)
  • Get Engagement – Engagement (LMS Only)

 

Group Batch Push

  • Push Retention (all files) – Group Batch for all files. Sends CSV flat files with same data found in each of the above GET commands.

 

 

 

6. How to use the APIs

Read the FAQ on how to use the HEDEX Web Service API’s – Link here

 

 

 

7. Retention Object Listing

The data objects represent the primary functional entities that are transmitted as part of the NoodleBus data integration standards. Each transaction can have a different primary object, but they can be related by the four main groupings – Catalog, Faculty and Staff, Student Academic Records, Student Engagement. For each primary object in a transaction, the integration may also include other related objects. Some of these objects can have multiple entries for each parent object (such as Student Terms to a Student). The method of packaging and transmitting these objects will vary depending on the transaction, the selected connectors, and their supported API options (batch file or web services).

 

The following list is a summary of the supported Retention Data Objects:

*Source (Priority):  The retention integrations are designed to pull data from both the Student Information System(SIS) and the Learning Management System (LMS).   Some objects only exist in the SIS, some only exist in the LMS, and some exist in both.    When data is available in both systems, the preference (i.e. priority in the chart above) will be to pull it from the Student Information System where there is usually more detailed information.    If a school is only able to pull data from the LMS, they can still send the objects, but it may not contain all of the fields you could get from the SIS.

 

 

 

8. Retention Core Database ERD

 

 

 

9. Retention Object Details

The following is a description of all the specific objects with their unique identifiers.  Note that many of these objects have several alternate identifiers.  You should always include your own id when posting if you have one (and there is a field supporting your identifier type).  If you are updating , you need to include the appropriate unique identifiers so the target system can recognize and match the specific object.

9.1 Terms

Description:

  • Terms

Unique Identifiers:

  • termCode
  • sessionCode

9.2 Sections

Description:

  • Course sections – A unique instance of a course in a term or session

Unique Identifiers:

  • termCode
  • sessionCode
  • subjectCode
  • sectionCourseNumber
  • sectionNumber

9.3 Staff

Description:

  • Faculty/Staff information and Status

Unique Identifiers:

  • <included with PERSON>

9.4 Staff Person

Description:

  • Faculty and Staff demographics (subset of Person data)

Unique Identifiers:

  • Each Person is uniquely identified by at least one for the following ID fields that must be unique:
    • personSisId – ID from the student information system
    • personCrmId – ID from the CRM or admissions system
    • PersonAlternateIDs – Array of additional ID fields and related ID type/system

9.5 Person Alternate IDs

Description:

  • Array of additional ID fields and related ID type/system

Unique Identifiers:

  • The following items must be unique within the array of objects:
    • personAlternateId
    • personAlternateIdType

9.6 Person Address

Description:

  • Array of Person’s Addresses with associated address type, start date and end date. A person can only have one active address for each address type.

Unique Identifiers:

  • addressType
  • addressStartDate
  • addressEndDate
  • <parent person identifiers>

9.7 Person Phone

Description:

  • Array of Person Phones with associated phone type. A person can only have one active phone for each phone type.  The array does not have status dates, so it should be considered the complete list for all valid phones in the array is included. However, the standard will not delete any phones that are not in the list.

Unique Identifiers:

  • phoneType
  • <parent person identifiers>

9.8 Person Email

Description:

  • Array of Person’s Emails with associated email type. A person can only have one active email for each email type. The array does not have status dates, so it should be considered the complete list for all valid emails in the array is included. However, the standard will not delete any emails that are not in the list.

Unique Identifiers:

  • emailType
  • <parent person identifiers>

 

 9.9 Advising Relationship

Description:

  • Information about an advisor’s relationship (with advising status) to a student for either a term or a date range.

Unique Identifiers:

  • advrId
  • studentId
  • advrTermCode
  • advrType

 

9.10 Teaching

Description:

  • Faculty Enrollments (teaching) for a section.

Unique Identifiers:

  • personSisId
  • termCode
  • sessionCode
  • subjectCode
  • sectionCourseNumber
  • sectionNumber

9.11 Student

Description:

  • Primarily contains the student student status

Unique Identifiers:

  • Included in Person

 

9.12 Student Person

Description:

  • Mostly Demographic data.

Unique Identifiers:

  • Each Person is uniquely identified by at least one for the following ID fields that must be unique:
    • personSisId – ID from the student information system
    • personCrmId – ID from the CRM or admissions system
    • PersonAlternateIDs – Array of additional ID fields and related ID type/system

 

 9.13 Student Terms

Description:

  • Student’s term specific information including student program information for each term, academic standing, GPA. etc.

Unique Identifiers:

  • personSisId
  • personLmsId
  • PersonAlternateIDs
  • termCode

 

 9.14 Student Enrollments

Description:

  • Student Enrollments for both current registered classes as well as completed (transcripted) course work. This includes grades for completed work.

Unique Identifiers:

  • personSisId
  • termCode
  • sessionCode
  • subjectCode
  • sectionCourseNumber
  • sectionNumber

 

 9.15 Assignments

Description:

  • Assignments for a student in a section.

Unique Identifiers:

  • personSisId
  • termCode
  • sessionCode
  • subjectCode
  • sectionCourseNumber
  • sectionNumber
  • assignmentType
  • assignmentLmsId

 

 9.16 Engagement Activity

Description:

  • Engagement Activity of a student in a Section

Unique Identifiers:

  • personSisId
  • termCode
  • sessionCode
  • subjectCode
  • sectionCourseNumber
  • sectionNumber

9.17 Attendance

Description:

  • Attendance records for a student in a section

Unique Identifiers:

  • personSisId
  • termCode
  • sessionCode
  • subjectCode
  • sectionCourseNumber
  • sectionNumber