timing of entering admits to ERP

Main Nav

Posted by CoryFalldine on April 17, 2013

Mike,

If you don’t mind my asking, what are the general parameters surrounding the automated process for removing the student accounts that do not matriculate? For instance, how long do you keep them in the system if they end up not enrolling at your College, etc.?

Cory

Christopher F. Falldine, MBA

Associate Chief Information Officer

Information Technology

Emporia State University (Emporia, KS)

Office: (620) 341-5846

cfalldin@emporia.edu

http://www.emporia.edu/IT

From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of Mike Cunningham
Sent: Wednesday, April 17, 2013 7:22 AM
To: CIO@LISTSERV.EDUCAUSE.EDU
Subject: Re: [CIO] timing of entering admits to ERP

We create accounts when students apply. That also is our definition for when we consider FERPA to start applying to a student. If students do not matriculate we have an automated procedure to remove the accounts. We do this so they can start using our student SIS portal to check on the status of their application and start using the matriculation check-off list we have on our SIS.

Mike Cunningham

VP of Information Technology Services/CIO

Pennsylvania College of Technology

From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis White
Sent: Wednesday, April 17, 2013 4:42 AM
To: CIO@LISTSERV.EDUCAUSE.EDU
Subject: Re: [CIO] timing of entering admits to ERP

Our students receive account credentials when a deposit is received. The thinking here is that this is when they are generally committed to the university and fall under our policies including the AUP governing account and technology use. Before this point it is difficult to say that they are covered by any institutional policies. Also, this keeps us from creating 2,000 email and other accounts that will never be used by applicants or accepted students that do not follow through to deposit and enroll - our auditors generally do not like us having a lot of accounts that never get used. We are using Hobsons to communicate with and engage prospective students and students in the funnel before they deposit so there is really no compelling reason for student accounts before this point.

Curtis

Curtis White

Vice President, Information Technology

Ashland University

www.ashland.edu

Ph: 419.289.5777

Cell: 419.606.3582

Skype: cltrwhite

Attachment	Size
image001.png	130 bytes
image002.jpg	15.21 KB
image003.jpg	3.51 KB

Post a Comment

Comments

I think campuses have to move away from looking at this as the "account" and move to thinking about how you manage identity.

I say this because account is a vestige of a system model of thinking and often account is equivalent to username. This username propagates to a variety of systems (SIS, LMS, Unix, AD,..etc.). Applicants have no reason to use these systems and giving them access creates security and performance concerns.

What you want to think about is adding an identity AND based on the role of that identity they are provisioned a set of services. An applicant role is different from the admit, the admit may be different from student, and student may be different from alum in the services they are provisioned.

This is not easy to implement but it is a model that is inherently flexible and is a direction we need to go if you want to create a set of adaptive IT services based on role.

What we do is applicants get loaded in our identity system and provisioned with the applicant role in our SIS. They log into our portal using their secondary email address as their "username" and the password we provisioned them. The identity system we developed associates this with the internal identifier for the SIS. Our portal has an applicant role and so they get content geared to applicants. A brief note, if you provision applicants you need to have an automated password reset feature built in because they WILL forget their password, we are often one of many institutions they apply too.

One of the projects I've presented on at EDUCAUSE is CommIT, CommIT comes out of work between PESC, Georgetown, and InCommon that would provide students a common account to use across campuses and service providers-- see http://www.pesc.org/interior.php?page_id=214

We are still working to normalize this with all the providers but everyone we talk to recognizes that it is crazy to have an applicant get accounts from every institution and every provider (ACT, CollegeBoard, CommonApp, .....). Could we develop a service that gives the student one account that can be used across all these entities, including applying to our universities. Universities would need to be InCommon to utilize, this but this model might make it much easier for campuses to move away from accounts and move to provisioning services.

The other project that you should follow is CIFER, Community Identity Framework for Education and Research, http://www.ciferproject.org/. The CIFER project goal is to make radical improvements in higher education Identity and Access Management (IAM) capability, ease of integration, and affordability. We want to build a model IAM that can enable this kind of flexible service delivery for campuses to adopt and vendors to follow as model practices.

jack

Jack Suess UMBC VP of IT & CIO
jack@umbc.edu 1000 Hilltop Circle
410.455.2582 Baltimore Md, 21250

Homepage: http://bit.ly/fSB5ID

Posted by: jack on April 17, 2013

Main Nav

Publications

Research

Major Conferences

Online Events

Special Topic Events

Events for all Levels and Interests

Career Center

Leadership and Management Programs

Fellowships and Awards

Getting Involved

Jump Start Your Career Growth

Latest Topics

EDUCAUSE organizes its efforts around three IT Focus Areas

Join These Programs If Your Focus Is

From the Blogs

Find Others

Share Ideas

Get on the Higher Ed IT Map

2013 Strategic Priorities

Membership

Who We Are

Stay Informed

Uncommon Thinking for the Common Good™