Concurrent Enrollment Data & Corrections

The Minnesota Department of Education (MDE) requires the U of M to upload their concurrent enrollment data (students and courses) twice a year, so high schools can get reimbursed by MDE. MDE uses birthdate, gender, grade level, and school district to match up students to the correct high school. The following process is used to confirm our data.

• • • • The U of M Twin Cities (UMT) dual enrollment program staff works with the Academic Support Resources (ASR) business analyst to create an initial data extract that includes the student, course, and credit information taken directly from PeopleSoft. System campuses review the information, and any missing or incorrect data (birthdate, gender, grade level, and school district) must be updated in PeopleSoft by each system campus. The ASR business analyst uploads the corrected files to the MDE secured server.

NOTE: The ASR business analyst maintains requests to change the data extract script.. Changes to the data extract script require coordinating with OIT developers and takes time (sometimes months) and resources to implement. To be approved/prioritized, changes to the data extract script will likely need to benefit the entire program and not a single portion of the program.

Semester 1 - February 15

• • • • Initial review sent to the system campuses by February 1 to correct errors.

      • Semester 1 AY 23-24 timeline:

        • Jan 22 - Jan 26

          • • The Academic Support Resources (ASR) business analyst will generate initial data extract files and will create a Google sheet version of that file for the system campuses to review. Those files, along with the error reports that go with each file, will be put in the System Campus Dual Enrollment Google Drive files for each campus. 

            • The ASR business analyst to let the UMT dual enrollment program staff know when the files are ready for review. The UMT Pre-College Programs coordinator will email the system campuses using the UM Dual Enrollment Google group.

        • Jan 29 - Feb 9

          • • System campuses to confirm their data and work to correct any last-minute errors in PeopleSoft.

        • Feb 15

          • • The ASR business analyst to upload each campus’ final PSEO data extract text (.txt) file to MDE’s SharePoint site 

            • The ASR business analyst will create Google sheet copies of each of the system campus files that were uploaded to MDE. Those will be stored in each of the campuses' Google drive folders for that term.

Semester 2 - May 30 

• • • • Initial review sent to the system campuses by mid-May to correct errors.

      • Semester 2 AY 23-24 timeline

        • May 5 - 9

          • • The Academic Support Resources (ASR) business analyst will generate initial data extract files and will create a Google sheet version of that file for the system campuses to review. Those files, along with the error reports that go with each file, will be put in the System Campus Dual Enrollment Google Drive files for each campus.

            • The ASR business analyst to let the UMT dual enrollment program staff know when the files are ready for review. The UMT Pre-College Programs coordinator will email the system campuses using the UM Dual Enrollment Google group.

        • May 12  - 16

          • • System campuses to confirm their data and work to correct any last-minute errors in PeopleSoft.

        • May 30

          • • The ASR business analyst to upload each campus’ final PSEO data extract text (.txt) file to MDE’s SharePoint site

            • The ASR business analyst will create Google sheet copies of each of the system campus files that were uploaded to MDE. Those will be stored in each of the campuses' Google Drive folders for that term.

        • Mid-June for the UMT campus

          • • Run a CIS late enrollment query in mid-June to catch any late CIS registrations for both fall and spring. 

After the U of M uploads their concurrent enrollment data to MDE's secured servers, it's matched against MDE's student data (birthdate, gender, grade level, and district). Any mismatch produces an error that must be corrected. Concurrent enrollment errors have the following implication:

• • Errors mean the high school may not be reimbursed by MDE for the concurrent enrollment registration. 

As of fall 2018, MDE will no longer accept data extract files with more than 5 errors. If more than 5 errors appear, MDE will contact the campus representatives to correct errors. Please follow the procedures outlined in this section. 

• Once corrections have been completed in PeopleSoft by the campus representative, the ASR business analyst can generate a new text (.txt) file containing the error corrections that have been made in PeopleSoft, and upload the file to MDE’s secured servers. 

CONTACTS & PROCESS

CONTACTS

• • • MDE: Jeanne Krile

    • UMT: cisenroll@umn.edu (MDE will reach out to this email with questions on errors and corrections)

    • UMD: MDE will contact UMD if there are any errors.

    • UMC: MDE will contact UMC if there are any errors.

SYSTEM CAMPUSES SHOULD MAKE THEIR CORRECTIONS IN PEOPLESOFT

High School Grade Level

• • Grade level is determined for each student based on a student group. At the current time, only seniors and juniors are being reported to the state. 

    • The HS## group is used, where the ## is equal to the calendar year the student is graduating in (e.g., HS18 would mean that student is graduating in 2018)  

    • The advantage of using a student group is to allow the data to be entered once for the student and used to calculate the two (or three) years the student is in the program  

    • Note that the student group must be effective dated as less than or equal to the start date of the term being reported and be active  

    • Missing grade level groups are part of the PDF error report generated with the extract and can mean:

      • There is no HS## student group matching the institution of the student

      • There is a HS## code, but it is effective dated past the first day of the term

      • HS## code is not for this year or next year (too old or too far into the future) 

CIS Course Attribute

• • The CIS course attribute is what the report uses to determine at which school the student took one or more Concurrent Enrollment courses.

  • Each high school that participates in the U of M Concurrent Enrollment program will need two records in PeopleSoft:

  • An external org record on the Organization Table

    • • Campus Community > Organization > Create/Maintain Organizations > Organization Table

      • These records need to be SCHL organization types to be recognized in the report that gets sent to MDE.

• • • • If only an SFTP organization type exists for a high school, then use the Org ID Request Form maintained by the Admissions tech team to add a new external org ID. See the SCHL EXAMPLE below. 

  • The proprietorship value on the SCHL type record also needs to be set to the appropriate value (e.g., ‘Public’ or ‘Religious’) as this field tells the report if the school is public or non-public

  • If the proprietorship value needs to be set, use the Org ID Request Form to adjust the existing external org ID

  • Note: The Concurrent Enrollment report only includes students who take courses through public high schools. All students taking courses at non-public high schools are not included in the report data but are noted on the PDF error report under the Excluded Non-Public School Codes section. See ORG DETAILS EXAMPLE below.

• A course attribute value on the CIS course attribute which consists of a four-letter code and description and long description values that exactly match the external org ID for that school  

• • • The description and long description fields for a course attribute value must exactly match the external org ID’s Long Description field as the report will search for the values on the Organization Table that exactly match that course attribute value. 

    • Even one character difference (e.g., ‘-’ instead of ‘/’) will confuse the report and will lead it to mark any students taking Concurrent Enrollment courses at that school as students attending a non-public school. See COURSE ATTRIBUTES EXAMPLE Below.  

Gender Code

• • Students without gender data will be flagged on the CIS error report.

ERROR CORRECTION PROCESS: AFTER SUBMITTING DATA TO MDE 

Errors are reported after the U of M system campus data has been uploaded to MDE, and that data has been checked against the student data at the school district level. It’s also possible that records will be flagged if the school district has a student listed for concurrent enrollment and the U of M campus didn't upload the student’s information on a certain data extract. Often, the high school will reach out to the U of M concurrent enrollment program, indicating there's an error. The most common errors are with the student's name or school district information.

• • • If MDE or a high school reaches out to the U of M concurrent enrollment program indicating there's an error, first determine in which semester the course was taken. Then check the data extract sent to MDE for that term which is located in the System Campus Dual Enrollment Files Google Drive. 

    • If the data was sent, but was incorrect (e.g., name is wrong, district information wasn't correct), the U of M campus will work with Jeanne Krile from MDE to correct the data.

      • • Email Jeanne Krile indicating the student did take concurrent enrollment for the given term, the data was uploaded to MDE, but the information was incorrect. Jeanne will then work with the high school to manually correct the data.

        • The U of M campus should correct the data in PeopleSoft. NOTE: if the error is a name change, and the student applied for freshman admission, connect with the student to confirm their preference.

    • If the data was not sent to MDE in the data extract, the U of M campus will need to resend the information to Jeanne Krile using an Excel template titled Concurrent Enrollment Manual Corrections located in the System Campus Dual Enrollment Files Google drive. 

      • • Working with the Academic Support Resources (ASR) business analyst, the system campus will need to determine why the data wasn't uploaded with the data extract.

        • Once the issue has been found and corrected, the ASR business analyst can rerun the data extract and pull the needed information to be uploaded into the Excel template. 

        • A copy of the Excel document should be saved in the system campus Google Drive folder for that term.

        • The system campus should email the Excel document to Jeanne Krile, the MDE contact.

        • Each school and university is assigned a code to identify it for reporting purposes. These are the ones for the U of MN System. On the Excel template, the first four numbers are the "Orgunit Number" and the two digits are the "Orgunit Type."

          • • UM TC: 0007-23 (called extension)

            • UM Crookston: 0003-23

            • UM Duluth: 0004-23

            • UM Morris: 0005-23

            • UM Rochester: 0009-23

CORRECTING SCHOOL DISTRICT CODES