Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Request No.2019-34
Date of RequestJuly 23, 2019
RequesterDaman Grewal, San Mateo CCD
Application(s)Standard/Noncredit 
International
Section / Page

Enrollment Page / Glue

ApprovalsYes - Jennifer Coleman, Lou Delzompo, CO
Proposed Change to Download File
Proposed Change to Residency Logic


Table of Contents


Problem / Issue

As part of the effort to streamline and enhance CCCApply for colleges, including getting data to colleges faster with more automation, is the ability for colleges to access student's in-progress application data is critical in order to providing support for the provide support and help the student through the application / on-boarding process.  

An ongoing concern raised by colleges using CCCApply is the inability to view/access in-progress applications in order to support students during the admissions process.

We need to implement new - or additional - consent to release information language and mechanism for students, and In order to provide pre-submission data to the college, we need student's Consent to release in-progress information and a mechanism to capture that consent (checkbox data field or flag)

implement a user-friendly, automated way to deliver the data to colleges through both data delivery methods (Download Client and Glue). Also colleges may need a user interface to view in-progress apps.


Target:  Students who start applications and do not finish them in one sitting.  The They hit a point in the application where they stop, save and leave the application.

NeedColleges College A&R and student services staff need an immediate, user-friendly, way to view the in-progress application informationapplications, so that A&R they can reach out - right away - to support help the student get through the application process.

NEED: Colleges need student's consent before they can view/see/collect the student's information.  

HOW:  Add a checkbox (data field) to the Enrollment page - right before or as they hit Continue or Save  (how this should look is being determined, meaning should this checkbox question appear on the page all the time or pop-up when the student clicks Continue or Save?)

The language in the Consent checkbox would include one of the statements below (drafts):

I authorize the California Community Colleges to release my contact information to one or more CCC colleges and/or affiliates that may wish to contact me before and/or after I have submitted my application to the College.

OR

authorize CCCAPPLY to release my contact information to XXX COLLEGE and/or affiliates that may wish to contact me before, during, and/or after I have submitted my Application for Admission to this college.


Workflow

An application becomes doesn't become an official application until AFTER the user the student completes the fields on the Enrollment page, and either Saves or Continues from the Enrollment pageIs this the point where the In-Progress DB stores the data?

Following completion of the Enrollment page, Glue could send page-level chunks of information to the Student Profile, DW, and College SIS.  
(NOTE: If the DW is also considered the "CCCApply Report Center" - then a college could run a report at anytime to see applications that have been started, but not submitted, and contact the student.


What do we know about the student after they complete the Enrollment page?

  • College Applying To (Apply)
  • CCCID (OpenCCC)
  • Legal, Preferred, and Previous Names (OpenCCC)
  • Permanent Address (OpenCCC)
  • Date of Birth (OpenCCC)
  • SSN (maybe not after new OpenCCC design - check this out)
  • Phone number (possibly depending on OpenCCC design)
  • Whether they've authorized text messaging or not  (possibly depending on OpenCCC design)
  • Email Address (OpenCCC)
  • Term Applying for (Apply)
  • Major / Intended Program of Study (Apply)
  • Meta Major (Apply; Optional)
  • Education Goal (Apply)

This data could be enough for the college to contact the student and help them complete their application. Following completion of the Enrollment page, Glue could send page-level chunks of information to the Student Profile, DW, and College SIS.  (NOTE: If the DW is also considered the "CCCApply Report Center" - then a college could run a report at anytime to see applications that have been started, but not submitted, and contact the student.


Next steps:

Query colleges on what they need out of this project?
What are the goals for doing this?
What do you need in terms of data to accomplish these goals? 

A full account of all fields 
Subset of data fields


Research Questions

What happens now during our auto-population process?  Will all auto-filled data be sent to the college?

What is delivered from CCGI - how does this affect this process, if at all?

What is delivered from CDE - how does this affect this process, if at all?


(Jane Linder - 9.6.19 meeting - is working on a high-level flow chart of the data flowing from Account > Apply > chunks of data > to college)


Proposed Solution

In order to pass in-progress application data to the colleges using the current CCCApply applications, several changes would have to be implemented, including language disclosure, placement of language and mechanism to obtain consent, and new development to integrate real-time data with colleges via Super Glue or other automation method.

  • Revise onscreen Consent page for current and mobile versions of Apply
  • Update the Consent language in the Terms of Use and Privacy Policy*
  • Add mechanism to obtain Consent (with language) on the Enrollment page or the My Applications page
  • Explore different levels of consent at different points in the process (OpenCCC account creation, enrollment page, submission)
  • Implement ability for data delivery using SuperGlue to allow colleges automated access to student data earlier in the application process
  • Implement user interface or other mechanism for college Admissions staff to see in-progress application data 
  • Adjust the current CCCApply Privacy Policy to include language that will disclose what we want to give college(s) and students, as well as "how".

  • Implement an additional, legal, consent mechanism (pop-up box or question) where students are informed and provide consent to share data with college (directory information, in-progress application data, and full submitted application data) with the college they intend to apply to.

See "Revise Consent to Release Information Language in CCCApply" for second part of this project.


Background Information Supporting This Project

Ever since OpenCCCApply was developed under the CCCTC, colleges have requested the ability to see when a student starts an application to their college but doesn't complete / submit that application. The ability to see in-progress applications was previously delivered in the Xap CCCApply system in their administrator tool.  At the time OpenCCCApply was designed, this capability was removed based on the understanding that providing that data to the college prior to their consent to release information permission was obtained and submitted via electronic signature, that this process was an infringement on the student's privacy (per FERPA and ? what other legal organization or mandate?).

However, many other state and national admission application products are allowing colleges to see in-progress data (example CSU, and the Common Application) and therefore a call to implement similar functionality in CCCApply is being requested.

  • Deliver CCCApply web app as a  stepping stone to on-boarding process
  • Get colleges the data they need for Admissions (college operations)
  • Get colleges the data they need for on-boarding

  • Get colleges the data they need for residency
  • Flexibility - move questions around - add defaults - tweak question and response option language - conditional questions/logic  (Survey Gizmo)
  • Access to student information prior to submission -
  • Background Information
    Info
    Info

    Change in Process from XapCCCApply
    Up to this point (2019), the CCCCO policy has been to prohibit access to student data until the student has the submission of the application (student agrees to release their application data and electronically sign/consents to this level of access). Now, as part of the CCCApply Redesign effort, and backed by widespread outcry by colleges, the Chancellor's Office (led by Omid) is willing to support an implementation that would provide early and often access to in-progress data via CCCApply.

    Requirements

    • Adjust the current CCCApply Privacy Policy to include language that will disclose what we want to give college(s) and students, as well as "how".

    • Implement an additional, legal, consent mechanism (pop-up box or question) where students are informed and provide consent to share data with college (directory information, in-progress application data, and full submitted application data) with the college they intend to apply to.

    (Jane Linder - 9.6.19 meeting - is working on a high-level flow chart of the data flowing from Account > Apply > chunks of data > to college)

    Proposed Solution

    In order to pass in-progress application data to the colleges using the current CCCApply applications, several changes would have to be implemented, including language disclosure, placement of language and mechanism to obtain consent, and new development to integrate real-time data with colleges via Super Glue or other automation method.

    • Revise onscreen Consent page for current and mobile versions of Apply
    • Add Consent language to Terms or Privacy Policy*
    • Add mechanism to obtain Consent (with language) on the Enrollment page or the My Applications page
    • Explore different levels of consent at different points in the process (OpenCCC account creation, enrollment page, submission)
    • Implement ability for data delivery using SuperGlue to allow colleges automated access to student data earlier in the application process
    • Implement user interface or other mechanism for college Admissions staff to see in-progress application data 


    See "Revise Consent to Release Information Language in CCCApply" for second part of this project.
    • Deliver CCCApply web app as a  stepping stone to on-boarding process
    • Get colleges the data they need for Admissions (college operations)
    • Get colleges the data they need for on-boarding
    • Get colleges the data they need for residency
    • Flexibility - move questions around - add defaults - tweak question and response option language - conditional questions/logic  (Survey Gizmo)
    • Access to student information prior to submission -


    Note

    Internal Use Documentation:  Requirements can be found here: https://cccnext.jira.com/wiki/x/M4E8Ng

    Screenshots



    Dependencies, Risks and/or Reporting Requirements?


    Question

    Yes

    No

    Which data field(s)?

    What/How?

    Would this change affect an existing question or data field on the Standard Application?
    •   
    •   


    Would this change affect an existing question or data field on the International Application?
    •   
    •   


    Would this change affect an existing question or data field on the Promise Grant Application?
    •   
    •   


    Would Account (OpenCCC) data be affected by this change?
    •   
    •   


    Does the question or data field align to an MIS reporting requirement now?
    •   
    •   


    Does this change affect any other state or federal regulations or requirements?

    •   
    •   


    Would this change affect existing residency logic?
    •   
    •   


    Would any other data fields be affected by this change?
    •   
    •   


    Would students users be affected by this change?
    •   
    •   


    Would colleges be affected by this change? 
    •   
    •   


    Would the Download Client be affected by this change?
    •   
    •   


    What other tech center web services will be affected by this change?
    •   
    •   

    i.e., Glue staging table?  Multiple Measur
    Other dependencies?



    Other implementation considerations?





    Supporting Documentation