Parents wanted it – Now they have it! Parent Portal

1. Parents wanted it – Now they have it! Parent Portal Session #30581 March 21, 2012

2. Your Presenters • Deanne Jackson • Interim Director of Records and Registration Missouri S&T • Functional Student Record Lead since September 2000 • Project Manager for Student Administration since August 2011 • Implementation team for both v8.0 and v8.9 • Implementation team for PT v.8.51 and v8.52

3. Your Presenters • Larry Linneman • Senior Associate Registrar, Mizzou • Functional Student Record Lead since September 2000 • Implementation team for both v8.0 and v8.9 • Implementation team for PT v.8.51 and v8.52

4. Overview • This presentation will touch on our AAA – Additional Authorized Access parent portal from concept to design to implementation. And how the four University of Missouri campuses came together to create new functionality for parents (and others).

5. Agenda/Contents • UM System Overview and Campus • Four campuses – Separate Instances/Same code • History of Parents/Student access • How we ‘heard’ parents get student data • Concept – design phase • Coding – testing phase • Difficulties when you have four individual campuses all using the same code

6. University of Missouri System • Four Campuses – Columbia Kansas City Rolla St. Louis • Total students - 63,000 • Enterprise Applications Services (EAS) offices - located in Columbia, MO

7. University of Missouri and Oracle • Missouri S&T was the pilot campus for implementation of all student modules • Separate Instance for each campus • All campuses live with v8.9 – v9.0 upgrade Nov. 2012 • All campuses live with PT8.51 – v8.52 upgrade Nov. 2012

8. University of Missouri and Oracle • UMSL • AD/SR/SF/FA - 2008 • MU/UMKC • AD/SR/SF/FA – 2007 • Missouri S&T • Admission 2000 • SR/SF – 2004 • FA – 2008

9. The problem • Parents and others wanted access to student information • Students often gave out their user id/password • This would allow others to access and update student records and have access to other campus systems • Signed forms to allow for information release • Students that signed specific authorization forms would have service indicators added to their id. These service indicators listed the names/phones numbers of who could have non-directory information verbally released to them. • FERPA and user training on campus for this method was difficult to maintain.

10. Research • Started looking at what other institutions were doing to accommodate dilemma • Peer institutions • Conferences Decided on a parent portal concept and quickly came to agreement on design

11. Students log on and navigate to Self Service > Student Services Center

12. Students are presented with the AAA page

13. Students are asked to accept responsibility

15. Email correspondence to student an AAA member • An email is generated to the student and authorized user for each type of transaction the student performs on the Additional Authorized Setup • - Add Member • - Delete Member • - Resend e-mail invitation • - Change to Access granted

16. Our self service log in page – note the guest access

18. AAA – the different options

21. The QuikPay log in page

22. Academic Information Page

23. AAA – Directory information page

24. AAA – Financial Aid information page

28. Emails are sent to AAA member when access is changed or deleted.

29. Staff can view student authorized members via Campus Community > Student Services Center

30. There is no staff security to allow for updates, this is view only.

31. Our Security Approach • Give the student as much control as possible • Notify both the student and the user of all access changes • Track users based on their student-supplied e-mail addresses • User id/password information stored in newly created tables designed for this process. • All changes to the access granted are tracked in the audit tables.

32. Developing the AAA Pages • Cloned delivered student self-service pages • Used delivered code as much as possible • Users’ pages are display only. No information can be updated • Included a link to QuikPay, our third-party payment processor

33. Multi-Campus Issues • Desired maximum flexibility for each campus • Entire mod can be turned on or off with security • Almost all displayed text is stored in the message catalog • Text for e-mail messages is stored in the message catalog • Each campus can customize these message catalog entries to reflect their own policies and procedures

34. Four Campus and System Development • Placed on Project Managers Agenda 4/11/2011 • Missouri S&T Topic Research Presentation 5/09/2011 • ‘Modification Request’ submitted 5/12/2011 • Initial user testing began 9/26/2011 • Number of content/design/security/follow-up/concerns emails = An extra server might have been purchased to handle the volume. • Moved to production 3/06/2012 (usage waiting on campus communications and security)

35. That’s our mod • Roadblocks encountered • Four campus • 4 modules * 4 campuses = too many players • Confusion between AAA and QuikPay • Timing of v9.0 upgrade/eLearning portal • Who to provide technical support? Ultimately we persevered!

36. Questions?

37. Contacts • Deanne Jackson • Interim Registrar , Project Lead Campus Solutions and Functional Lead Student Records • Registrar’s Office • Missouri University of Science and Technology • E-mail: deannel@mst.edu • Larry Linneman • Senior Associate University Registrar and Functional Lead Student Records • University Registrar’s Office • University of Missouri • E-mail: linnemanl@missouri.edu

38. Technical Support • Jim Givens • Programmer/Analyst, Student Records Team Lead • Enterprise Applications Services • University of Missouri • E-mail: givensj@umsystem.edu • Aaron Jenkins • Programmer/Analyst – Specialist • Enterprise Applications Services • University of Missouri • E-mail: jenkinsaa@umsystem.edu

39. This presentation and all Alliance 2012 presentations are available for download from the Conference site atwww. heug.orgwww.psugonline.orgwww.federalusersnetwork.com Presentations from previous meetings are also available