Single Parent code vs Grade Level COde

Jessica Smith 4

This question is for RE Users who work with schools.

Currently we use different Constituent Codes to identify parents of students in specific grades. (Freshman Parent, Sophomore Parent etc etc). This means one constituent can potentially have 4 Constituent codes just to identify their parent status. When new parents are added from Education Edge, the automatically get assigned the Parent constituent code and I have to go in and manually change it to their student(s) grade(s). 

We use the codes for the typical reports and stuff (how many Senior Parents gave this year etc.) If we report on all parents I just pull in all 4 codes.

I am wondering if we should just use the Parent constituent code and not have to worry about changing all the codes year after year. I am thinking, in theory, RE has Parent reports that group by child grad year, queries and exports can be run using the Relationship>Individual criteria, and it may be easier on reporting one the entire Parent population with just the one code.

What does your organiztion do: one Parent code or each grade level? What problems have or may arise from using just the one code over the 4 different ones? 


Thoughts, suggestions? Thanks in advance for your input.

 

Alicia Barevich

Wow, that sounds complicated to maintain! We just have a Parent const code, and if we need to restrict it by grade or any other affilitaion pertaining to the student, we pull that through the student's Primary Education information (including attributes).

Daniel Bayer

Yikes, that is a LOT to maintain. I've used constituent attributes for grade levels before, along with a general "Current Parent" constituent code, but even that you have to change every year, and it's silly since you can query/export/report on the individual relationship's class year. I think it makes more sense to do your reporting that way, and have just one Current Parent constituent code. It's easier to maintain and not too difficult to set up in queries and exports.

Christine Cooke 2

Jessica Smith:

This question is for RE Users who work with schools.

Currently we use different Constituent Codes to identify parents of students in specific grades. (Freshman Parent, Sophomore Parent etc etc). This means one constituent can potentially have 4 Constituent codes just to identify their parent status. When new parents are added from Education Edge, the automatically get assigned the Parent constituent code and I have to go in and manually change it to their student(s) grade(s). 

We use the codes for the typical reports and stuff (how many Senior Parents gave this year etc.) If we report on all parents I just pull in all 4 codes.

I am wondering if we should just use the Parent constituent code and not have to worry about changing all the codes year after year. I am thinking, in theory, RE has Parent reports that group by child grad year, queries and exports can be run using the Relationship>Individual criteria, and it may be easier on reporting one the entire Parent population with just the one code.

What does your organiztion do: one Parent code or each grade level? What problems have or may arise from using just the one code over the 4 different ones? 


Thoughts, suggestions? Thanks in advance for your input.

 

Having worked in four schools... I have always used a Parent-Current constituent code and Parent-of Alum constituent code (two schools insisted on a Withdrawn code because of some of the history in a very old school).  Nonetheless, you are correct, you can pull most reports based on the child's grad year.  In some reporting, depending on the type of data you are looking for, it does help to have the grad years on the parent record, and I found that challenge was easily remedied be adding a constituent attribute for every child with their grad year.  So the Attribute Category is Parent Class of:, the Description is 2002 or whatever the year.  It is easy eough to globally add or import with the incoming class of parents.


By doing that it gives you some other reporting options both in canned reports and things you may export.  It is also a little more direct, which is helpful at times, than digging down into the relationships to the field with the class year of the student.  It is also helpful so that you do not miss some of the exceptions, like the grandparents or aunt/uncle or some other adult that is the guardian and should be counted, pulled for mailings etc. but may get missed if someone forgets to include that relationship type when pulling class year.

Kate Sklodowska

We are a small k-12 school (~650 students).  Current parents are coded as such: Parent, then Parent '21, Parent [grad year of child 2], etc. When the student leaves the codes are changed to Former Parent, Former Parent [grad year of child 1], etc.  This makes it easy to see the parent grades, but we only have to change the code when a child leaves instead of every year as in your case.  We also assign 2 attributes for each parent.  "new parent year" to show when they first came into our community and "parent year" to easily add their parent years on name tags and other listings.  So a parent with 3 kids would have a parent year attribute of P '21, '24, '29