Using PII to Support Multi- College FA Processing Presented by SMCCD/SIG

Using PII to Support Multi-College FA Processing

Presented by SMCCD/SIG

2

Introduction

3

Introduction

In order of appearance:

Edgar Coronel

Dave Neil

Laurie Neil

Sheela Mamillapalli

4

Background

• San Mateo County Community College District includes three colleges:– College of San Mateo– Canada College– Skyline College

• Approximately 25,000 students attend all three colleges

• Over $6.5 Million in Financial Aid disbursed annually.

5

Background

• Each college has a unique Federal Pell ID• Home/Host Concept - Enrollment home vs

FinAid home.• Consortium agreements exist among all

colleges.• At the time, Banner™ baseline was unable to

support this functionality.• Local modifications were made to Banner™.

6

Environment

• Institutional issues– Campus code “floats” based on

enrollment– Differences in packaging philosophies

• Campus based aid• Loans

• Student issues– Change enrollment constantly

• Banner™ issues– SGASTDN campus code drives Pell/COD

7

What is the problem?

• Modifications to Banner™ were needed to support multiple Federal Pell IDs

• Eventually the mods became– Numerous, complex (COD!)– Required evaluation with each upgrade– Difficult, time consuming and required significant

resources to support – Hindered the ability to take advantage of many

baseline functions

• Financial Aid module not supported by SunGard ActionLine (COD!)

8

Banner 7™!

• New features in FA– Enhanced multi-college processing for

multiple Federal Pell IDs

• New features in General Module– Personally Identifiable Information (PII)

restricts access to a group of pidms– Value Based Security (VBS) restricts

access to a group of records

9

Development Process

• A lot of help from Laurie/Dave

• Constant communication with the users

• Numerous testing sessions

• Users were very supportive and willing to accept change

10

Technology Background

11

FGAC Overview – Oracle™ FGAC

• FGAC Overview• VBS• PII• Implementation

12


• Banner™ VBS (Value Based Security) and PII (Personally Identifiable Information) are based on Oracle’s™ Fine Grained Access

• FGAC is an Oracle™ Database feature. – Row-level security on any Oracle™ table– Restricts access to an entire row based on

a column’s value

13


• Based upon Oracle™ Table Policies– When a table is accessed, Oracle™ checks

to see if there is a policy on that table– If there is a policy, the function assigned

to that policy is executed

14


• Policy functions determine restriction criteria and create predicate clause

• Predicate clause is appended to WHERE clause of the DML (select, insert, update, delete) statements

• Restricts ALL applications accessing the database table data, not just Banner™

15

FGAC Overview – Banner™ VBS

• Oracle ™ introduced FGAC in Oracle 8• VBS is the Banner 7™ interface used to

manage Oracle™ FGAC– Create the function and the restriction

criteria via Banner™ forms• Does not replace Banner™, Finance or HR

Security

16


• Based on functional processing area (domain)– Payroll– Admissions– Registrar– Financial Aid

17


• Restrict access to objects assigned to that domain– Printers– Address types– Accounting strings– Not PIDMs, that’s PII!

18

FGAC Overview – Banner™ PII

• PII is a Banner™ interface that is also used to manage Oracle™ FGAC– Create the function and the restriction

criteria via Banner™ forms• Restricts access to person data only

19


• Oracle™ FGAC select policy on SPRIDEN table

• Based on functional processing area (domain)– Payroll: PEBEMPL– Student: SGBSTDN– FinAid: RCRAPP1, RORSTAT

20


• Common Matching Process is exempt from PII

• ID Search forms are exempt from PII• For all other forms, it’s as if the person

doesn’t exist

21

Implementation

22

Implementation

• Created applicant tables, one for each college

• Table contains PIDM and Aid Year– Current, previous and next aid year

• PII and VBS are based on applicant tables– Driver tables for each college’s FinAid

domain

23

Implementation – Driver Tables

• Criteria to populate tables– Highest College choice on FAFSA – BOG– SGBSTDN_CAMP_CODE

• Each criteria overwrites the previous criteria– Campus code overrides all (COD!)

24

Implementation – PII

• PII – can only view personal information for students (PIDMs) in the college’s table– Three domains WHERE RXXXXXX_AIDY_CODE =

DriverTable_AIDY_CODE

AND RXXXXXX_PIDM = DriverTable_PIDM

– Assign domains to business profiles– Assign business profiles to users

25

Implementation – VBS

• VBS – created VBS on every FinAid table that has aid year and PIDM– Three groups for each table

WHERE RXXXXXX_AIDY_CODE =



– Can only process records for the aid year and PIDM in the college’s table

26

Implementation – PopSels

• PopSels– Re-enter for each college, referencing that

college’s applicant table




27

Implementation – RORRULEs

• RORRULE– Re-enter for each college, referencing that

college’s applicant table




28

Implementation – Data Conversion

• Convert EDE2, EDE3, EDE4 to EDE• Constraint violations

– Same Banner SEQ_NO for different transaction numbers

– Had to delete duplicate records– Inserted comment into RHRCOMM– ISIR record still exists

29


• Duplicate delete order:– RCRLDS8,7,6,5,4,3,2,1– RCRIMP1– RCRAPP4,3,2– RCRESAR– RCRAPP1

30


• New Form: RZAPIIM– ID and Aid Year in Key Block– Radio Buttons show assigned college– Change college – Reset to original assignment

31


32


New Reports• RZRPIIA: PII Audit Report

– Lists manual (RZAPIIM) changes along with original assignment

• RZRPIIL: PII Log Report– Lists changes made to each PII table through

each step of the table population process• FAFSA, BOG, CAMP_CODE

33

Business Process Changes

34


• Multi-campus (multiple Pell IDs) vs multiple locations

• Regulations allow consortium agreements• COD considerations

– Routing ID • Source Entity ID• Destination Entity ID• Reporting School ID• Attend School Entity ID

35


• Banner™ 7.x improvements on Multi-Campus processing

• ROAINST – Campus/EDE tab

• RORCODI – Setup ID relationships

• RERPLxx – RORCODI and CAMP_CODE

• REAORxx – Origination tied to CAMP_CODE

36


37


38


39


Changes:

– Dataloads• Reduced from three (EDE2, EDE3, EDE4)

to one (EDE)

– Suspense• Reduced multiple copies of a record

down to one

40


Changes:

– Campus Code (SGASTDN)• Now drives Pell, so cannot be

enrollment specific

– Disbursement• More tightly controlled; disbursement

rules prevent payment from wrong fund/campus combination

41


Changes:

– Campus Assignment• Changes made to student campus

assignment, not user campus assignment

– Data consistency• Campus code frozen, drives COD;

controlled by PII

42


• Tasks remaining:– Update AppWorx– Develop a routine for working suspense on

a rotating schedule– Finalize procedures for student

“ownership” and method for transferring– Determine if frozen campus and PII

assignment supports student service

43

Benefits

• Back to baseline – no mods!!!– FinAid Upgrades easier – More functionality– Actionline support!!!

• COD• Consistent procedures across colleges• VBS and PII are easy to maintain once

they’re set up

44

Conversion Update

• So far so good• A few minor issues (data conversion, PII rule

for prior year, form not exempted, etc.)• A small “surprise” with a form where PII

prevented a record from being seen and caused a unique key violation

45

Questions?

46

47

Contact Information

Edgar Coronel650-358-6866

[email protected] Neil

[email protected]

Laurie Neil541-350-6268

[email protected] Mamillapalli

[email protected]

mailto:[email protected]













Documents

Using PII to Support Multi- College FA Processing Presented by SMCCD/SIG