Obviously, we don't have students or parents of students in my current job, but this is a topic that's near and dear to my heart, so I'll see if I can share a few thoughts.
At my previous institution, we had a similar issue with the Admissions office, so our initial implementation was to receive the data immediately after "control" passed from the admission office to the Registrar's office. That occurred shortly after the deadline when admitted students had to make their deposit to confirm their attendance.
Early on in setting up that process, there was a misapprehension on the part of the Registrar's office that the advancement office/system could only receive "directory" information on students, so we were not receiving information like student ID and date of birth, which were both key to setting up effective matching, and we were not receiving any information about parents from the student system. The conversation about the information provided to advancement took place along several tracks, with counsel eventually weighing in with the definitive view that, under FERPA, non-directory information could be shared with school officials with a legitimate educational interest in the information, and that under the definitions in the university's FERPA notice (following, in turn, the model disclosures published by the Family Policy Compliance Office at the U.S. Department of Education), advancement staff (and staff at the associated foundation and alumni association) were school officials who had a legitimate educational interest in the information that they needed to fulfill their professional responsibilities. And, therefore, we could receive non-directory information like the student ID, date of birth, and parent information.
Each spring, once the responsibility for the data on new students passed from admissions to the Registrar, we received one file with that included information about both the student (including name, contact info, student ID, date of birth, degree program, etc.) and up to 4 associated parents (including name and contact info: postal address, telephone number, email address) as recorded on the student's record in the student information system. There were some issues with the parent information, I should note. For example, the same parent might appear more than once in the row for a student, since that was the only way that the student system had to record a name variant for a parent (like an alternate hyphenated last name or a nickname) or to record more than one address or phone number for a parent. Also, the student system did not support linking spouses, so we had to try to infer parent married couples from common address information. (This also meant that we wound up with much better parent information that the student system did, especially since we ran a regular NCOA process that included parents, so that the parents association became interested in using our data rather than the student-system data!)
The key to being ready for an agile response to notices that a student had failed to attend or had withdrawn is that we made a first pass through the new student file to create records in the advancement system for the incoming students. Matching was pretty easy, because most of the records were new, and for students already in the database (for example, those going on to a graduate degree) we could match on the student ID number (we had had a project to back-fill those once it was made clear that we were entitled to that information).
Once we had the student records in place, we made a second pass through the file to match/create the parent rows. As I mentioned, we inferred spouse relationships based on shared addresses, and-key point-we created a parent/child relationship between the parents and the students. That made it easy to adjust whether the parent(s) were included in communications or solicitations once we had notice of a change of status of the student. It also meant that we could use the class standing that was part of the student row to segment the associated parents if we were looking only for parents of seniors, etc. We could also code students who had been awarded named scholarships right there at the time of the award, code athletic participation, code participation in key student activities, etc., and use all that data to identify the parents of students with those characteristics, as appropriate.
After the drop/add date for the fall term, we got the same file, but extended to include all parents. Matching the students was trivial, since we had the student ID. Matching the parents was pretty easy as well, since, while there may be a bunch of "John Smith" records in the database, only one of them was the parent of the student with student ID 123456789! The process also updated contact information and class standing. Each time we loaded the file of current students, we deleted and re-built the major and minor information associated with their current degree program, rather than trying to selectively modify it. That proved really useful if a student left without completing a degree. Previously, when we only loaded students upon graduation, we didn't have any school/degree/major information on non-graduates, but, loading that information for students, we had the most recent degree-program information left in the system at the time that the former student left the school. We could also change the status of any "current" students in our database that weren't included in the new feed of current students. The process was getting robust enough that we were thinking about getting the whole student file not just during the first term of the academic year but every term and updating the records accordingly. (We did also receive files of graduates after each awarding of degrees, in the same format, and used it to update the new graduate records accordingly.)
Our admissions office did try at one point to fight a rear-guard action, attempting to assert that the admissions office should decide which parents the advancement office would later be able to solicit. For example, they wanted to bar advancement from soliciting parents of students receiving full need-based scholarships. It was very interesting that the then-Annual Fund director was a recent alum who had received a full scholarship and who reported that his family was very appreciative of the aid that he had received and was grateful to have the opportunity to make a modest contribution in return! We eventually worked around to the view that, while the admissions office was free to flag those records for us, they would continue to make the decisions about admitting students, and the advancement office would make the decisions about soliciting their parents. That did take some discussion at the senior-management level.
There's more, but perhaps that's enough for now!
My US$0.02 worth; the usual disclaimers apply.
Good luck!
Alan
Alan S. Hejnal
Data Quality Manager
Smithsonian Institution - Office of Advancement
600 Maryland Avenue SW, Suite 600E
P.O. Box 37012, MRC 527
Washington, DC 20013-7012
*: 202-633-8754 | *:
HejnalA@si.edu<mailto:
HejnalA@si.edu>
[SNAGHTML5cbfa34]<https://www.si.edu/> [AASP_FundSvcs_LOGO-01(040pct)(mark)]
From: Advancement Services Discussion List <
FUNDSVCS@LISTSERV.FUNDSVCS.ORG> On Behalf Of Callaghan, Jeffrey B.
Sent: Wednesday, September 4, 2019 5:47 PM
To:
FUNDSVCS@LISTSERV.FUNDSVCS.ORG
Subject: [FUNDSVCS] Parent Data Best Practices
Hi all, I'm combing the archives and know this is a familiar (if ever-evolving) topic. As such, I thought it best to start fresh:
I'm curious at what point you load parent data from Admissions into the fundraising database. Admission? Deposit? Enrollment? Do you receive all available parent data (including phone and email) or only select fields?
For context, Admissions uses Slate and my side is on Advance. Admissions has typically provided a file for us in our preferred layout, we scrub, load, then export and send off to Research Point for screening. This year we did not receive phone numbers and email addresses which - though not required for screening - are critical for identifying duplicate records and also important breadcrumbs that help paint a fuller picture of our parents. These two fields are available after the add/drop date, when students are actually enrolled.
Admissions is understandably concerned with Advancement soliciting parents whose students may have cancelled or deferred their admission to our university. So as to a) capture the data we need for research and b) adhere to Admissions' mandate to not contact incoming parents until we have ensured their child is indeed attending -or the parents make a gift and are "organically" added to the database -my office has committed to "firewalling" incoming parent records until class begins and Advancement is cleared to contact. Our weekly Banner checks for withdrawals and leaves of absence is not satisfactory, and we'd like to prevent any outreach instead of monitoring activity after the fact. While the particulars of this are still TBD (new record type? new status?), we'll find a way to make it work.
Long story short - when do you get parent data and what (if any) restrictions are placed on that data? I'd like to gather some best practices from our peer and aspirational institutions to compare and contrast.
With thanks,
Jeff
Jeff Callaghan
Director, Advancement Information Services
[LMU logo]<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lmu.edu%2F&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654236547&sdata=F1KhilGldlsYMiSNgtf4WCjHiKEFsR3C9QgeGc5hHz4%3D&reserved=0>
University Hall 2800
1 LMU Drive
Los Angeles, CA 90045-2659
www.lmu.edu<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lmu.edu%2F&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654236547&sdata=lOvxHq%2BMlajAkO1ZIcgMPzz6%2FZBvxaKioc41mJffNX8%3D&reserved=0> | Privacy + Legal<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lmu.edu%2Fcopyright%2F&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654246543&sdata=%2BxFGzM5X3YlYIevc6IY2qA4XaFqWjfKoKLZEx8F678o%3D&reserved=0>
Office
310.338.2378<tel:+13103382378>
Mobile
424.207.7337<tel:+14242077337>
Email
jeff.callaghan@lmu.edu<mailto:
jeff.callaghan@lmu.edu>
[https://s3.amazonaws.com/lmuemailsignature/email-fb.png]<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Flmula&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654246543&sdata=8BeooEjDxhbVn8VHF0sJWT%2FTMIYQYMUaibSsY1XcjGw%3D&reserved=0>[https://s3.amazonaws.com/lmuemailsignature/email-tw.png]<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Floyolamarymount&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654256545&sdata=VjHF09O1kL35LxOuALoFoTGP8EyAtq7Sz9ZxXa%2F27Mo%3D&reserved=0>[https://s3.amazonaws.com/lmuemailsignature/email-in-1.png]<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Finstagram.com%2Floyolamarymount%2F%3Fhl%3Den&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654256545&sdata=qlHFAaE%2FGdy4ds%2B659w5m6LMcx0kfGfy4f5XtQPO2Qs%3D&reserved=0>[https://s3.amazonaws.com/lmuemailsignature/email-li.png]<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fedu%2Fschool%3Fid%3D17875&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654266534&sdata=zJqvKU96TLmcumez5Ql22j%2BHoXOxfRCE%2B3sZQHWOGhk%3D&reserved=0>[https://s3.amazonaws.com/lmuemailsignature/email-yt.png]<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2Floyolamarymount&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654266534&sdata=WLOMmeiho1Gj4rlo9UiIkJ7YGzApRIpbejDGzULB%2F0Q%3D&reserved=0>[https://s3.amazonaws.com/lmuemailsignature/email-pin.png]<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pinterest.com%2Floyolamarymount%2F&data=02%7C01%7CHejnalA%40SI.EDU%7C9193c763e1f843a00aa308d731818300%7C989b5e2a14e44efe93b78cdd5fc5d11c%7C0%7C0%7C637032304654276526&sdata=ylOCZJVmUkrLxHpxvN%2FuM0pusO%2BzZADhDsfm8U6D%2Fc8%3D&reserved=0>