parents wanted it – now they have it! parent portal session #30581 march 21, 2012
TRANSCRIPT
Parents wanted it – Now they have it! Parent Portal
Session #30581March 21, 2012
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.50 and v8.52
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.50 and v8.52
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).
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
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
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.50 – v8.52 upgrade Nov. 2012
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– SF – 2008
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.
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
Students log on and navigate to Self Service > Student Services Center
Students are presented with the AAA page
Students are asked to accept responsibility
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
Email correspondence to student an AAA member
Our self service log in page – note the guest access
AAA – the different options
The QuikPay log in page
AcademicInformation Page
AAA – Directory information page
AAA – Financial Aid information page
Emails are sent to AAA member when access is changed or deleted.
Staff can view student authorized members via Campus Community > Student Services Center
There is no staff security to allow for updates, this is view only.
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
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
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
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)
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
Ultimately we persevered!
Questions?
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: [email protected]
• Larry Linneman– Senior Associate University Registrar and Functional Lead Student Records
– University Registrar’s Office
– University of Missouri
– E-mail: [email protected]
Technical Support
• Jim Givens– Programmer/Analyst, Student Records Team Lead
– Enterprise Applications Services
– University of Missouri
– E-mail: [email protected]
• Aaron Jenkins– Programmer/Analyst – Specialist
– Enterprise Applications Services
– University of Missouri
– E-mail: [email protected]
This presentation and all Alliance 2012 presentations are available for download from the Conference site at
www. heug.orgwww.psugonline.org
www.federalusersnetwork.com
Presentations from previous meetings are also available