Lead/Admissions Denodo Date Roadmap

Phases:

A. Person

1. Basic bio/demo data

2. Review and revision period

3. Advanced bio/demo data

   1. Undergraduate school

4. Custom requests

B. Application

1. Basic application data

2. Review and revision period

3. Advanced application data

4. Custom requests

C. Interaction/Activity/Source Data (Inquiry Details)

1. Basic interaction activity (incl. program of interest)

2. Review and revision

3. Advanced interaction activity

   1. Messages

4. Custom interaction activity

D. Messages (Deliver Campaigns)

What does “done” look like?

• Query in Slate is built and configured with web services
• Denodo “view” is built?
• Data refresh is scheduled/ongoing
• Field definitions are added
• Query description is added
• Access/permissioning is configured?

Notes:

• Do we need a “beta” period?

• Feedback from stakeholders/clients--how to factor that into the project plan?

• How do we handle ongoing requests/concerns

• Capturing the next “core fields” for the University

• Goal is to build a dashboard that is used for all schools

• Gather admisisons directions to create standard definitions (e.g. Veterans)

  • Under Data Governance Committee

  • Advisory vs. Directive?

• Slate team builds the queries sent to Denodo that creates the “base view” – only for DSE

Questions for Group meeting/Matt

• What happens to old data?

• More access to update fields?

• Who is in charge of naming fields/naming conventions?

• Where do we solve the “fuzzy” definitions, in Slate or Denodo? To the “university” standard?

  • e.g. socioeconomic indicator

  • school-specific clarifications happen in Slate, University wide “joins”/translations happen in Denodo?

    • e.g., definition of “admitted” is school-specific?

    • e.g., IPEDS classification is University/Denodo?

Data Collections

1. Person

   1. Simple bio/demo data

2. Application

   1. Simple program/app data

   2. Funnel Dates

      1. Complete Date

      2. Interview Date

   3. Invite to Interview Flag

   4. Fee waived

   5. HRSA/Socioeconomic Indicators

   6. Application review indicators

      1. GPA

   7. Decline for institution

3. Schools

4. Engagements

   1. Lead Form submissions

   2. UCM/Hubspot

   3. First Source

   4. Flags

      1. Submitted a form

      2. Registered for an event

      3. Contacted the school

5. Program Dataset (Meta data about programs)

   1. Cycle dates

      1. Application Open

      2. Application Deadline

      3. Decision dates

      4. Semester Start date (race release)

   2. Program length

   3. Program launch date/term

   4. Program close date

   5. Program Application Review stuff

      1. Do they require interviews?

      2. Rolling admission?

      3. Number of required recommendations

      4. Required test scores?

      5. Definition of complete application

      6. Requirements for complete post-submission? What is collected after you submit?

   6. Fee waiver process?

   7. Application fee amount?

   8. Location

   9. Format/Modality

   10. Degree or non-degree

   11. SIS codes

   12. PF codes

   13. Tuition

   14. Scholarship?

   15. Program Staff (use for content blocks?)(use the existing user table?)

       1. Admissions Director

       2. Manager, etc.

       3. Admissions Counselor/staff

   16. Program selectivity rating

Instances

1. Vet

2. Nutrition

3. GSBS

4. TUSMGP

5. Fletcher

Milestones

1. Identify data to be provided

2. Identify level of data inaccuracy

3. Identify causes of data inaccuracy

4. Retroactively “fix” inacurate data

5. Business process to ensure data remains accurate

6. Audit process to identify future inacuracy

7. Slate Query v1

8. Data review/validation

   1. Review internally (Helen or Beth cross-check)

   2. External stakeholders (Brian,

9. Slate Query v2

10. Refresh/Add query to Denodo