General Troubleshooting and Tricks of the Trade

"Dear Illuminate Help Desk: I have an issue with my SENR file. I have 50 errors. HELP!"

It's great for you to keep in touch with us and letting us know you have an issue and we definitely love you too. However, it's not going to help us any more if you don't get us specifics. Attaching an error log (believe us, we know CALPADS has error logs), send screenshots, giving us the exact error (GERR001, SENR0027...), etc. TMI is never a problem with us and will bring about a quicker solution.

"I'm seeing a pattern in the errors. They all seem to be specific to students at one particular site."

In this scenario, think big picture and whether something has changed recently. Was there a request to adjust term dates that were incorrect? Was there a request to mass update student enrollment, programs, etc? Were calendars adjusted? Many times, it's possible that some recent mass update may be the source of this problem. If you should find a repeated occurrence of the same problem from one student to the next within the error logs, it's very possible that Illuminate can help. A few minutes of Illuminate's time can possibly keep your sanity. If there was such a request, having this tidbit in the help ticket is good background info for us to help troubleshoot.

"So you're saying that I need to fix all these students in CALPADS one by one. I'll be working til I'm 120."

Please don't jump to any conclusion yet that Illuminate is broken and start manually correcting students within CALPADS. It's very possible that a manual edit in CALPADS can make matters worse (if not adjusted correctly) and cause more misalignment of Illuminate to CALPADS. Illuminate's not perfect and we make mistakes too. it's also very possible that if you start making changes in Illuminate, that once we fix the real issue, your exports are still going to be incorrect.

"How often should I generate/submit files?"

You'd want to try at best, to do weekly and/or bi-weekly updates/submissions. From the various range of client experiences we've seen out there (weekly, biweekly, monthly, one time and on the day before submission window closes, etc), more is merrier. Those who do frequent uploads are able to detect issues (Illuminate or user error) and alert the appropriate party before more harm is done. If you are those who likes to one time and on the day before submission window closes, it may be very hard to fix and reconcile the ~2K errors. Help may not come soon enough if you are in this scenario.

Current CALPADS documentation

The following docs already exist and are the same docs from other pages. However, we're including here for easy access. Some of these docs may possibly have updated versions and can be found here.

2016-2017 CALPADS Complete (Excel Sheet): This doc will help to figure out the Illuminate to CALPADS spec alignment. It will assist to find what data field from CALPADS and where that data element resides in Illuminate. There are no version #'s for this doc. Any updates/corrections to this doc, Illuminate will replace the same file with the new updated version.

CALPADS Code Set: This is the official doc from CALPADS that details all current code sets they are expecting.

CALPADS Error List: This is the official doc from CALPADS that details all possible errors you may receive per your submissions. It's a helpful doc that also explains the scenario on how and where to look to fix the issue.

2015-2016 CALPADS Complete (Excel Sheet): This doc will help to figure out the Illuminate to CALPADS spec alignment. It will assist to find what data field from CALPADS and where that data element resides in Illuminate.

2014-2015 CALPADS Complete (Excel Sheet): This doc will help to figure out the Illuminate to CALPADS spec alignment. It will assist to find what data field from CALPADS and where that data element resides in Illuminate. There are no version #'s for this doc. Any updates/corrections to this doc, Illuminate will replace the same file with the new updated version.

CALPADS Validation Logs

CALPADS has validations and requirements that are ever changing. With that said, it's a lot of validations and checks that we have to update into the system to keep up. Because of this madness, there will be some logic that we may miss.

Keep in mind, there is a difference between a field that is required for all students VS. a field that is conditionally required.

Required for all students: Our filters are definitely setup to trigger these things, should the student not have this data. For example, Birth Date is required for all students.

Conditional requirements: We may not have validation for every bit of conditional requirement validation from CALPADS. For example, field5 is required if field1 = "A" and field2 = "B". If we should have any missing, please let us know.

When you generate a state report (ie. SENR, SINF, etc), there possibly can be a validation Log for that specific date/time export, that displays whatever errors are present as of that generation at X date and time. After those errors are corrected, the Validation Log that was generated at X date and time, will remain showing those errors. It is not until you go back and generate a new report, that we will query any new errors that still remain.

a. IF there is no new log for X date and time, this means that all the data as of that report, has passed our validation. This is a good sign because obviously there's nothing more that is required and the file should pass all/most of CALPADS' required fields.

b. IF there is another log for X date and time, then this means that there is at least one or more error(s) still. Correct those and repeat the steps of running the report again.

Code Management (State ID Mappings)

This is something very important to note, especially with adding/modifying code table data (ie. language codes, english prof codes, etc). This area is most responsible for all your missing-related code errors from CALPADS and on fixing, will resolve most of these errors. We use the State ID Mapping piece at the bottom of the code edit page. This is our way of extracting the correct code value per academic year.

For example, if CALPADS expects that in 2015, the code value for Hotels/Motels is "110". You'd add a record for 2015 > 110. Let's take this into the future and in 2016, CALPADS expects Hotels/Motels codes to export as "600". You can add a state mapping record for 2016 > 600. Having these records in place, if you export a 14-15 CALPADS file, it will pull the 110 code. If you pull a 15-16 file, it will pull the 600 code.

SENR Requirements

Due to CALPADS requirement now to exit all students at EOY, the export will only include the current year's enrollment data. There is no more exporting continuous enrollment dates.

Student must have an enrollment that overlaps the report Start Date and End Date. Using the example of 10/03/2014 to 11/03/2014, a student whose enrollment starts on 11/15/2014 will not be included. A student who started on 8/25/2013 and never left, will be included because he/she is enrolled at some point within that date range.

E150 and grade level changes

CALPADS has adopted a new exit code E150 that is to be used in the event that a student enrollment has a grade level change. So for example, a student who started the 14-15 year enrolled in 5th grade, after three weeks was assessed and determined to go back down to 4th grade, and the "Change Grade/Program" tool used to make that grade level change.

As you know, the "Change Grade/Program is one tool, but does two different functions (change Grade and/or change program). Regardless of which option the user chooses, we always exit that enrollment record with an IRIS-1 exit code.

Change Grade Level: In the described example above, let's say that the user has change grade level from 5th back to 4th. The tool will exit the 5th grade enrollment on X date with an IRIS-1 and start a new row/record for 4th grade effective the next available in-session date.

Problem: Yes, if you leave the IRIS-1 exit code, the tool will not export the expected E150 code. CALPADS expects an E150 here.

Solution: Edit the enrollment record to adjust the IRIS-1 to the E150. The export script isn't set up to automatically pull the E150 in the event that a grade level change has occurred with an IRIS-1 exit code. We may have an automated solution at a later time.

Change enrollment attendance program: This is the other path that the tool can take the user. In this scenario, CALPADS does not care to report on program changes.

Problem:No.

Solution: Do nothing and leave the IRIS-1 exit code. Please DO NOT replace the IRIS-1 with some other exit code or blank the exit code, because it will break our backend logic. The IRIS-1 exit is a special code we've designed that needs to be in place so that we know that although the enrollment is broken, it still is continuous.

District of Geographic Residence

CALPADS previously did not collect this data therefore many charter schools previously set up a "district" called Charter however this year actual districts should be populated. These codes can be managed in Code Management table called "Transfer Districts." Once this is complete the student transfer record can be edited in Illuminate through Students > Transfer Details.

There generally are two types of transfers: Intradistrict vs. Interdistrict.

a. Interdistrict transfer (From outside your district/school, the student in District A is granted a transfer to enroll at one of your school): When adding a transfer record for the student, you're required to add a "From" district. At the very top of that drop-down list, you will find all those Transfer Districts to choose from (these are Transfer Districts from Code Management). So for example, Jane Doe lives Alameda Unified, but is granted a transfer to go to your school John Adams Elementary. This is a scenario where you will add Alameda Unified as the "From". The "To' field will also yield the same list of transfer districts and your internal school list. You can choose John Adams Elementary.

b. Intradistrict transfer (Within your district, student lives in a location where School A is the expected home school, but the student is granted permission/transfer to go to School B for whatever reason): When adding a transfer record for the student, you're required to add a "From" district. At the very bottom of that drop-down list, you will find your internal school(s) to choose from. So for example, John Doe lives in the Lincoln Elementary boundaries, but is granted a transfer to go to Washington Elementary. This is a scenario where you will add Lincoln Elementary as the "From". You can choose Washington Elementary within the "To" field.

How this all translates to CALPADS and SENR District of Residence (1.32):

a. Interdistrict transfer: Because Transfer Districts are from code management, please review your Transfer District code set. Please ensure that the Transfer District code has a the 7 digit County-District code for in the State ID Mapping area, for the academic year of concern.

b. Intradistrict transfer: In the event that the From school is your internal school, the 7 digit County-District code from the "From" school will export. Please ensure that your From school has a complete 14 digit CDS code for the "State Site ID" field.

1.30 Met UC/CSU logic

Illuminate does have a field on the demographic details page (Met A-G Requirement: Y/N). However, this field does NOT export into SENR 1.30. It is possible that one day we may change to point field 1.30 to this field. Until then, we do not use this field.

To successfully flag SENR field 1.30 (identifying if a student has met A-G) per student, the export is dependent on three things:

On the demographic details page, all students must have the Graduation Requirement Year populated.

"Met A-G Requirements" Y/N override is applied on Demographic Details page. If no override has been applied, then #3.

A Course Requirement must be created for the academic year in which that student is graduating. In addition, the course requirement name must start with "CSU/UC Requirements". We're very specific on the name and so anything else (ie. UC/CSU....) will not work. Within this requirement from step 1, you can create categories. You should create a category for each letter (A-G). If you're not sure about what each letter/subject means, please review the following link to the University of California A-G Requirements page (http://www.ucop.edu/agguide/a-g-requirements/). Once your categories are created, within each category, you affiliate those CSU/UC courses from your course catalog that apply to that category. For example, within your "A" category (History/Social Science), you'd want to affiliate all UC/CSU approved History/SS courses from your catalog.

The student based on their Graduation Requirement Year, will be applied to the matching CSU/UC requirement. If the student has met all categories (A-G), then the export will produce the Y for field 1.30. Otherwise, the student defaults to N for field 1.30.

In order to ensure that all students who meet CSU/UC Requirements for the academic year you are doing EOY CALPADS reporting for, we highly recommend running a Mass Grad Check Generation for all your graduating seniors for that requirement set. This is necessary to ensure all grades received by students in courses tied to that requirement get refreshed. A refresh of those grades, as they related to the course requirement set, is not automatic.

SPRG Requirements

Student must have an enrollment that overlaps the report Start Date and End Date.

The program Start/End dates must overlap the report Start Date and End Date.

One very important note about SPRG exports:

Enrollment School Changes: All program data in CALPADS is broken out by School > Program > Start Date > End Date. The biggest factor/challenge here is the School piece. Take for example, a student who was at School 1 in a SPED program for 2 years from 8/1/2011-6/15/2013, then went to School 2 from 8/15/2013 to current day, keeping the sped program status. So Illuminate has designed the exports at best, to export the programs to be consistent with the student's enrollment dates. So what you get now is an overlap of Program Start/End dates versus Enrollment Entry/Exit dates.

SED or Socio Economically Disadvantage Students

Currently, only 2 attributes are being tied to a student to assign a SED status in Illuminate. California disaggreates the data with addtional attributes that then affiliate the SED status to the student, thus giving a different number than what you see in Illuminate.

After Census date, you have two options:

Import into a Summary Assessment to use the information in custom reports, or

Download 8.1

Update and match the information to the programs.txt as necessary

Submit to help to merge and update the existing program to match the most up to date information

Year-Specific Programs

Academic year specific programs: Some programs are specific to only that academic year of reporting. For example, Lunch program (free or reduced) data is one of those that CALPADS expects to start & end within each year and they don't want the data to overlap many years. Makes sense because F/R lunch generally requires re-evaluation, etc. So for this reason, the F/R lunch program export script to pull a lunch record only based on the current year's enrollment dates.

The following programs are academic-year specific programs: Free Lunch Program (181), Reduced Lunch Program (182), Transitional Kindergarten Program (185)

For example, the screenshot above shows student 61042 with a Free Lunch program starting on 10/03/2011.

When generating an SPRG for the 14-15 year, the export produces the Free Lunch program (181) with the Start Date (7/01/2014) to End Date (6/30/2015).

When you cross reference enrollment, the export is exporting the 2014-2015 enrollment Entry Date for the program Start Date and assumed Term End Date for the program End Date.

Continuous Programs

Continuous Programs: Contrary to academic-year specific programs, you have for example the 504 program (101) that is continuous and doesn't necessarily need to be closed out every year. CALPADS expects that as soon as a student leaves a school and starts a new school, then the program should also reflect that change. So when you generate an SPRG today, we make an attempt to pull Start/End dates as far back as possible, comparing the program dates with enrollment.

The following programs are continuous: Special Ed Program (144), Migrant Ed Program (135), Title I Part A Basic (122), GATE (127), 504 Program (101), Homeless Program (191).

If you reference the student 62064 who has a current GATE program effective 8/11/2010.

When generating the SPRG for 14-15, the GATE program record exports a Start Date of 8/8/2012.

Comparing this Start Date with the student's enrollment and based on the student's current school, the student was continuously enrolled in that school back to 8/8/2012. Although the student started GATE while enrolled in Elementary, the export will not pull the exact Start Date from the program record. This rule is to adhere to CALPADS current way of storing program data (School > Program > Start Date > End Date).

Additional

Because enrollment is closely tied to programs, exit codes make a big impact on whether a program is continuous or true break. If a valid CALPADS exit code (other than IRIS-1, E155) is used to end/close an enrollment record, the exit code breaks the enrollment and the program Start Date may be different. Only those two exit codes (IRIS-1, E155) are the ones to determine that an enrollment/program is continuous and possibly goes back further.

SPRG0070: Open Education Program record exists with Different Membership Start Date

You uploaded your SPRG data to CALPADS and WHAM! You received hundreds of errors back from CALPADS complaining about an "Open Education Program record exists with Different Membership Start Date". In looking closer, Illuminate is producing a program start date for the student(s) that is doesn't match the current open program record in CALPADS.

If you've got a small number of errors, you can make manual edit of the students' current program in CALPADS. However, please be extremely careful that you edit the program to End Date accordingly.

There's no way that you will be able to manually correct all those mismatching discrepancies? Who you gonna call? Does Illuminate have any reconciliation tool to help out? Yes, indeed Illuminate does. Please follow this link here to review and understand our SPRG Reconciliation Tool.

Change of Primary Disability

Special Ed historical data is not stored in Illuminate. If a student disability changes, you would go to the Student Special Ed page and change the start date to reflect the start date of the new disability. We encourage our clients who are not using our SPED product to store historical special ed data in the system they are using, such as SEIS for example.

If you need to track disability changes for special ed students in Illuminate, you can use Student Programs to track that information. Student Programs would reflect historical start/end dates for all disability changes for a student. Please NOTE that student programs does not report special ed data to CALPADS. Only the data on the special ed student page is reported to CALPADS.

Because SPED 144 program is auto-derived based on the primary disability that is in Spec Ed tab, we don’t have historical tracking if a student should end an IEP and start a new. Best practice is recommended to be the following:

To put the original Disability and start date & End Date in the Spec Ed tab for that student.

Export an SPRG, which should contain that data.

The SPRG export should now contain that SPED program record that is reflected in Spec Ed tab. This data should upload into CALPADS and close off the existing program record in CALPADS.

In Illuminate, come back and enter the new IEP/Disability in the Spec Ed tab.

SELA Requirements

Student must have an enrollment that overlaps the report Start Date and End Date.

If student's English Proficiency currently is EL, TBD, RFEP, the LEP Date is required.

Depending on what the student's current English Proficiency is and whether the corresponding Date is between the report Start Date and End Date. Rules are defined below.

English Only (EO) student export logic

In the event that a student's English Prof. = EO, then we will export the following dates (whichever comes first, and we will use that date to compare).

State School Entry Date (Language details page)

US Entry Date (Language details page)

US School Entry Date (Language details page)

District Enter Date (demographic details page)

School Enter Date (demographic details page)

So for example, if you generate a SELA report using the dates of 8/15/2014 - 11/17/2014.

1. Does the student have a State School Entry Date? If blank, the tool moves to the next field. Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and State School Entry Date as the SELA Effective Start Date. If the date does not fall between, the student is excluded from this export.

2. Does the student have a US Entry Date? If blank, the tool moves to the next field. Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and US Entry Date as the SELA Effective Start Date. If the date does not fall between, the student is excluded from this export.

3. Does the student have a US School Entry Date? If blank, the tool moves to the next field. Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and US School Entry Date as the SELA Effective Start Date. If the date does not fall between, the student is excluded from this export.

4. Does the student have a District Enter Date? If blank, the tool moves to the next field. Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and District Enter Date as the SELA Effective Start Date. If the date does not fall between, the student is excluded from this export.

5. Does the student have a School Enter Date? If blank, the tool moves to the next field. Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and School Enter Date as the SELA Effective Start Date. If the date does not fall between, the student is excluded from this export.

Concern 1: This will mean that the exports will not include an EO student who has a State School Entry Date of, for example 8/1/2005. This student is new to my district this year and I need to submit the student's EO status.

Basically, if the student truly has a State School Entry Date of 8/1/2005, that first CA district who enrolled that student in 2005, should have added the status for the student. If not and the student somehow never had a status reported, then please ensure that the student has a State School Entry Date populated in Illuminate, that falls within your report date range.

Concern 2: I see within CALPADS, that the student currently has an EO status effective X date that is owned by District 1. But doesn't CALPADS require/need that I add an EO record for my district/LEA, with a new effective date?

CALPADS currently only allows for one EO status, regardless of which LEA owns that EO record in CALPADS. CALPADS will NOT allow you to add a new EO record that is owned by you, if that status already is present. Oddly, CALPADS is a bit buggy too in that you may actually find some student scenarios where there are overlapping same status, from different districts/owners.

Concern 3: So it seems that this logic should only pull new EO students, such as TKs and Kinders?

That's correct. If you think about it for example, a new Kinder student should have a State School Entry Date that is pretty recent. If the student started Kinder with you on 8/25/2014, then most definitely the State School Entry Date should be equal to that (or somewhere within range). Having a State School Entry Date of 8/25/2014 and assuming you generate your report from 8/25/2014 - 11/1/2014, the export will find this student and export.

Concern 4: It seems that the State School Entry Date is the best match. Why do I need to bother with all those other fields (US Entry Date, US School Enter Date, etc)?

If you do have the State School Entry Date populated for all your students, you're definitely correct that you don't have to deal with our logic of looking at those other fields. Those fields were added into the formula as backups, in case you don't have a State School Entry Date populated. We have plans to take away those other fields and making State School Entry Date the only field to compare against the report dates.

Recommendation:

For students new to the district but not new to CA, there should only be one initial Home Language Survey. If a new Home Language Survey is collected by the new district and the student is incoming from another CA school district, then the EL status should be verified with the previous district or by looking up the EL status in CALPADS to ensure the data is consistent from district to district.

EL, TBD, IFEP, RFEP student export logic

CALPADS expects that Illuminate export only students who have changes in English Proficiency status going forward. Illuminate will search for all students who matches the following logic, using the sample dates of 8/15/2014 - 11/17/2014:

When the student's English Proficiency = (EL or TBD) and the LEP Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the EL/TBD status, and LEP Date as the SELA Effective Start Date.

When the student's English Proficiency = IFEP and the FEP Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the IFEP status, and FEP Date as the SELA Effective Start Date.

When the student's English Proficiency = RFEP and LEP Date is not blank and the Reclassification Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the RFEP status, and Reclassification Date as the SELA Effective Start Date.

SDEM Requirements

User must have one ore more site/role affiliation(s) to the reporting Academic Year.

User is setup as Exclude From State Reporting = No or blank. This field is found in the user details edit page.

User has a State ID (SEID) that is not blank.

Staff Employment Status (7.27), Service Years LEA (7.30), & Service Years Total (7.31) rule

Behind the scenes, the 3 fields above are tracked per academic year. If you toggle your Control Panel to the 2014-2015 year, then these 3 fields will yield the data per that year. While in that academic year, these 3 data elements should reflect what the user is/should be for that year of reporting. If this data is missing for YYYY academic year, then that year's SDEM export will be missing these 3 data elements. So please ensure that your control panel is set to the correct academic year (doesn't matter what school/district) prior to adjusting this data.

Previous clients: If you used Illuminate the previous year and assuming you did submit this data then to CALPADS, logging into the new year will not copy this data over for all your users (ie. same Position Status, +1 to Yrs Service, +1 to Yrs District). There is no process that will populate your new year with this new data. Our developers have created a script that will copy (same Position Status, +1 to Yrs Service, +1 to Yrs District) from the previous year to current. The script will only rollover this info if the user has the data in the previous year. This will be a one time request and if this is your scenario, please email help@illuminateed.com to make this request.

Start Date: Please ensure that you enter (at best), the date of when the user began this Job Classification and/or Assignment at the Site specified.

End Date: For this Job Class/Assignment and user, if the user is expected to end on a certain date, please input the date. Otherwise, if the user is expected to continue with this same Job Class/Assignment from one year to next, please leave the End Date blank. A blank date is interpreted as continuous and will yield the same Job Class/Assignment next year for the user. This will avoid having to rollover or re-enter the same data.

CRSE Requirements

Selection criteria to include Course/Section data into this export:

There are multiple levels in which to flag Exclude From State Reporting andcan be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area (and child-affiliated data) is flagged to Exclude From State Reporting = No or blank.

Site level exclusion: No CRSE data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).

Course level exclusion: CRSE data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections tied to this course will be excluded.

User level exclusion: CRSE data affiliated to this user will not export (ie. the 5 sections the user is scheduled to will not export).

Section level exclusion: CRSE data for that specific section will be excluded from the export.

Those Course/Section in which the section Start/End Dates overlap the report Start/End Date.

9.13 CRS-UC CSU Approved Indicator logic

To successfully flag CRSE/CRSC field 9.13 (identifying a course as CSU/UC compliant), the export is dependent on one thing. This same logic is also applied to SENR field 1.30.

A Course Requirement must be created for the academic year in which you are generating/submitting. In addition, the course requirement name must start with "CSU/UC Requirements". We're very specific on the name and so anything else (ie. UC/CSU....) will not work.Within this requirement from step 1, you can create categories. You should create a category for each letter (A-G). If you're not sure about what each letter/subject means, please review the following link to the University of California A-G Requirements page (http://www.ucop.edu/agguide/a-g-requirements/). Once your categories are created, within each category, you affiliate those CSU/UC courses from your course catalog that apply to that category. For example, within your "A" category (History/Social Science), you'd want to affiliate all UC/CSU approved History/SS courses from your catalog.

If the course is assigned to one or more categories within this requirement, this field will export a "Y". Otherwise, "N".

SCSE Requirements

Selection criteria to include Student/Course/Section data into this export:

There are multiple levels in which to flag Exclude From State Reporting andcan be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area is flagged to Exclude From State Reporting = No or blank.

Site level exclusion: No SCSE data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).

Course level exclusion: SCSE data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections (along with the schedules) tied to this course will be excluded.

User level exclusion: SCSE data affiliated to this user will not export (ie. the 5 sections the user is tied to, along with the students scheduled will not export).

Section level exclusion: SCSE data for that specific section will be excluded from the export.

Those Course/Section data in which the section Start/End Dates overlap the report Start/End Date.

Those Student/Section data in which the students' Entry/Exit Dates overlap the report Start/End Date.

CRSC Requirements

Selection criteria to include Course/Section data into this export:

There are multiple levels in which to flag Exclude From State Reporting andcan be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area (and child-affiliated data) is flagged to Exclude From State Reporting = No or blank.

Site level exclusion: No CRSC data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).

Course level exclusion: CRSC data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections tied to this course will be excluded.

User level exclusion: CRSC data affiliated to this user will not export (ie. the 5 sections the user is scheduled to will not export).

Section level exclusion: CRSC data for that specific section will be excluded from the export.

Those Course/Section in which the section Start/End Dates overlap the report Start/End Date.

Secondary schools in which there are Secondary Final Grading Periods and the Grading Period Start/End Dates overlap the report Start/End Date.

SCSC Requirements

Selection criteria to include Student/Course/Section data into this export:

There are multiple levels in which to flag Exclude From State Reporting andcan be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area is flagged to Exclude From State Reporting = No or blank.

Site level exclusion: No SCSC data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).

Course level exclusion: SCSC data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections (along with the schedules) tied to this course will be excluded.

User level exclusion: SCSC data affiliated to this user will not export (ie. the 5 sections the user is tied to, along with the students scheduled will not export).

Section level exclusion: SCSC data for that specific section will be excluded from the export.

Secondary schools in which there are Secondary Final Grading Period and the Grading Period Start/End Dates overlap the report Start/End Date.

SDIS Requirements

Student enrolled at a school tagged with Exclude From State Reporting = No or blank.

Student must have an enrollment that overlaps the report Start Date and End Date.

The incident date must occur between the report Start Date and End Date.

Include only valid Consequence(s) per the participant, per the incident. Invalid Consequence(s) that have no State ID Mappings (Code Management) are automatically excluded.

Include only valid Violation(s) per the participant, per the incident. Invalid Violation(s) that have no State ID Mappings (Code Management) are automatically excluded.

Include only incidents that have been marked as completed.

Depending on the student's status/violation:

SPED students who committed any Violation offense (48900, 48915).

Non-SPED students who committed a Violation offense (48900, 48915) and received a Suspension (300) as a result.

All students who committed any Fire Arm Violation offense (100, 101, and 105).

9. The incident must be a Major incident.

Additional Notes

If you generate an SDIS report and you get no results, more than likely the problem/solution may be the following. Pay special attention to rules #5 and #6 above. If there should be any Violation or Consequence codes that do not have State ID Mappings for the given academic year, will filter out those behavior/participant records that tie to that Violation or Consequence.

For example, within an incident a student received X consequence (ie. After School). The consequence value does not have a State ID Mapping for the year. Per our report filters, this consequence for this student will not export on the SDIS.

While you are not required to report summer school enrollments, you are required to report out summer school behavior incidents as you would in the normal school year. On the May 14 EOY CALPADS call they recommended that you manually add a secondary enrollment for the student(s) involved for the day of the incident and use a T160 exit code. All behavior incidents that happen between July 1, 2014 and June 30, 2015 will need to be reported in the 2015 school year. All behavior incidents that happens between July 1, 2015 and June 30, 2016 will be reported in the 2016 school year.

The logic for field 4.21 is as follows: If, on Disciplinary Incident Occurrence Date, Education Program Code = 144 (Special Education) and Incident Disciplinary Action Taken Code is not equal to 300 (No Suspension or Expulsion) Then Y; Else N. This logic is being applied in the script and should return a Y or N where appropriate.

Illuminate allows for multiple Consequences to be entered. However, CALPADS requires that only the most recent (latest) reportable Consequence to be submitted. For this reason, Illuminate will be pulling only the latest reportable Consequence record. If there are multiple consequences and they ALL have the same 'Date Assigned', the system will pick one at random to include in the extract. The consequence with the later date assigned will populate in the extract.

SCTE Requirements

Student enrolled at a school tagged with Exclude From State Reporting = No or blank.

Student must have a CTE Pathway record for the academic year that matches the report Academic Year.

Designating CTE Pathways

CALPADS requires that all 11th or 12th grade students enrolled in CTE courses be designated as CTE participants, concentrators, or completors for a given pathway.

Participants are 11th or 12th grade students enrolled in any CTE designated course.

Concentrators are 11th or 12th grade students who have completed at least 50% of the required courses for a particular CTE pathway, and are enrolled in the next course.

Completers are 11th or 12th grade students who have completed all of the required courses for a particular CTE pathway.

These can be designated in Illuminate as follows:

Navigate to Students > General > CTE Pathways.

Search for and select the student for which you would like to add a pathway.

Select "Add CTE Pathway"

This will return a "Student CTE Pathways" form with two fields. Please fill these out as follows:

To designate the student as a Participant, you do not need to do anything. This information is pulled from the course information.

To designate the student as a Concentrator, select the pathway from the pathway dropdown, and click the save button. The Academic Year field should be left blank.

To designate the student as a Completer, select the pathway from the pathway dropdown, and select the academic year from the Academic Year dropdown. This should be the academic year during which the pathway was completed. Once both fields are populated, click the save button.

Additional Notes:

A student can be participating in multiple CTE pathways at one time, and be in different stages in each one.