SINF Mid-Year Guardian Changes for 20-21 (Updated 2/18/21)

In order to provide more flexibility to our customers, we are programming to make further changes to this process (Out of Band Update released 2/19.21)

Issues Resolved

  • CALPADS Extracts
    • A new setting was added under Other Options to force Parent/Guardian information (SINF/SIAD) to be extracted exclusively from STU.PG and STU.PED. The option is deselected by default. See CALPADS Extracts - Other Options Tab
    • The Parent/Guardian Highest Education Level will always be pulled from STU.PED, even when processing Guardian information from the CON table. This will remain in place until CALPADS changes the SINF file layout in preparation for 22-23.
    • The Staff Demographics (SDEM)/Staff Assignments (SASS) extracts were adjusted to evaluate the staff hire date against Information Day, instead of October 31st as was required before. Also will evaluate the Assignment Start Date against Information Day.

We have also updated our documentation here: Managing Contacts - Identify Guardians for CALPADS SINF Extract

The changes to the SINF process were included in the Update that was released 02/12/21. 

Here are several links that should be helpful: 

(Added 2/12/21)

Earlier this year, CALPADS informed vendors that there would be a mid-year change to the SINF file. They would begin validations that the Guardian First Name and Last Name fields both be populated, and would eventually capture an Education Level for each Guardian (21-22 SY). They asked vendors to start preparing their local systems to handle these changes. 

CALPADS is making this change to allow more accurate matching with a variety of state and federal databases, including SNAP, Foster system, etc. It was discovered, during measures taken due to COVID, that students were not being matched efficiently by the Guardian Names resulting in fewer matches than expected. Having both Guardian First and Last names submitted separately allows for a more accurate matching system.

  1. On December 12, CALPADS activated validations against the Guardian First and Last Name fields. This resulted in Warnings about Missing Guardian First/Last Names being generated for our customer. These WILL remain as warnings throughout the entire school year. 
  2. The warnings will not be changed to fatal errors until sometime in the 21-22 school year when the SINF file has more fields added to it for the separate Guardian Education Levels. We have not been notified of the date of the SINF file change.

For some background, here is what the current CALPADS File Specifications (CFS) file says for SINF:

  • Parent Guardian Highest Education Level field (2.38) IS required.
  • Guardian 1 & Guardian 2 First and Last Name fields (2.39 - 2.42) are NOT required

Here is what Aeries is currently extracting: See: CALPADS Cross Reference by Extract

Because of this, customers are now receiving warnings about the Guardian 1 First Name missing. It is fine to ignore these warnings, the files will post correctly with the values in the Parent/Guardian field in Demographics (STU.PG) being populated in the Guardian 1 Last Name field as before. CALPADS will not change to fatal errors until the 21-22 school year submissions.

We are making the following changes to prepare for updating the SINF process for splitting Guardian Names and collecting separate Education Levels. The following two items were included in the 01/29/21 update.

  • We have added a new field for Education Level to the Contacts - CON table (CON.ELV). This will allow sites to begin recording the information specific to each Parent/guardian record. 
  • Districts who use Online Enrollment have an existing set of values for the Contacts Code field (CON.CD) that are used to identify which types of contacts are being imported. We have changed the labeling of this field to  "Record Type". 

We are also in the process of changing the SINF extract to meet these new requirements. The following changes won't be made until after the Fall 1 amendment window has closed.  

  1. We will be adding a District Setting to indicate which of these Record Type (CON.CD) values are used by the district to identify the students' Parents/Guardians. Generally these are P1 and P2. 
  2. When this District Setting is populated, any CON records meeting the code(s) will be analyzed for that student first. They will be ranked by the Order field, and the two records with the lowest numbers will be extracted.
  3. If there are no codes identified, or no CON records with matching codes for the student, then CON records with a "Y" indicated for other pertinent fields will be analyzed. Again, the Order field will then be used to pick which two should be extracted. Fields to be analyzed, in no particular order are: 
    1. Primary Contact (CON.PC)
    2. Education Rights Holder (CON.ERH)
    3. Lives With (CON.LW)
    4. Access To Portal.  (CON.AP)
  4. For now, since there still is only one field for Parent Guardian Highest Education Level, if the CON.ELV field for the record identified as Guardian 1 is blank, then the STU.PED value will be extracted. We must do this because that field cannot be blank. However, we cannot assume which Parent/Guardian the STU.PED value belongs to. 
  5. The 1/29/21 update hid the STU.PED field on the Demographics page if it was empty. This had the unintended consequence of hiding it for brand-new records that were being entered, and may have not yet collected the separate education level for each parent. It was confusing because the couldn't find where to enter it. We will soon be un-hiding this field for now, and districts that wish to re-enable that field being required can do so. However, that will not be a long-term solution, and customers need to move forward in changing paper registration forms, etc. to allow for collecting the data for each parent/guardian in the future. (added 2.3.21)

Other related changes are being planned for development now. We have created an Aeries Idea for each of these items (linked below). Customers can add themselves to these Ideas, and they will be notified personally as action is taken on them:

We will update this article as more development is planned in this area to help our customers meet these new requirements.

NOTE: Once sites start collecting Education Level on the CON table, they should remove the checkbox from the STU.PED field on the "Define Required Fields". Once it is changed for one school, the change will be enforced at ALL the schools. However, we would not recommend (at this time) marking the CON.ELV field as Required, because it would mean that EVERY contact must have that field populated.   

3 people like this

How does enrollment save the newly added student record if they are missing Parent Ed level? They can't fill it in on Demographics and can't go to Contacts without saving the Demographics but that doesn't save because they are missing the field for Parent Ed Level.

Thank you

Erin Baker

You just need to adjust the settings on Define Required Fields to remove the checkbox from STU.PED field as "Required" 

1 person likes this

@Jan- Thank you so much!!! 


The problem that I have with removing the checkbox from the STU.PED field on the define required fields is that then it could potentially be forgotten and it is a required field.  Will there be anything else done to address this issue?

I've considered making the parent education level a required field on the contact screen but then that won't work for contacts who are not parents or guardians.  

Any advice would be greatly appreciated.  


1 person likes this
We are asking programming to make the STU.PED field visible again even if it is currently empty, as it will be in the case of brand new students. The field is still active, and they WILL be able to add data to it, and make it required still if they wish. However, that will NOT help customers be ready for next year when it will have to come from the CON table to be reported for the specific guardian record that it applies to. 

It seems like the Revision notes introduced some misconception how the data is currently being handled, so that's why I added more explanation to both the following articles: 
We are still discussing ways to better handle this data, as well as work-flows for our customers, so when we have a clearer path forward, we will let everyone know.

It would really, really, really be nice if there was a field, or box  on the contact screen right next to the new Ed Level field that we can mark with a Yes or No so that when we pull the SINF file -  AERIES will know that these records are the ones that we want to send up to CALPADS.

The hierarchy that is in the explanation of what was posted is unacceptable.  We have told the sites to fill in as much information on all records in the contact screen but some parents are only single parents and the 2nd contact they have is an Aunt, Uncle, etc.  these should not be pulled but they will be if following the rules AERIES is following.

2 people like this

Will we have an option to make it a required field just for the "Record Types" that are included in the SINF file?  

Also how do we add ourselves to the Aeries Ideas that are listed?

Shelley, if you "Vote" on any of the Aeries Ideas or Bug items, your contact info is automatically added to it, and when action is taken on an item, you will be included in a personalized email, altering you to the action that was taken. We update them when they are moved into Development, when the progress to Testing, and when they are Completed. 

We are investigating different ways to handle the issue of making sure data is populated in the Contacts table as necessary, and having a contextual 'Required Field Indicator' that is tied to certain code values is one of the ones we are considering, but programming has to weigh in on the feasibility of coding that change. We will keep you informed as decisions are made. 

1 person likes this
Login to post a comment