1

Web for Proxy – Set-up Tips

Presented by: Pat Tuchman (University of Illinois)

Kevin Davidson (Rose-Hulman Institute of Technology)

21 March 2011

Session ID 3627

Session Rules of Etiquette

• Please turn off your cell phone/pager

• If you must leave the session early, please do so as discreetly as possible

• Please avoid side conversation during the session

2

Thank you for your cooperation!

Session ID 3627

Introduction

• We’d like to show how to configure the new Web for Proxy functionality

—Rule & configuration tables/forms

—Web Tailor

What the authorizer sees

3

• What the authorizer sees

• What the proxy sees

• We’d also like to show how to monitor the system

• Of course, let’s see how the system works!

Session ID 3627

2

Agenda

• Brief history – Web for Parent leads to new effort

• All the configuration that’s available—And what it all means

• What system “monitoring” is available

4

• And, what will happen when you “flip the switch”!

• Migration from Web for Parent to Web for Proxy

Session ID 3627

But first, who are we?

Kevin Davidson

• Principal Technologist with Rose-Hulman Institute of Technology (1980-present)

• Developed the original Web for Parent mod and shared the code with many other schools

• Proponent of community source, code repository and any other effort that will improve the Banner product

Session ID 3627 6

3

Pat Tuchman

• University of Illinois

• Member of the Student Functional Review Committee (Community Source Initiative)

• Really likes this mod and wants it to be baselined!

• Ended up as project manager of the effort

Session ID 3627 7

BETWEEN FRIENDS ©(2010) SANDRA BELL LUNDY DISTRIBUTED BY KING FEATURES SYNDICATE

History – Web for Parent

Rose-Hulman’s Web for Parent

• Extension to Banner self-service

• Meant for students to authorize their parents to see information on self-service pages—So parents didn’t need to “borrow” credentials

• Minimally invasive – very few changes to baseline Web Tailor packages

• Very successful— In production at Rose-Hulman since July 2003

—Distributed to 75+ other institutions

Session ID 3627 9

4

Web for Parent → Web for Proxy

• Submitted to the Student Review Committee of the Community Source Initiative

• The committee liked it, except for a “few” items

• Rose-Hulman couldn’t commit to all the work needed—Even though they agreed with the proposed changes

• Community Source put together a consortium of schools to work on the enhancements

• Began the re-design during the summer of 2010

Session ID 3627 10

Web for Parent vs. Web for Proxy

Web for Parent (existing) Web for Proxy (new)

Used by students and parents Supports multiple relationship types

Parent must be in General Person Any SSB can add a proxy if the proxy has a valid e-mail address

Parent entered into Banner by hand Optional load for proxy data using Common Matching

One list of potential pages Each relationship type has its own list of potential pages

Required Banner Advancement Self-contained relationship table

Required Banner A/R (FERPA) Flexible FERPA indicator

2 new tables 14 new tables (GENERAL schema)

Minimal configuration needed Many options can be configured

Exposed parent credentials to student

Direct communication with proxy, student and administration

Source provided by Rose-Hulman Source is targeted for baseline

Session ID 3627 11

Who’s been involved?

• George Washington University

Kent State University

• Michigan Technological University

• Radford University

Rose-Hulman Institute of Technology

Seton Hall University

• SunGard Higher Education

Taylor University

• University of Central Oklahoma

University of Illinois

• University of Vermont

• Wayne State University

• Wheaton College (Massachusetts) core participant

Session ID 3627 12

5

All that configuration – rule & validation tables

Basic concept – system & relationship type

• Design was for VERY generic infrastructure—So other systems could make use of it

• Both SunGard Higher Education & any locally written

—Over-engineered for our immediate purposes

V lid ti t bl• Validation tables—GTVSYST – the system (e.g. PROXY)

—GTVRETP – the relationship type (e.g. parent, advisor, coach, employer, agent, BFF)

• Rule table—GEBSRTP - what relationship types does each system

use

Session ID 3627 14

Example of the basic configuration

System Relationship types

Proxy Parent

Proxy Employer

Proxy BFF

Affiliation Parent

Affiliation Best Friend

Affili ti SibliAffiliation Sibling

Session ID 3627 15

6

How to specify options

• We wanted to minimize use of GTVSDAX

• We wanted to make as many design decisions as possible to be locally configurable

• Some options needed to be set for the system and others needed to be set for each relationship type—For the latter, we wanted to provide a system default

• Validation table—GTVOTYP – option types available for a system with

default values

• Rule table—GEROPTS – option types available for the system &

relationship type combinations

Session ID 3627 16

Example of the options configuration

System Option Default System or type?

Relationship type specific values

Proxy Default days

180 Either

Proxy Log logins Y Either

Parent Employer BFF

365 10 1

Employer BFF

N N

Proxy Log pages viewed

Y System

Affiliation Days between reminders

20 Either

GTVOTYP GEROPTS

Session ID 3627 17

Parent Sibling BestFriend

5 14 1

Some options available for Web for Proxy

• Default days until stop date

• Default days for proxy to activate

• Keep history of page authorization changes

• Keep history of proxy logins

• Keep history of pages viewed by proxy

• Enable authorization at page levelp g

• Display existing proxies

• Display name on proxy page

• Common matching rules

• Default address type

• Default email type

• Opt-out of Advancement

Session ID 3627 18

7

How to specify what proxy data to load

• Not all institutions will want to load all the data—Some may want every possible proxy in Banner person

and in Advancement

—Some may want only some information loaded

—Some may not want any information loaded anywhere

• “You’re going to do what to my multiple pidmteam’s workload?!?!?!”team s workload?!?!?!

• Validation table—GTVDTYP – what data types are expected to be loaded

• Rule table—GERLOAD – for each system, relationship type, and

data type, should we load the data?

Session ID 3627 19

Example of the data moving configuration

System Relationship type Data to be created

Proxy Parent

Proxy Employer

Proxy BFF

Basic person Proxy Advancement

Yes Yes Yes

Basic person Proxy Advancement

Yes Yes No

Basic person Proxy Advancementy

Affiliation Parent

GTVDTYP GERLOAD

Session ID 3627 20

No No No

Basic person Proxy Advancement

Yes No No

Communications

• There are a number of communications that can be sent out, including:—New proxy, new relationship or relationship change

—Pin reset or e-mail address change

—List of pages the proxy is authorized for

• Modeled on the waitlist configurationU b li B il/l tt fi ti—Uses baseline Banner email/letter configuration

• Validation table—GTVCTYP – communications types

• Rule tables—GEBCOMM – communication types for the system

—GERCOMM - communication types available for the system & relationship type combinations

Session ID 3627 21

8

Example of the communications configuration

• This is for “new proxy being established”

• Person-centric—Need to be aware of the relationship type between the

person and the proxy

Role relationship Notify? Letter code BCC admin?

Session ID 3627 22

Role - relationship Notify? Letter code BCC admin?

Person Yes W4P_person_new No

Admin No

Proxy – parent Yes W4P_parent_new Yes

Proxy – employer Yes W4P_employer_new Yes

Proxy – BFF Yes W4P_BFF_new No

Example of the communications configuration

• This is for a “reset pin”

• Proxy-centric—Unaware of the relationship type between the person

and the proxy

Role Notify? Letter code BCC admin?

Person Yes W4P person pin No

Session ID 3627 23

Person Yes W4P_person_pin No

Admin Yes W4P_admin_pin

Proxy Yes W4P_parent_pin No

FERPA authorization

• Some institutions need a FERPA authorization on file before a student can authorize anyone

• There is no single place in Banner for this authorization to be maintained

• We needed a single place to look for this authorization

• Decided to use the existing GORRSQL form/table— It allows locally written SQL to be evaluated during

processing

• We plan to include several sample rules

Session ID 3627 24

9

Examples of possible FERPA checks

• Mimic existing Web for Parent—Check TVRAUTH for codes specified in GTVSDAX

• Special student cohort code(s) in SGRCHRT

• Special student attribute code(s) in SGRSATT

• Locally defined tables—e.g. University of Maryland Baltimore’s

• Assume that the act of authorizing a proxy implies FERPA permission— i.e. don’t need to check anywhere

Session ID 3627 25

Sample FERPA rule

Session ID 3627 26

Who is eligible to be a proxy?

• Possible to display a list of potential proxies

• Different institutions may want to include more or fewer categories—E.G. from Advancement, primary advisors, etc

• We needed a single place to look for these categories of people

• Again, decided to use the existing GORRSQLform/table

• We plan to include several sample rules

Session ID 3627 27

10

Sample Potential Proxy rule

Session ID 3627 28

All that configuration – Web Tailor

Potential Pages for Proxy Access

• Menu records for each relationship type— Naming convention is web4proxy-????-xx

—???? is the relationship type (required)

— xx is a grouping parameter (optional)

• The menu record must be enabled (TWGBWMNU)

30

—Menus are ordered by menu description

—Menus are grouped by description

• The menu option record must be enabled (TWGRMENU)—Menu options are ordered by menu name & sequence

—Menu options are grouped by menu name

Session ID 3627

11

Which Pages Can be Authorized and How?

• A page can be included in multiple groups

• A page can be included for multiple relationship types

• Up to the institution to decide which pages to allow—We have not tested all possible Web pages

—Some may not work

—Remember – if a Banner person can update data on a page, whoever is a proxy can update the same data

• And it will look like the Banner person did it!

• Not limited to SunGard Higher Education supplied Web pages—Any page accessible via SSB

Session ID 3627 31

What are the Groups For?

• The system allows the Banner person to authorize by group level as well as by individual page—This is controlled by a configuration

• For example, Student pages could be grouped:—Registration related

A d i hi t l t d—Academic history related

—Holds related

• Use of groups is optional

Session ID 3627 32

Example of using groups

3 groups (3 menus, 1 & 2 have common description)

PAGE_LEVEL_AUTHORIZATION = ‘N’

Session ID 3627 33

12

Other infrastructure

Data load

• Modeled on existing processes to load contents of “temporary tables” into Banner

• Batch processes to load the data—Multi-part

• Basic person tables

• Proxy tables

• Advancement tables

• INB forms to resolve errors—Common matching suspended records

—Other data errors

Session ID 3627 35

Data flow – the basics

P t

Person initiates proxy

Proxy tables

General

Person authorizes proxy

Email sent to proxy

Common matching

Session ID 3627 36

Proxy enters data

Banner(traditional)

General matching

tables

invoked to get proxy into Banner

Proxy logs in and starts looking at SSB

pages Steps in red are optional – depends on the configuration that has been done

13

Data Load – little more detail

Proxy comes in to set up credentials

General matching

tables

Banner person data

Process to create and/or

update Person data

Process to

Session ID 3627 37

Proxy data

Advancement data

Process to update Proxy

data

Process to create and/or

update Advancement

data

Authorized staff “monitor” form

• For each person, authorized staff can:—See all the proxies that have been set up

—See all the authorizations

• Both allow and revoke

—See the pass phrase for that proxy

—See the accesses the proxy has done

A i th t thi t f l i h b• Assuming that this type of logging has been enabled

• For each proxy, authorized staff can:— Initiate a pin reset

—Check the pass phrase before divulging information

Session ID 3627 38

Authorized staff “monitor” form – mock-up

Session ID 3627 39

14

Putting it altogether

Student authorizing a new proxy

• You can get some screen shots for this, right?

Session ID 3627 41

Proxy logging in

• Screen shots would be good here.

• Or, let me know if I should do a mock-up

Session ID 3627 42

15

Proxy seeing what they’ve been authorized for

Session ID 3627 43

Migrating from Web for Parent

Steps for Web4Parent users in migration

• Review the configuration & decide on your approach—Mimic existing vs. adding new functionality

—New functionality can be phased in

• Do your configuration in a test environment

• Test, and test some more

• Plan the communications about the upgrade!—To the students

—To the proxies

—To the support staff

Session ID 3627 45

16

Checklist of configuration

Checklist – what to review/configure

1. Validation tables setup

2. Rules setup

3. Options setup

4. Communications setup

5. Query setup

Session ID 3627 47

Checklist – what to review/configure – Web Tailor

• Web Menus and Procedures—Enable menus for each relationship type

—Customize menu descriptions

—Configure roles for proxy management pages

• Menu Items—Enable menu options for each menu

—Customize link text

• Information Text—Customize text and icons

• WebTailor Parameters—EMAIL_HOST

—WEB4PROXY_DAD

Session ID 3627 48

17

Summary

• There is a lot of configuration to understand—Most of it needs to be set up only once

• Institutions have a corresponding amount of flexibility

49

• Options could be turned off/on depending on the point in the academic cycle—E.G. turn off logging when grades are posted

• Web for Proxy is on its way to baseline!!

Session ID 3627

Questions & Answers

50Session ID 3627

Session Sponsor

Thank You!

Pat Tuchman (ptuchman@uillinois.edu)

Kevin Davidson (davidson@rose-hulman.edu)

51

SunGard or its subsidiaries in the U.S. and other countries is the owner of numerous marks, including “SunGard,” the SunGard logo, “Banner,” “PowerCAMPUS,” “Advance,” “Luminis,” "DegreeWorks," "fsaATLAS," “Course Signals,” and “Open Digital Campus.” Other names and marks used in this material are owned by third parties.

© 2010 SunGard. All rights reserved.

Session ID 3627

Please complete the online Session evaluation form

Session ID 3627