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.51 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.51 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 – ColumbiaKansas CityRollaSt. 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.51 – 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– FA – 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– 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.

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– Who to provide technical support?

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: 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

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

This presentation and all Alliance 2012 presentations are available for download from the Conference site at

www. heug.orgwww.psugonline.org

www.federalusersnetwork.comPresentations from previous meetings are also available