Release 6.4.0 Summary Notes

Release Schedule

Description

Date & Time

Release No.

6.4.0

Pilot Release

02.19.19 - 9:00AM PST

Production Release

03.15.19 - 6:00PM PST

Release TypeMaintenance Window | Major Release

Release Scope

DescriptionScope
Applications

CCCApply Standard Application (Apply)
CCCApply International Application (IA)

Changes to Residency LogicNo
Changes to Download ClientYes - (Download Client Jar 6.4.0)
Changes to DocumentationYes - Data Dictionaries & User Guides

Contents


Release Scope  

#Change RequirementApplicationNotes & Change Request Docs
1CCCApply Redesign Project - User Interface Enhancements CCCApply Standard & International Applications

See "Changes to User Interface" section
See "Changes to Download Client" section
See "New & Changed Data Fields" section 

2

CCCApply Noncredit Application Path (Phase 1: Development)

CCCApply Standard Application onlyCCCApply Noncredit Application
3

Maintenance & Support  (Admin Support, Tech Updates, and Bug Fixes)

CCCApply Standard & International ApplicationsSee "Maintenance & Support" section
4Bug FixesCCCApply Standard ApplicationSee "Bug Fixes" section
5Issue Resolution: Problems with new Race & Ethnicity Data Fields
(Version 6.3.0, Dec 2018)
CCCApply Standard & International Applications

See "Issue Resolution" section

Included in Hotfix 6.3.1 - January 25, 2019

Back to Top


Release Summary

This is the third release of the CCCApply Redesign Project under the guidance of the CCC Chancellor's Office, the CCC Technology Center, and the CCC Foundation to revise the CCCApply application in compliance with AB 3101. Read more about the CCCApply Redesign Project, including the project objectives and project release schedule for the first phase of the project and future long-term plans to rebuild the application (holistic redesign). Also included in the redesign project, CCCApply Noncredit Application - Phase 1: Development, and information about the soft-launch of the College Pilot Project.

Pilot Release

The Pilot environment release is scheduled for February 19, 2019. This period is for colleges to preview interface changes and test bug fixes and prepare for new or changed data fields prior to the production release (March 15). The CCCApply Support Services team will be monitoring feedback on the CCCTechnology.info support site, and additional online support information will be available.

Release Schedule & Timeline

  • February 19 - 9:00AM - 1:00PM (Note the Pilot Site will be down during this release).
  • March 16 - 6:00PM - 11:00PM - Production Maintenance Window


Stay Informed!  For news, release announcements, updates, and CCCApply System Alerts, follow us on "CCCApply System Alerts" on CCCTechnology.info.


Back to Top


Changes to the CCCApply Standard Application

The following changes and enhancements were approved and deployed in the 6.4.0 release code.

#
Change Specification
Additional Info
1

CCCApply Redesign - User Interface Enhancements

Approved changes intended to shorten & streamline the Standard App
CCCApply Redesign Project (Release 3)
CCCApply Redesign Project Dashboard - Release Timeline
CR: 2018-37B: Low-Hanging Fruit #2



Revise layout of the Residency page 

See Changes to User Interface section below.


Remove/Hide Questions from Special Residency Section Depending on Out-of-State Activity Response

Hide the following questions in the Special Residency section by default for all users

  • Pubic School Employee
  • State College Employee
  • Seasonal Agricultural Worker

See changes to field values in Changes to Downloads below.

See Changes to User Interface section below.



Revise  the "Out-of-State Activities" section on the Residency page and add skip logic to Show Special Residency questions




Revise/Hide Question on the Education pageSee changes to field values in Changes to Downloads below.
2Noncredit Application Path (Phase 1: Development)See the CCCApply Noncredit Application
See the Noncredit Application Path Requirements


Implement a new workflow path in the Standard Application, with no residency questions and does not calculate a preliminary residency determination via the Submission Calculation Service. 

For students enrolling exclusively in noncredit courses; no credit is given. 

See Noncredit Path Change Requirements



Implement new URL exclusively for the Noncredit path in the Standard Application. Unique for each college, based on MIS code. Replace XXX with college MIS code.

Example:  https://pilot.opencccapply.net/cccapply-welcome?cccMisCode=XXX&nonCredit=True



Revise the Confirmation number (prefix) for applications started and submitted using the Noncredit URLTo identify and distinguish Noncredit applications from Standard applications, Noncredit confirmation numbers have a prefix "NC-" for all applications that are started and submitted using the Noncredit URL. Example: "NC-4144323"


Hide the Citizenship & Military page in the Noncredit App/PathSee Changes to User Interface below.


Hide the Residency page in the Noncredit App/PathSee changes to field values in Changes to Downloads below.


Hide questions on the Needs & Interests page in the Noncredit App/PathSee Changes to User Interface below.


  • Hide "Comfortable with English" question
  • Hide "Financial Assistance" question
  • Hide "SSI CalWorks GA" question
  • Hide "Athletic Interest: question
See Changes to User Interface below.


Add a new "Noncredit Status" data field to Standard Application and set flag to "True" when the Noncredit URL is used

See New & Changed Data Fields section
See Changes to Downloads below.
See Noncredit Path Change Requirements



Add new "Integrity Flag 81" data field to the Integrity Flags table (Standard Application) and trigger if applicant applies using the Noncredit URLWhen Integrity Flag 81 is triggered, admissions office is flagged, "Applicant applied using the Noncredit Application URL"


Add new value to the "Residency Status" field to identify "noncredit / exempt" statusSee New & Changed Data Fields section
See changes to field values in Changes to Downloads below.


Exclude Noncredit App/Path from residency determination logic If the new "non_credit" flag is set to "True" - the application is not put through the Submission Calculation Service and the residency status field is set to "N = noncredit / exempt"


Add new value to "Residency Areas" status fields to identify "noncredit / exempt" statusSee changes to field values in Changes to Downloads below.


Add logic to allow student's who submitted a Noncredit application using the Noncredit URL to re-apply to the same term, same college using the Standard ApplicationSee Noncredit Path Change Requirements
Removed restriction for Noncredit > Standard Application transition only. 


Implement auto-population for fields hidden in the Noncredit Application if student re-applies using the Standard Application within 2 years.Noncredit students may want/need to re-apply to enroll in credit courses. They should re-apply using the Standard Application to get residency-determination status. 
See Noncredit Path Change Requirements
3 Maintenance & Support Changes


Add new v.6.4.0 fields to CCCApply Administrator Rules module:
  • Noncredit Status
  • Integrity Flag 81
The new v.6.4.0 data fields have been added to the Rules module in the CCCApply Administrator, and can now be used in college email rules and error messages.


Add new v.6.4.0 fields to CCC Report Center domain and Full Application report templates:

  • Noncredit Status
  • Integrity Flag 81
The new v.6.4.0 data fields have been added to the Report Center. The Full Application report has been updated with these fields. Colleges can now be used in custom reports.


Add v.6.3.0 fields to the CCC Report Center and the CCCApply Administrator Rules module:

  • Race Ethnic Full  (Pilot & Prod)
  • Fraud Score  (Pilot & Prod)
  • Fraud Status  (Pilot & Prod)
Due to a bug in the Report Center admin service, these tasks were unable to be completed after the 6.3.0 release (Dec 2018).


Add v.6.3.0 & 6.4.0 fields to the "Full Application" Report templates in the CCC Report Center

  • Race Ethnic Full  (Pilot & Prod)
  • Fraud Score  (Pilot & Prod)
  • Fraud Status  (Pilot & Prod)
  • Noncredit Status  (Pilot Only)
  • Integrity Flag 81  (Pilot Only)

Bug Fixes

#Bug DescriptionFix Details

Issues: Problems with new Race & Ethnicity field values that were implemented in v.6.3.0 (Dec 2018)


Issue 1
In-progress applications - applications that were started before the new Race & Ethnicity disaggregation implementation on December 14, 2018 - and submitted after the 6.3.0 release are delivering bad values (not translated into the new format) to college downloads and the Report Center.


Solution 1: 
See "Issue Resolution: Problems with the New Race & Ethnicity Data Fields"

For affected submitted Apply and IA applications that have been submitted post Dec 14, 2018 and downloaded by the college, the old values stored in the DB were sent over with submitted application without being translated to the XNY MIS Format. The formats are wrong in this use case and were to be fixed. Worst case scenario, the SIS has bad values and the colleges may/may not even be aware. See "Issue Resolution: Problems with the New Race & Ethnicity Disaggregation Project 2018"



Issue 2
The SPAM training is not working. After developer research, the training process began to fail because of the bad race/ethnicity values in the submitted apps table. 

Solution 2: Unlike Issue 1, where the number of applications at-risk of being affected (in-progress applications) is diminishing over time, Issue 2 potentially affects a larger number of applications that are not going through the spam filter training service due to the bad race values in the submitted applications table. This issue necessitated a hot fix release (Hotfix 6.3.1) which was deployed Friday, January 25, 2018 to production.

Temporary workaround to app-export service so that it skips over any records that do not have the XYN format in the race ethnicity field. Records that contain numbers and commas should NOT be output since it breaks the SPAM retraining model.


Issue: Missing Instructional Text in the new Race & Ethnicity Section that was intended for original implementationSolution: Added missing instructional text for the Race/Ethnicity Section to read as follows:

Check all of the ethnicity, nation, and ancestry groups that you identify with. When you select a major ethnicity group, you will have the option to select more specific ancestry groups. Select all that apply.


Issue: Applicants reported getting 'Application not completed' email after successfully submitting their application

The issue affects any college with pre-submission rules and NO supplemental questions, this explains why our development team didn't find this during regression testing, as our testing of college rules is based on a feature to allow rules to run against supplemental question fields.

Solution: we fixed the residency calculations, as well as multiple other calculations we have to set residency flags, to happen when the user clicks the submit button. We run the pre-submission colleges rules before these calculations happen however. The flow is something like:

User fills out submission page -> run submission validation -> run college validation rules -> run residency calculations

What appears to be the root cause of this ticket is a null pointer exception thrown when we attempt to run the college validation rules. In the process of running the rules, we convert the application to its submitted format so that the field names and properties match up to the various database columns we map to on the submitted side so the colleges can reference the fields that way in the rules. To convert the residency flags, we call the toString() method on this object and if it is initialized then it throws an NPE.

If the college has supplemental questions, we run the residency calculation flow during the transition from the supplemental questions page to the submission page so the flags get properly initialized. However, if the college does not have supplemental questions, as is the case with Moreno (All of their supplemental questions as set to "active = false" in Prod), then the calculations that would populate these flags only occur after the flags have caused the NPE.


Issue: Fixed length varies with new download client

Problem: We added code that would strip out characters in what is called the "multilingual Supplementary Plane" of the unicode encoding. Unfortunately, some characters are not in that plane, but it still requires 3 bytes to encode it. 

Solution: We updated the way we handle UTF-8 3 and 4 byte characters in the "Basic Multilingual Plane".  Added flag to the download client to output code to either UTF or ASCII.
Default is set to ASCII.

Updated the Download Client User User v.2019.1


Issue:  Missing validation in the Date of Birth field allowing future DOBs to be submitted

Solution: An applicant who submitted their application on 10/22/18 was allowed to provide a future date of birth of 01/20/19.  Added logic that prevents an applicant from entering and saving a DOB that is a date greater than the current date:

  • Introduced logic so that a user is not allowed to enter a birthdate in future. Logic states that be date cannot be greater than today's date <current_date> of application.
  • Error validation was also added in place to display the following: "Your date of birth must be before today’s date.

Issue: Address confirmation modal was not being displayed to homeless applicants

Solution: Implemented a fix to deliver expected behavior. The following message is now successfully displaying:

The street address you entered does not appear to be a valid address. Please review the address and correct it or check the box that you have verified the address if you are sure it is a correct address.


Issue: Edit Account app is incorrectly saving the country code (i.e., U.S.) to the Phone Number Extension field and leaving the country code blank when the users went to edit their account in the applications.

Solution: Edit Account systems in the Standard, Promise Grant, and International Apps is now mapping and saving the correct phone number data values for the phone number, the extension, and the country code, etc., for the respective phone number for the Account Main and Secondary phone numbers after editing an account.


Issue: International App not saving the Current Mailing Postal Code correctly in downloads

Solution: Fixed an issue on the Account Information & Mailing page, where the database was not storing the same data values for the Current Mailing Address fields when the applicant checks the box stating that it is the "Same as their Permanent Address".  QA has verified that these data values now match in the database.

Back to Top


Issue Resolution: Problems with the New Race & Ethnicity Data Fields

Problems Encountered After Deployment of the New Race & Ethnicity Implementation (v.6.3.0, December 2018)

In the CCCApply 6.3.0 release (December 2018), CCCApply was updated to include a larger set of race groups and ethnicities as part of the 2018 Race & Ethnicity Disaggregation project. The objective of the project was to expand upon the race groups and ethnicities collected in CCCApply and disaggregate the existing race groups in order to support student equity services across the system.

  • The objectives for development was to add over 200+ new race groups and ethnicity options to the database (and to the user interface) for delivery to the college, but still also maintain delivery of the original data fields and values for MIS reporting. In order to deliver both these files, we had to refactor the code in the background to ensure the data was clean and easy to maintain.

  • Before the 6.3.0 release, the raw values for the users choices were stored to the database column "race_ethnic" in a CSV format (example: "02, 03, 06, 16"). At submission time, this would be translated to the MIS format of "YYYNNYNNNNNNNNNYNNNNN" and stored in the "race_ethnic" column of the submitted application. In the process of the new implementation, we changed where we do this translation to whenever the user saves their demographic information so that in the new code we are never storing the raw values, we are always storing the "YYYNNY..." format to the race_ethnic column.

  • At submission time, this value is sent over directly with the submitted application without needing translation at submission time. However, a use case that is often challenging to significant development changes to CCCApply are the "in-progress applications" that are started but not submitted before a major release. This was also the case with this implementation, and we ran into an issue with applications that were started before the 6.3.0 release on December 14th, 2018 and resumed after the release to a page that was after the Demographic Information page. In this case the old, raw values would still be stored with their in-progress application, loaded from the database and submitted with their application.

  • Note that this only affects applications that were resumed directly to a page after the Demographic Info page which are the Supplemental Questions page or the Submission page and then submitted without the user going back through the Demographic information page and revising their responses for the new Race & Ethnicity format and layout. Due to the nature of this bug (affecting in-progress applications), the number of applications that will be submitted that were in-progress before Dec. 14th is limited and will diminish over time. In fact, by the time the issue was identified, researched, and resolved - we saw a significant decline in reports from colleges and the number of at-risk, in-progress applicants diminished as predicted.   

Types of Issues Reported

Immediately following the 6.30 release, we received requests for support from 6 colleges related to:

  • Problems with bad data interrupting download processes
  • Bad data appearing in Report Center reports

Work-arounds proposed and documented

  • We do not have a proposed work around at this time. The issue is that the affected applications have bad data in them, the best we can suggest is to maintain a record of the affected apps downloaded, and we can provide instructions for how to translate the race_ethnic value to the correct format if necessary.
  • For colleges affected by this, if they maintain a record of the affected applications they could potentially wait until we run the script to fix the values in the submitted application DB, and then reset those apps for download again so they can load them into the service they have that consumes the submitted applications. Each colleges process is probably too different and customized to be able to provide a concrete work around however.

Solution: Fix to the Translation Logic and Data

We took two approaches in addressing this issue:
  1. The first is to put the translation logic back in at submission time. If an application is submitted without the MIS formatting, then it will be properly translated before it is submitted.
  2. The second approach is we have built a small script that will connect to the submitted application database, search for the affected applications, and perform the translation of any race_ethnic values that have the improper format. 

Data fixes will roll out in the March release (6.4.0)

Development of both of these solutions is complete, and they are in the process of working their way up to the production environment now in this release (6.4.0). 

Changes to the CCCApply Download Client

The following data fields have been added or changed in the CCCApply applications. For updated data specification documents, please see the CCCApply Data Dictionaries and User Guides space.

Update Your Download XML Files: In order to download new or revised data fields, they must first be added or updated in the CCCApply Format Definitions XML file(s) and the download client jar file must also be updated with the latest version = transfer-client.V6.4.jar >  For more information, please see the CCCApply Download Client User Guide >  User Guides

New & Changed Data Fields

The table below provides an overview of the new or changed data fields in CCCApply Standard, and "Glue for Apply".
See these data specification changes in the CCCApply Standard Application Data Dictionary V.2019.1 in the Data Dictionaries space.

Description

Data Element

TypeValue / Response Options

Format / Length

Allows NullRequired

Notes

Noncredit Status<non_credit>New Field

1 = True

0 = False

Boolean, 1

Yes

NoOptional; Value set to "True" if applicant applies using the new Noncredit Application URL; otherwise it is "False"
Integrity Flag 81<integrity_fg_81>New Field

1 = True

Null

Boolean, 1YesNo

Flag triggered if applicant applies with the new Noncredit Application URL; otherwise it is blank.

NOTE - this is consistent with how we have all the other integrity flags structured. 

Confirmation Number<confirmation>Changed Value

IF non_credit=True then
<confirmation> has prefix = "NC-"

StringNoSystemIF an application is submitted using the Noncredit URL then the value for <confirmation> = "NC-"
Residency Status<res_status>

New Value

New NC default value = N

1 = resident
2 = possible resident
3 = non-resident
N = noncredit / exempt

bpchar, 1No
Residency status is calculated at submission for Standard Application only. 
For the new Noncredit Application path (in the Standard Application) if applicant applies using the new Noncredit URL then:
<non_credit> status is set =True   and
<res_status> status is set ="N"
Residency Area A<res_area_a>New Value

New NC default value = 9

Boolean, 1No
Residency area status defaults to "9" when (non_credit =True)
Residency Area B<res_area_b>New ValueNew NC default value = 9Boolean, 1No
Residency area status defaults to "9" when (non_credit =True)
Residency Area C<res_area_c>New Value

New NC default value = 9

Boolean, 1No
Residency area status defaults to "9" when (non_credit =True)
Residency Area D<res_area_d>New ValueNew NC default value = 9Boolean, 1No
Residency area status defaults to "9" when (non_credit =True)
Declared Residency Outside California for Taxes<ca_outside_tax>

Default values = False / Null 

Values = True / False / Null

1 = True

0 = False

Null

Boolean, 1YesNo

IF the question is displayed:

  • IF checkbox is NOT empty, value = True
  • IF checkbox IS EMPTY, then value = False

IF question is hidden:

  • Set value = Null

NOTE: IF hidden, such as in the Noncredit application, then default to NULL

For a standard application, it will default to False, unless the user checks the checkbox.

Declared Residency at a College Outside California<ca_outside_college>

Default values = False / Null 

Values = True / False / Null

1 = True

0 = False

Null

Boolean, 1YesNoSame as Above.
Registered to Vote Outside California<ca_outside_voted>

Default values = False / Null 

Values = True / False / Null

1 = True

0 = False

Null

Boolean, 1YesNoSame as Above.
Lawsuit Filed Outside California<ca_outside_lawsuit>

Default values = False / Null 

Values = True / False / Null

1 = True

0 = False

Null

Boolean, 1YesNoSame as Above.
Public School Employee

<ca_school_employee>

Default value = Null

Values = True / False / Null

1 = True

0 = False

Null

Boolean, 1YesRequired response If appears onscreen
State College Employee<ca_college_employee>

Default value = Null


Values = True / False / Null

1 = True

0 = False

Null

Boolean, 1YesRequired response If appears onscreen
Seasonal Agricultural Worker

<ca_seasonal_ag>

Default value = Null

Values = True / False / Null

1 = True

0 = False

Null

Boolean, 1YesRequired response If appears onscreen
Citizenship Status<citizenship>New Value

Default to value = X when (non_credit = True)

character(1)No

Required to have non-null value in DB.

In the new Noncredit Application workflow, the Citizenship status question is hidden; value stored = "X"
Military Status<military_status>New Value

New NC default value = X

Default to value = X when (non_credit = True)

character(1)No

Required to have non-null value in DB.

In the new Noncredit Application workflow, the Military status question is hidden; value stored = "X"

Comfortable with Englishcomfortable_englishAllow Null NC default value = nullBoolean, 1YesNoIn the new Noncredit Application workflow this question is hidden; value stored = Null
Financial Assistancefinancial_assistanceAllow NullNC default value = nullBoolean, 1YesNoIn the new Noncredit Application workflow this question is hidden; value stored = Null
TANF-SSI-GAtanf_ssi_gaAllow NullNC default value = nullBoolean, 1YesNoIn the new Noncredit Application workflow this question is hidden; value stored = Null
Athletic Interest: Intramuralathletic_intramuralAllow NullNC default value = nullBoolean, 1YesRequired response If appears onscreenIn the new Noncredit Application workflow this question is hidden; value stored = Null
Athletic Interest: Intercollegiateathletic_intercollegiateAllow NullNC default value = nullBoolean, 1YesRequired response If appears onscreenIn the new Noncredit Application workflow this question is hidden; value stored = Null
Athletic Interest: Noathletic_not_interestedAllow NullNC default value = nullBoolean, 1YesRequired response If appears onscreenIn the new Noncredit Application workflow this question is hidden; value stored = Null

Back to Top

Changes to the User Interface

Page / SectionDescriptionCurrent UI StateNew Revised UI StateNotes to Colleges
Residency page

Revise the layout of the Residency page  

Reorder the questions and sections on the Residency Page for all users

  • Switch the positions of the Special Residency Categories section and the Out-Of-State Activities section.

Currently the layout of the Residency page places the Special Residency section in the middle between the California Residence and the Out-of-State Activities sections. This layout prohibits the ability to implement skip logic to streamline the experience for CA residents.

The new order of sections/questions on the Residency page is:

  1. California Residence section (no changes to questions, fields, or logic)
  2. Out-of-State Activities section 
  3. Special Residency section - with specific questions hidden by default.  


This is a layout change and there are no changes required by the college 

  1. (with added skip logic to only Show specific Special Residency questions based on the user's Out-of-State activities and the most recent year is within 2 years of the RDD.
Residency 

Hide three questions in the Special Residency section by default for all users

  • Public School Employee 
  • State College Employee 
  • Seasonal Agricultural Worker 

Add logic to Show the three questions as a group if user selects one or more Out-of-State activities and the most recent year is within 2 years of the RDD.

Currently, all Special Residency questions display to all users in Yes/No radio button format and a response to each question is required.

The Special Residency section now only displays the Homeless Youth Status and Foster Youth Status questions to all users with all existing validation and logic in place. 

If user selects (checks) one or more of the "Out-of-State Activities" with the most recent year of activity is within 2 years of the RDD, then the three hidden special residency questions will display as a group and responses will be required.


Note: The Homeless Youth and the Foster Youth questions ALWAYS display and each requires a response by all users.


College needs to be aware that this field will now allow a null

Note:  In 2018, only 1% of all applicants responded Yes to this question.

Residency

Revise the "Out of State Activities" Section by combining four separate, required questions into one optional question with skip logic to shorten the Special Residency section


Combine the four current "Out-of-State Activity" questions into ONE new question, and change the format of the response options from required, Yes/No radio buttons and set the default to "No".

Currently, the "Out-of-State Activities" section consists of four separate, required, Yes/No questions with conditional "Year" fields that appear if the user answers Yes to any of the specific questions.

The new "Out-of-State Activities" section now contains one question (onscreen text) with four optional checkbox response options (the original four OOS questions, revised).  

"As of <RDD minus 2 years>, have you engaged in any of the following activities? Check each activity that applies."

[checkbox]  I paid taxes outside of California

[checkbox]  I registered to vote outside of California

[checkbox]  I declared residency at a college or university outside of California

[checkbox]  I filed for a lawsuit or divorce outside of California

All existing data fields would persist (no change to data output, downloads, etc.)

There is no change to the text, conditions, logic or data fields for the four, corresponding Out-of-State Activity Year fields section/questions. 

The four Out-of-State Activities questions/fields are now optional (responses are no longer required by default) and the data fields will now accept Null or blank. 


Education

Hide the College Education Level and 
Colleges/Universities Attended questions on the Education page by default for all users


Add logic to the College Enrollment Status question to only show college sections if the user is NOT a first-time in college after leaving high school


Currently, the College Education Level section and the Colleges/Universities Attended sections are required questions/sections that appear to all users on the Education page, even for students who have never attended college in the past. 

The College Education Status and Colleges/Universities Attended sections/questions will not display on the Education page unless the user indicates they have attended one or more colleges in the past.  

If the user selects "first-time in college after leaving high school" option in the College Enrollment Status question, do not show college questions and default field value to Null. 


Noncredit ApplicationAdd a Prefix to the Confirmation Number for Noncredit Applications
The Confirmation number (as well as the App_ID) will include a prefix of "NC" if the application is started and submitted using the Noncredit URL.Example:
NC-4140067
Noncredit ApplicationHide the Residency Page in the Noncredit Application path
When a student applies to your college using your Noncredit URL, the user interface and the user experience will be very similar to the Standard Application but the residency page is not included in the workflow.  No residency page questions are required at the time of submission.
Noncredit ApplicationHide the Citizenship & Military Page in the Noncredit Application path
The Citizenship & Military page of questions do not appear in the Noncredit Application workflow
Noncredit Application

Hide questions from the Needs & Interests Page in the Noncredit Application path:

Main Language:
Are you comfortable reading and writing English?

Financial Assistance:
Are you interested in receiving information about money for college?

Are you receiving TANF/CalWORKs, SSI, or General Assistance?

Athletic Interest:
Are you interested in participating in a sport while attending college?


Several Needs & Interests page questions do not appear in the Noncredit Application workflow; however, the Programs & Services table DOES APPEAR in the Noncredit Application workflow as a series of optional checkboxes.
Noncredit ApplicationAuto-population of Noncredit Application responses in the Standard Application  
Note: Auto-population will pre-fill previously submitted responses from the last application submitted within 2 years of current date.
Noncredit AppAdd logic to allow applicants to re-apply to the same college and the same term when transitioning from Noncredit to Credit statusCurrently, the Standard Application prevents a user from submitting two applications to the same college for the same term.  This With the implementation of the Noncredit Application path, a student who submits a Noncredit Application to college (A) for term (A) is now able to re-apply with the Standard Application to college A for term A.  This logic has been modified for Noncredit > Standard Application only.  (NOTE: This means that a student who has submitted an application to a college (example: College A, Term A) using the Noncredit Application, can now re-apply (submit a Standard Application to the same college for the same term A). However, this only applies to students transitioning from Noncredit status to Credit status; otherwise they will be blocked from submitting a second Standard Application to the same college, same term.)



Changes to "Glue for Apply" and the SuperGlue College Adapter

Description

Data Field

Format / Length

Required

Notes

Noncredit Status<non_credit>Boolean (True/False)NoOptional field set to "True" if applicant applies with the new Noncredit Application URL; otherwise it is "False"
Integrity Flag 81<integrity_fg_81>Boolean (Y/N)NoFlag triggered if applicant applies with the new Noncredit Application URL; otherwise it is blank.
Race Ethnicity Full

<raceEthnicFull> 

CSV delimited

Maximum Expected Width:  805 characters (201 * 3 character long values + 200 commas + 2 surrounding quote marks for CSV delimiting in the output format)

No

NOT AVAILABLE in the Release 6.3.0. 

Back to Top


User Acceptance Testing (Pilot)

User acceptance testing for this release involves previewing the user interface changes that are being deployed as part of the CCCApply Redesign project. Colleges are encouraged to log in to their Pilot application (after the deployment on February 19) and review the changes.  

UAT Plan: CCCApply Release 6.4.0

New Non-Credit Application Pilot Project

To participate in the CCCApply Noncredit Application College Pilot Project, please contact Patty Donohue, Product Manager, pdonohue@ccctechcenter.org 

Details will be emailed to volunteers, including an informal MOU agreement, bi-weekly meeting schedule, IT implementation checklist tasks, and Admission staff testing criteria. NOTE: We will not exclude any college that wants to participate fully in this project; however we have just 12 weeks to test and discuss enhancements before the June 2019 production release. An online demonstration webinar will be announced for the week of February 25 (and the demo will be recorded). 

UAT Feedback & Resolution Process 

  • Gathering Feedback: Feedback should be categorized as bugs, issues or enhancements. Only Severity 1 issues (issues that prevent critical business functions from being accomplished) will be considered as production release blockers.
  • Reporting Feedback: User feedback should be noted in the result section. The following criteria should be followed and documented:
    • Any identified bugs with severity and priority 
    • Enhancement requests with priority identified
    • Issues that prevent critical business functions

UAT Plan: CCCApply Release 6.4.0

Preview & Send Us Feedback: During the Pilot preview, your feedback is important to our commitment to continuous improvement. If you find a bug or experience any issues, please let us know by posting in the CCCApply Support category on CCCTechnology.info.


Back to Top


Data Dictionaries & Release Documentation

The following links point to the most current versions of the CCCApply Data Dictionaries and User Guides.

DescriptionVersion / FILEFormatReleaseDate Published
CCCApply Standard Application Data DictionaryV.2019.1PDFRelease 6.4.002.19.19
Download Client Jar File V.6.4.0transfer-client.V6.4.jarjarRelease 6.4.002.19.19
CCCApply Download Client User Guide V.6.4.0ONLINERelease 6.4.002.19.19
2019-2020 CC Promise Grant Data DictionaryCCPG-V2019PDF2019-202011.20.18
CCCApply International Application Data DictionaryV.2019.1PDFRelease 6.4.002.19.19

Back to Top