Adding Student Records in RE

Options
Hello All,


We are about to begin adding students into our database. I wanted to reach out to the community to ask, what are your current processes for importing/managing these records? We are an academic medical center so we aren't talking about major university numbers here. We have a constituent code of student that I will use. I will populate the date to (constituent code) with the expected graduation date so I can locate them easily when we get the graduation file. I'm also thinking of going ahead and adding the degree to the record, and putting the expected graduation date with their appropriate class year. That way when they do graduate all I am really changing is their constituent code to alumni. I would like to hear anybody else methods used to track student records.  


 
Tagged:

Comments

  • We're a private university and we enter our Freshman Student class every year.  We've been doing it for years and it generally works out pretty well.  Here's a quick overview of our process:


    1. We receive a list of freshman students and parents from our application software.

    2. We clean up some of the data anamolies (typos, zip codes, obvious errors).

    3. We use ImporOMatic to pull in both the student records as well as the parent records.  They're related together with ImporOMatic.

    4. There is still some data cleanup after the fact.  We have to "marry" the parent records together when appropriate.  We also code our Student Consituent code with their starting year (in the Date From field), so we can then idenfity who should be a sophomore, junior or senior in the years to come.


    After the students graduate we're able to then import in our alumni records.  This actually go pretty quickly because we already have the majority of the students in our system with their academic ID (the same one we imported them with... it's an alias in our alumni system).  We add the "Alumni" constit code to their record and then remove the Student constit code at the end of the process.


    Obviously, some students never graduate.  We sweep through Raiser's Edge and remove any "withdrawn" students who are given to us by our Registrar's office.  We do get alumni who transferred in to our school in their sophomore, junior or senior years. They simply come in as new records.


    Hope that helps!
  • Brandon Atkison:

    Hello All,


    We are about to begin adding students into our database. I wanted to reach out to the community to ask, what are your current processes for importing/managing these records? We are an academic medical center so we aren't talking about major university numbers here. We have a constituent code of student that I will use. I will populate the date to (constituent code) with the expected graduation date so I can locate them easily when we get the graduation file. I'm also thinking of going ahead and adding the degree to the record, and putting the expected graduation date with their appropriate class year. That way when they do graduate all I am really changing is their constituent code to alumni. I would like to hear anybody else methods used to track student records.  


     

     

    Sounds like you already have a solid process, here's a few ideas to consider:
    • Assuming student records are managed in another system: use that system"s ids (hopefully same thing as student id) as the RE constituent ID.
    • Ensure no solicitations go to the Student constituency.
    • I recommend that you don't import the degree type until after they graduate, unless this is necessary to segmenting current students.   This is more apt to change than anything else.
    • If you can, get lists each year of student withdrawals - we change student code to alumni non-degree in our system.
  • I would NOT import the expected "Date To" field for constituency, as it may have unintended effects in reporting and processing. You should really have the Alumni/Education module for things like class year/graduation date, but if you don't I think it makes more sense as an Attribute. I also wouldn't add the degree until they've earned it... unless you offer multiple degrees, in which case you will want some way to separate them out.


    After a long, drawn-out battle (within myself), I've actually decided to not just change a student's constituent code to Alumni when they graduate. If we want an accurate picture of our donor base at any given point in time, it's important to keep the "historical" constituent code with the proper dates. It's a little bit more work, but worth it in the long run. Right now, whenever a new class comes in, I import their basic info (name, contact info), a Current Student constituency code and a Date From the start of the semester. Anticipated graduation year and degree gets imported to the Education Record with the College. When a class graduates, I create a query from importing the list of IDs, and then do a Global Add of the graduation date to the Constituency Date To field, and then another Global Add of the Alumni Constituency Code and Date From the day after graduation (don't want to have any overlap).

  •  

    Have you encountered any effects from populating the Date to field? The reason why I wanted to utilize the field is because when their expected graduation date passes it will automatically disable that constituent code. Everyone in the system has at least one constituent code so I would just search all constituents with a blank constituent code. I plan on also using the class year/graduation date fields in the education relationship window. In regards to adding the degrees early, I have no choice. Our Alumni Affairs group wants to be able to email certain degree segments about events to try and get them engaged before they become official alumni.  

  • Brandon Atkison:

    Hello All,


    We are about to begin adding students into our database. I wanted to reach out to the community to ask, what are your current processes for importing/managing these records? We are an academic medical center so we aren't talking about major university numbers here. We have a constituent code of student that I will use. I will populate the date to (constituent code) with the expected graduation date so I can locate them easily when we get the graduation file. I'm also thinking of going ahead and adding the degree to the record, and putting the expected graduation date with their appropriate class year. That way when they do graduate all I am really changing is their constituent code to alumni. I would like to hear anybody else methods used to track student records.  


     

    Every school I have been at adds students at the time of enrollment.  They have a Constit Code of Student, their year of graduation is entered at the time the record is entered.  I would wait on the degree and major, unless you want to be revisiting that info throughout their tenure (since there are peeps that change their major).  You could, if you need to add the degree as a place holder for undergrad and graduate or higher if needed.  I would put Date Entered on the Primary Education record, along with the grad year, I would not use Date To on Constit Code that can limit reporting, you could use Date From.


    Since I can see that if you put them in, you will be asked for analytics/reporting based on grad year, it should go in when entering the record. 


    A bonus of entering the grad year is that you can then format Addressee/Sals to include it if you want, and have it display when you have a record open so that you do not have to click through record to find the year.
  • Brandon Atkison:

    Hello All,


    We are about to begin adding students into our database. I wanted to reach out to the community to ask, what are your current processes for importing/managing these records? We are an academic medical center so we aren't talking about major university numbers here. We have a constituent code of student that I will use. I will populate the date to (constituent code) with the expected graduation date so I can locate them easily when we get the graduation file. I'm also thinking of going ahead and adding the degree to the record, and putting the expected graduation date with their appropriate class year. That way when they do graduate all I am really changing is their constituent code to alumni. I would like to hear anybody else methods used to track student records.  


     

    Ok everyone, I just finished this project up. It took a little longer than expected due to it being the first time we have attempted to put students/residents into the database. We had a lot of duplicates we had to manually match and make sure we updated their records instead of creating duplicates. We had a file of almost 3000 students/residents to load and here is everything I added to each student record:


    1. Created an alias of Student ID so I can search by their ID instead of last name when searching for a constituent.

    2. Put a constituent code of student on the record and populated the "date to" field. (I have yet to find anything that says this field interferes with reporting). My reasoning for using this field is because once that date comes that certain constituent code gets turned off. This will help when trying to identifying students who did not finish or left the program.

    3. Created a constitutuent code of Resident/Fellow (to help seperate them from students) and populated the date from and date to field (was provided).  

    4. Went ahead and put the future degree on their record populating: degree, class year, date graduated, status, and major.

    5. I added an attribute with a category of Student Import and then put the time when each student was expected to graduate (ex. Student Import -- Spring 2017) *I feel like this is going to be very helpful when I go to turn these students into Alumni.

    6. I added an attribute of Student ID and put their individual ID with it. (I know this will not be useful once they graudate, but as long as their in school it will be a good unique identifier).


    I also included all bio information that was provided: Name, DOB, address, and email. 


    Now I have some Majors to cleanup within table cleanup! 


    Let me know what yall think.


     

  • Brandon Atkison:

    Brandon Atkison:

    Hello All,


    We are about to begin adding students into our database. I wanted to reach out to the community to ask, what are your current processes for importing/managing these records? We are an academic medical center so we aren't talking about major university numbers here. We have a constituent code of student that I will use. I will populate the date to (constituent code) with the expected graduation date so I can locate them easily when we get the graduation file. I'm also thinking of going ahead and adding the degree to the record, and putting the expected graduation date with their appropriate class year. That way when they do graduate all I am really changing is their constituent code to alumni. I would like to hear anybody else methods used to track student records.  


     

    Ok everyone, I just finished this project up. It took a little longer than expected due to it being the first time we have attempted to put students/residents into the database. We had a lot of duplicates we had to manually match and make sure we updated their records instead of creating duplicates. We had a file of almost 3000 students/residents to load and here is everything I added to each student record:


    1. Created an alias of Student ID so I can search by their ID instead of last name when searching for a constituent.

    2. Put a constituent code of student on the record and populated the "date to" field. (I have yet to find anything that says this field interferes with reporting). My reasoning for using this field is because once that date comes that certain constituent code gets turned off. This will help when trying to identifying students who did not finish or left the program.

    3. Created a constitutuent code of Resident/Fellow (to help seperate them from students) and populated the date from and date to field (was provided).  

    4. Went ahead and put the future degree on their record populating: degree, class year, date graduated, status, and major.

    5. I added an attribute with a category of Student Import and then put the time when each student was expected to graduate (ex. Student Import -- Spring 2017) *I feel like this is going to be very helpful when I go to turn these students into Alumni.

    6. I added an attribute of Student ID and put their individual ID with it. (I know this will not be useful once they graudate, but as long as their in school it will be a good unique identifier).


    I also included all bio information that was provided: Name, DOB, address, and email. 


    Now I have some Majors to cleanup within table cleanup! 


    Let me know what yall think.


     

     




    After cleaning up the file a bit, we use import-o-matic to import. Class of, major, date entered, type and status are the only fields on the Primary screen that get entered.  The rest go in as attributes.


    1. Attribute for current semester date.  I use this to globally change the Status field (Student - Currently Enrolled, Student - Not Currently Enrolled).  This field is then used to update parent records. We also have Graduated and Left - No Degree.  We use the not currently enrolled status for students who are not taking summer classes or taking a semester off but have not formally withdrawn.

    2.  Attempted degree, major and concentration codes, credit hours, Classification (FR, SO, Jr, etc) Department and School are also attributes.  That data comes from our student/admissions database, so I just overwrite them every semester.

    3. I update the Class Year every semester based on the classification code I get from the student database.  We often get returning students, so I can't base class year off of date entered.


    We started adding the classification codes because we do solicit parents and often want to exclude or include parents of specific types.  The credit hours have been helpful to audit potential scholarship recipients. 



     

  • Brandon Atkison:

    Hello All,


    We are about to begin adding students into our database. I wanted to reach out to the community to ask, what are your current processes for importing/managing these records? We are an academic medical center so we aren't talking about major university numbers here. We have a constituent code of student that I will use. I will populate the date to (constituent code) with the expected graduation date so I can locate them easily when we get the graduation file. I'm also thinking of going ahead and adding the degree to the record, and putting the expected graduation date with their appropriate class year. That way when they do graduate all I am really changing is their constituent code to alumni. I would like to hear anybody else methods used to track student records.  


     

    Yes you should have their expected graduation year on their record.  Every student record should have Primary Education relationship of your school with Grad Year, major/minor if you know it.  If they do not graduated you can use the Status on that tab to record Graduated, Withdrew.  Yes, you can add the expected degree that will be earned also.  At some point once, or twice a year you will have to do a sweep to edit records that have changed (i.e., withdrawn, changed major etc.)  I would also suggest on the Prime Education relationship to utilize Date Entered and Date Left so you can see how long it takes them to matriculate.


    Think about what sort of reporting and/or analysis may be needed, that should help you decided which info you need to record moving forward.
  • I know this is an old post, but am just now reading…. can you tell me what you do with parents records when their student withdraws? Do you delete those records?

  • Carlene Johnson
    Carlene Johnson ✭✭✭✭✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic

    Lisa Geiersbach:

    I know this is an old post, but am just now reading…. can you tell me what you do with parents records when their student withdraws? Do you delete those records?

    Lisa, are you Higher Ed or K-12?

    Generally speaking, I don't recommend deleting records. For K-12, we need to keep the historical data of who WAS a parent in any particular year so that we can continue to calculate participation rates, know who was a part of our community, etc. There is also the possibility that they will reenroll at a future date. Or the family will have siblings of the withdrawn student enroll.

    I use constituency codes with start and end dates as follows:

    • Past Parent 7/1/21 - (no end date)
    • Current Parent 6/1/18 - 7/30/20

    I've seen some places do the following to make a finer distinction that they are a parent of child who did not graduate vs. those who did, though I've never felt it necessary since I can get at that info from the relationship record of the student.

    • Withdrawn Parent 7/1/21 - (no end date)
    • Current Parent 6/1/18 - 7/30/20

    I also code the record accordingly regarding Do Not Solicit or Do Not Mail depending on the circumstances. Sometimes the family is withdrawing because they are moving away but still have a positive relationship with the school and wish to continue hearing from us.

    I can see for Higher Ed there may be a different situation in that the “Past Parent” community is different than that of a K-12. One could make a case that in Higher Ed if there are no gifts, no activity with the past parent of a withdrawn student, and there is no need to solicit in the future that one would remove those from the database. (I'd probably keep… but that is just me!)

    The only time I have deleted the parents of a withdrawn student is if they enroll and unenroll before the school year even starts. In that case I take the student and parents out of RE as they've never actually become part of our community.

    Happy to answer more questions about Constituency Codes or other details of coding withdrawn students/parents!

Categories