DARTS : UMS Applicant Extract Usage, Contents, Evolution (2/6/19)

Created by Miki Yanagi, last modified by Unknown User (pavan.narayanan) on Mar 07, 2019

Date

 https://maine.zoom.us/j/3923818086

Attendees

  • Janet Boucouvalas - SPC
  • Jonathan Barker - USM
  • Rachel Groenhout - DARTS
  • Jeff Jensen - DARTS
  • Pavan Narayanan - DARTS
  • Miki Yanagi - DARTS

Discussion Items

  1. Our goal: Datamart and Admission Dashboard 
    1. Who else should be involved (from a standpoint of stakeholder-ship)?
      • UM- Michael Cooley- Orono uses TargetX mainly, so they may not use applicant extract.
      • UMA- Ariel Cassista 
      • USM- Brenda Berry, Jon Barker 
      • UMF- Jami Holmes - grad application is handled offline at UMF. 
      • System- Mike Kelly, Janet Boucouvalas 
    2. What aspects of the applicant extract do you think are most likely to be misunderstood by data users and data consumers who do not specialize in your functional area?
      • Ethnicity is confusing. An idea to consider: each ethnicity is one row. If student checks three ethnicity, we will have 3 rows of data.
      • UM_EXT_ORG_ID1 - External Org ID: Janet joins table, not using the fields on extract
    3. What aspects of the applicant extract do you think are most technically complex?

  2. Questions about Applicant Extract
    1. What databases and applications do you know of that it feeds? Who else might we need to consult in order to have a 100% complete list of targets sourced from the applicant extract?
      • Mike Kelly maintain feeds for all other applications. USM has own process.
    2. What user groups do you know of who depend on it (e.g., Admissions, IR, etc.)
      • SSSC meeting and go to Admissions for each campus and law school; Registrars, Bursars, FinAid, Admissions, Law, IR.
    3. Field Validity:
      1. Are there any fields that you KNOW are not accurate and you correct for their inaccuracies in your own work?
        • UM_ADMIT_DATE - Admit Date: When people reverse Matriculated date the calculation breaks. Conditional Admission blocks calculation for Admit Date. Deferred / conditional admit students
      2. Are there any fields or groups of fields that you suspect are not 100% accurate?
        • PROG_ACTION - Program Action/ PROG_REASON - Action Reason/ PROG_STATUS - Academic Program Status – these don’t update after census (should they?) Perhaps for existing usage it wasn’t an issue, but Academic Partnerships will pose a problem (see next bullet)
      3. Who else might have ideas for fields that may need review?
        • Need review: Academic Partnership’s 7 week courses. Students will apply/ enroll after census. Janet is not creating new admission term. Need to recognize two distinct sessions.
    4. Field Usage:
      1. Do you use any of the ethnicity fields? If so, which one(s)? When were they last validated/how confident are you of their accuracy?
      2. Are there any fields or groups of fields that you suspect are not used?
        • ROW_CHECK – on admission side
        • Calculated field with multiple programs in the same application- USM doesn’t do it. UM grad school was using, but not sure if this is current.
        • UM_ENROLL_DATE - Enroll Date: don’t think it’s accurate
        • RECRUITER_ID - Recruiter ID - nobody is using
        • APPL_FEE_TYPE - Application Fee Type; most don’t have app fee types
        • ADDRESS1-4 – USM don’t use because there are multiple
        • BIRTHPLACE - Birth Location / BIRTHSTATE - Birth State/ BIRTH_COUNTY - Birth County - not populated
        • MAR_STATUS - Marital Status/ MAR_STATUS_DT - Marital Status Date
        • EXP_GRAD_TERM - Expected Graduation Term - not populated
        • UM_NL_INDEX - Noel-Levitz Academic Index - nobody is using anymore
      3. Are there any fields that overlap with other data sources you use frequently? As in, are there items that you could source from elsewhere, but source from here so that you can get as much out of one record as possible?
    5. Contents:
      1. Are there any missing data elements?
      2. Are there any use cases that the applicant extract cannot currently serve but that you'd like it to?
  3. Is there anyone else who is still with the UMS and who has been involved in the evolution of the applicant extract over the years (involved from the standpoint of modifying specifications as needs change and/or involved from the standpoint of programming/re-programming as specs change?