Admissions Standards

Admissions Standards

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

Index:

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

 

 

 

1. What is the Admissions Core?

The Admissions Core is the central component in the NoodleBus for all the recruiting and admissions 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. Admissions Core Connectors

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

  • Student Information Systems (SIS)
  • Enrollment CRMs
  • Lead Generation Systems
  • Application Systems
  • Recruiting and Admissions Coaching Systems
  • Document Imaging Systems (ECM – Enterprise Content Management)
  • Enrollment Analytics Systems (such as Noodles Analytics for OPM)

 

 

 

3. API Documentation – SWAGGER:

 

 

 

 4. Admissions Integration Architecture:

 

 

 

 

 5. Admissions Transactions (overview)

  • /Admissions/All

The set of admissions transactions for post, get, and push are designed to include the full set of all admissions objects and fields. This is used as a mass API to create or update a batch of records with a specific individual and ANY of their related admissions data. The list of data objects included in these transactions are:  Person, Person Alternate IDs, Person Address, Person Phone, Person Email, Prospect, Applicant, Application, Source, Activity, Rating, Checklist Items, Financial Aid, Education, Credentials, Test Scores, Relation, Relation Address, Relation Email, Relation Phone, Events

API Documentation – SWAGGER

Sample Flat-File Format

  • /Prospects

The set of Prospect transactions for post, get, and push are designed to include objects and fields related to the recruiting lead. This is used as a method to create or update a batch of records with specific individuals and their contact information, recruiting/coaching rep, lead source, ratings, and other related specifically to recruiting. The list of data objects included in these transactions are:   Person, Person Address, Person Phone, Person Email, Prospect, Source, Rating

API Documentation – SWAGGER

Sample CSV Format (Available soon)

  • /Activity

The set of Activity transactions for post, get, and push are designed to include objects and fields related to the recruiting activity (coaching or recruiting rep interactions with the prospect). This is used as a method to create or update a batch of records with specific individuals and their recruiting activity. The list of data objects included in these transactions are:  Person, Prospect, Activity

API Documentation – SWAGGER

Sample CSV Format (Available soon)

  • /Applications

The set of application transactions for post, get, and push are designed to include objects and fields related to an application. This is used as a method to create or update a batch of records with specific individuals and their application data. The list of data objects included in these transactions are:  Person, Person Alternate IDs, Person Address, Person Phone, Person Email, Prospect, Applicant, Application, Source, Financial Aid, Education, Credentials, Test Scores, Relation, Relation Address, Relation Email, Relation Phone

API Documentation – SWAGGER

Sample CSV Format (Available soon)

  • /Checklists

The set of Checklist transactions for post, get, and push are designed to include objects and fields related to an applications checklist of received documents and completed activities. This is used as a method to create or update a batch of records with specific individuals and their application checklist data. The list of data objects included in these transactions are:  Person, Applicant, Application, Checklist Items

API Documentation – SWAGGER

Sample CSV Format (Available soon)

 

 

 

6. How to use the APIs

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

 

 

 

7. Admissions Core Object Descriptions

  • Person: Primary Object. Mostly Demographic data.
    • Person Alternate IDs: Person’s Alternate IDs with Agencies.
    • Person Address: Person’s Addresses with type
    • Person Phone: Person’s Phones with type
    • Person Email: Person’s Emails with Type
    • Education: Person’s Educational History (Per institution)
      • Credentials: Academic Credentials for Person at institutions
    • Test Scores: Test Scores for Person
    • Relation: Person’s related Family Members
      • Relation Address: Addresses for each relation
      • Relation Email: Emails for each relation
      • Relation Phone: Phones for each relation
    • Prospect: Lead/Prospect data for Person
      • Program Interests: Specific Program/Start (term or date)
      • Source: Lead Source information for Prospect and, optionally, program interest.
      • Activity: Lead contact activity by recruiter or coach for Prospect and, optionally, program interest.
      • Rating: List of recruiting ratings with different rating types for Prospect and, optionally, program interest.
      • Events: Event Registrations
    • Applicant: Applicant Data for Person (1 to 1 with prospect)
      • Application: Application Data for Person/Applicant
        • Checklist Items: List of application checklist items with Status Related to: Application Relation Type: Multiple
        • Financial Aid: Financial Aid Award information Related to: Application Relation Type: Multiple
    • Extra Object: Extra Object(s) for Custom Data
    • Batch Transaction: Transaction Object for entire Batch (all records)
    • Item Transaction: Transaction Object for single Item (each record in primary object)
    • Transaction Data: Standard object used by every object to store transaction statuses and Routing Details.

 

 

 

8. Admissions Core DataBase ERD:

 

 

 

9. Admissions Core Object Details and Primary Keys

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    Person

Description:

  • Mostly Demographic data.

Parent Object:

  • Primary Object

Unique Identifiers:

  • Each Person is uniquely identified by at least one of 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.2    Person Alternate IDs

Description:

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

Parent Object:

  • Person

Unique Identifiers:

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

 

9.3    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.

Parent Object:

  • Person
  • Each Person has zero, one, or multiple Person Addresses

Unique Identifiers:

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

 

9.4    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.

Parent Object:

  • Person
  • Each Person has zero, one, or multiple Person Phones

Unique Identifiers:

  • phoneType
  • <parent person identifiers>

 

9.5    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.

Parent Object:

  • Person
  • Each Person has zero, one, or multiple Person Emails

Unique Identifiers:

  • emailType
  • <parent person identifiers>

 

9.6    Prospect

Description:

  • Lead/Prospect data for a Person

Parent Object:

  • Person
  • Each prospect has one person, each person has one or zero prospects.

Unique Identifiers:

  • <parent person identifiers>

 

9.7    Program Interests

Description:

  • Array listing each prospect’s interest in specific program/start (term or date).

Parent Object:

  • Prospect
  • Each Prospect has zero, one, or multiple Program interests

Unique Identifiers:

  • The program interests for a prospect are unique to the program code and either a start term or a start date (for non-term programs)
    • prospectAcademicProgram
    • prospectStartTerm
    • prospectStartDate
    • <parent person identifiers>

 

9.8    Applicant

Description:

  • General information for a person as an applicant. Parent object for applications.

Parent Object:

  • Person
  • Each applicant has one person, each person has one or zero applicants. Each applicant should also have a prospect to store the activity information.

Unique Identifiers:

  • <parent person identifiers>

 

9.9    Application

Description:

  • Application Data for Person/Applicant.

Parent Object:

  • Applicant
  • Each applicant can have zero, one, or multiple applications

Unique Identifiers:

  • Applications usually have a unique ID assigned by the admissions system. An application is unique for an applicant, program, and start term (or start date for a non-term program).
    • applicationSisId
    • applicationCRMId
    • applicationAlternateIds array
    • academicProgram
    • startTerm
    • startDate
    • <parent person/applicant identifiers>

 

9.10 Application Alternate IDs

Description:

  • Array of alternate IDs and type/systems for a applications. This is used if the application is not sourced from an SIS or CRM/admissions system.

Parent Object:

  • Applicant

Unique Identifiers:

  • applicationAlternateId
  • applicationAlternateIdType

 

9.11 Source

Description:

  • Lead Source information for Prospect and, optionally, program interest.

Parent Object:

  • Prospect or Program Interests

Unique Identifiers:

  • A source is unique by source code for each prospect or a Prospect’s program or interest.
    • <parent prospect identifiers>
    • sourceProgramOfInterest – not required
    • sourceStartTerm – not required
    • sourceStartDate – not required
    • sourceIds – array of source Ids by type or system – not required
    • sourceCode

 

9.12 Activity

Description:

  • Lead/Prospect/Applicant contact activity by recruiter or coach for Prospect and, optionally, program interest.

Parent Object:

  • Prospect, Program Interests, or Application

Unique Identifiers:

  • An activity is unique for a specific external activity ID associated to a prospect, or an application, or a Prospect’s program or interest.
    • <parent prospect identifier> – Required
    • activityProgramOfInterest – Not Required
    • activityProgramStartTerm – Not Required
    • activityProgramStartDate – Not Required
    • activityIDs – array
    • activityApplicationId– Not required

 

9.13 Rating

Description:

  • List of recruiting ratings with different rating types for Prospect, program interest, or application.

Parent Object:

  • Prospect, Program Interests, or Application

Unique Identifiers:

  • A rating is unique by rating type for a prospect, or an application, or a Prospect program or interest.
    • <parent prospect identifier> – Required
    • ratingProgramOfInterest – Not required
    • ratingStartTerm – Not required
    • ratingStartDate – Not required
    • ratingType – Required
    • ratingApplicationId – Not required)

 

9.14 Checklist Items

Description:

  • List of application checklist items with Status.

Parent Object:

  • Application
  • Each application can have zero, one, or multiple checklist items

Unique Identifiers:

  • A checklist item is unique for…
    • checklistItemCode
    • checklistItemStatus
    • checklistItemDate
    • <parent application identifiers>

 

9.15 Financial Aid

Description:

  • Financial Aid Award information.

Parent Object:

  • Application
  • Each application can have zero, one, or multiple financial aid items

Unique Identifiers:

  • A Financial Aid item is unique for…
    • financialAidType
    • <parent application identifiers>

 

9.16 Events

Description:

  • Events attended for a prospect

Parent Object:

  • Prospect

Unique Identifiers:

  • Events are unique for each
    • eventAttended
    • eventAttendedDate

 

9.17 Education

Description:

  • Person’s Educational History (Per institution)

Parent Object:

  • Person
  • A person can have zero, one, or multiple education records

Unique Identifiers:

  • Education is unique for each institution a person attended. At least one of these fields need to be provided and unique:
    • institutionAttendedCeebCode
    • institutionAttendedFiceCode
    • institutionAttendedName
    • institutionAttendedAlternateIds – should we add this array?

 

9.18 Credentials – EducationCredentials

Description:

  • Academic Credentials for Person at institutions.

Parent Object:

  • Education
  • An education record can have zero, one, or multiple credential records

Unique Identifiers:

  • A credential item is unique for…
    • credentialInstitutionId – Which ID is this?
    • institutionAttendedDegreeObtained
    • institutionAttendedDegreeDate

 

9.19 Test Scores – PersonTestScores

Description:

  • Test Scores for a person

Parent Object:

  • Person
  • A person record can have zero, one, or multiple test score records

Unique Identifiers:

  • Test Scores are Unique by
    • testName
    • testDate
    • <parent person identifiers>

 

9.20 Relation

Description:

  • Person’s related Family Members.

Parent Object:

  • Person
  • A person record can have zero, one, or multiple relation records

Unique Identifiers:

  • A relation is unique based on the unique relation individual. There are no constraints on having Unique relations by type.
    • <parent person identifiers>
    • relationFirstName
    • relationLastName
    • <note – there is currently not a unique relation ID>?

 

9.21 Relation Address

Description:

  • Addresses for each relation

Parent Object:

  • Relation
  • A relation record can have zero, one, or multiple relation address records

Unique Identifiers:

  • Relations have a unique address for each address type:
    • relationAddressType

 

9.22 Relation Email

Description:

  • Email addresses for each relation

Parent Object:

  • Relation
  • A relation record can have zero, one, or multiple relation email records

Unique Identifiers:

  • Relations have a unique email address for each email type:
    • relationEmailAddressType

 

9.23 Relation Phone

Description:

  • Phones for each relation

Parent Object:

  • Relation
  • A relation record can have zero, one, or multiple relation phone records

Unique Identifiers:

  • Relations have a unique phone for each phone type:
    • relationPhoneType