KS ENR Functional Training
Module 2:: Understanding the
Enrollment Environment
Topics and Presenters
Item
Presenter
Project Role
Welcome and Context
Carol Bershad
Analysis Team, Lead
Product Manager (Interim)
People and Permissions:
• Concepts and Terminology
• Services
Steve Barnhart
Ruth Schleifer
Cathy Dew
Analysis Team, SME
Analysis Team, BA
Services Team, Lead
Setup (Time): Academic Years/Terms
• Wireframes
• Concepts and Terminology
• Services
Kristina Batiste
Steve Barnhart
Cathy Dew
UX Team, Designer
Analysis Team, SME
Services Team, Lead
Setup (Environment): Registration Environment, Holds, Exemptions
• Wireframes
• Concepts and Terminology
• Services
Kristina Batiste
Steve Barnhart
Cathy Dew
UX Team, Designer
Analysis Team, SME
Services Team, Lead
KS Enrollment Application Map
Kristina Batiste
UX Team, Designer
Supporting Materials
Carol Bershad
Facilitator
Mike Huynh
Analysis Team, BA
Logistics Coordinator
Cheryl Medley
Project Mgmt Coordinator
Critical Observer
Dan Symonds
Analysis Team, SME
For agenda details, presenter contact information and supporting materials, please visit
Understanding the Enrollment Environment
2
Module 2 -
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
9. Academic
Planning
6. Program
Offering
3. Course
Offering
KS
Financials
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
UW My
Plan
5. Course
Assessment
9. Academic
Planning
1. Setup
8. Program
Assessment
KS ENR:: 10 Functional Areas
Objectives and Expectations

Overall Training Objective:: To equip participants with a solid
understanding of the functional framework of the KS Enrollment
Module and the associated business artifacts as they currently exist.

Module 2 Objectives:: To provide a more in-depth understanding
of the following functional areas of KS ENR, including key concepts
and terminology and the status of all related analysis and design
artifacts (i.e., requirements, service contracts an wireframes)
 “Setup”
 Managing academic years and terms
 Managing the registration environment
 Managing the Holds Inventory
 Managing the Exemptions Inventory
 “People and Permissions”
 Managing People
 Managing Permissions
4
Where we all
WANT TO BE
We are HERE
You are HERE
“Pulling you up”
“Teaching you to fish”
Psst… What the heck does “manage” mean?

The term MANAGE is generally used as shorthand to
refer to:


Your basic CRUD operations (Create, Read, Update, Delete)
Plus other context-dependent functionality (e.g., Search,
Group, Relate).
But (and there is always a ‘but;’
oh, were you expecting a
different image?) ….

in some instances, CREATE is called out separately from
MANAGE

In those instances, the scope and complexity of the initial
create process is such that it warrants separate
consideration (e.g., "Create Course Offerings").

In cases where it doesn't, the term 'Manage' is assumed to
include 'Create' (e.g., "Manage Academic Calendars")
5
KS ENR Functional Area:
People and Permissions
People and Permissions: PEOPLE

People can be thought of as things (“objects”), actors (“roles”), or both (the
ugly intersection)



Things (“Objects”): What do we need to know about them? What can be done TO
them?  People as Objects drives Attributes
Actors (“Roles”): What can THEY do?  People as Roles Drives Permissions
People as OBJECTS





Kuali Identity Management (KIM) terminology is “entities”
Examples of People as Objects:
 An admitted Student
 An Instructor teaching specific course offerings
 An Advisor assigned to specific programs or students
KS ENR is primarily concerned with the “Student Object”
 KS ENR is the system of record for the “Student as a Thing”
 For others, it is mainly concerned with other “People as Actors”
Interfacing with internal and external systems
 Instructors, Advisors accessed from institutional HR and Identity Management systems
 Students from internal or external Admissions systems
People as Objects may be directly assigned to organizations
7
People and Permissions: PEOPLE

Creating and Managing People as OBJECTS – Students
 Creation of initial student population will be via data interface from



institutions’ existing student information systems
As the majority of students on an ongoing basis originate in an
admissions process, their creation will also be accomplished through
a data interface to institutional admissions systems
Certain graduate professional schools may use common outside
services (LSDAS, AMCAS) for admissions the interfaces for which may
be opportunities institutional contributions back to KS
KS will allow the creation of individual student records by authorized
users to accommodate those students who do not participate in an
admissions process
8
People and Permissions: PEOPLE
 Creating and Managing People as OBJECTS – Students
 Data elements include:
 Names (legal, nick-names, maiden, married, professional, etc.)
 Demographic (birthdate, birthplace gender history, ethnicities, First




Nation status)
Contact information (physical addresses, email addresses, telephone
numbers, social media)
Citizenship information (countries of citizenship, immigration and
visa status)
Residency information
Identifiers (university ID number, net ID’s, SSN, Social Insurance
Number, SEVIS number, etc.)
9
People and Permissions: PEOPLE
 Creating and Managing People as OBJECTS – Students
 Initial development will concentrate on the administrative
ability to manage information about students

Later development will provide students with self-service
functions to manage their personal information
 Institutions will be able to identify which data elements students will
be able to maintain themselves
10
People and Permissions: PEOPLE

Creating and Managing People as OBJECTS – Instructors
 Interfaces from institutional HR systems to KIM will provide the



majority of the pool of Instructors
Interfaces from institutional identity management systems to KIM
will provide information on Instructors who are not university
employees (some adjuncts, visiting professors, etc.)
Long-term desire is to maintain qualifications of Instructors such as
certifications, areas of special knowledge, preferred subject areas, in
order to make assignments to course offerings
Will require additional information be maintained in KS which KIM
does not accommodate
11
People and Permissions: PEOPLE

Creating and Managing People as OBJECTS – Administrators
 May be “central” or “departmental”
 Interfaces from institutional HR systems to KIM will provide the pool


of administrators
Interfaces from institutional identity management systems to KIM
will provide information on Administrators who are not university
employees (ROTC staff)
Will require additional information be maintained in KS which KIM
does not accommodate
Next, we will consider People as Actors, i.e., Permissions
12
People and Permissions: PERMISSIONS
 People as Actors




KIM terminology is “principles”
Active within KS, they can do things
Associated with organizations
Actors have roles


Their roles may be derived by their being objects
This is the potentially “ugly intersection” ….
13
I’m
“acting”
People and Permissions: PERMISSIONS

Permissions
 In the KS business world, “Permissions” is used interchangeably with the


term “Authorization” to refer to the ability to access to specific
functionality in KS; examples include: “can Enter Grades,” “can schedule
Classes”
In the KIM world, “Permissions” represent more fine grained actions that
have very specific constraints. Some examples would be: "canSave", “can
Edit” that are scoped by NameSpace.
Roles
 In the KS business world, “roles” is a collection of Authorizations
 In the KIM world, “roles: refers very specifically to a collection of


Permissions
May be defined specifically based on organizations, or more globally
Allows shorthand granting of groups of authorizations to like
individuals (Advisors, Instructors, Schedulers, etc.)
14
People and Permissions: PERMISSIONS

Person Types
 A fundamental relationship between an individual and the institution




Determines the minimum data required to create such a person record

We’ve not settled on whether the concept of a “primary” person type
will be necessary
Constrains which authorizations may be granted
Provides context for the individual’s interaction with KS
Individuals may have multiple concurrent person types (graduate
students may also be instructors of record, staff employees may be
pursuing degrees, etc.)
15
People and Permissions: PERMISSIONS

Qualifiers
 An attribute of an individual which constrains one or more particular

authorizations
May be derived from other data

Example: A faculty member may have the authorization to enter grades;
this authorization may be constrained by the qualifier of the course
offerings for which she is the instructor of record

Example: A departmental administrator may have the authorization to
schedule classes; this authorization may be constrained by the qualifier
of which department he is in
16
People and Permissions: PERMISSIONS

Delegating Authority
 The granting of one or more specific authorizations, including
qualifiers, of one user, by that user, to another user for a specific
period of time

Professor Smith will be a attending a seminar in Europe during the
registration period for Fall 2012; he delegates his authority to waive
prerequisites for his courses to Professor Jones during that period, but
delegates his authority to allow non-business majors into his classes
during the same period to his departmental administrator, Carol Craig
 All transactions will reflect the identity of the person actually
performing the transaction, rather than the identity of the individual
who delegated the authority to that person
17
KS Strategy for RICE Modules
 General strategy is to leverage RICE modules as much as possible in KS
Enrollment
 KRAD (UI platform)
 Focus of RICE development for 2.0 and 2.1
 KIM (Person Identity, Permissions)
 Strategy for gaps
 Strategy for authorization
 KRMS (Rules)
 How this maps to concept of a Process Service
 Collaboration with Coeus
 Strategy for performance
 KOM (Organization)
 Explore KS Org contract + MSU implementation
 Further out
 KEN (Notification)
 KEW (Workflow)
KIM People (who need people)

The current KIM identity service also combines together distinct
concepts ::



The creation and management of People (e.g., students, parents,
instructors, advisors)
Identity management for security purposes (user login and access rights)
In ENR, this will be greatly enhanced ::








Update methods on biographic and demographic data
Complex Matching Logic
University ID assignment
Identification and merging of duplicates
Batch syncing of large numbers of people from other sources (e.g.,
Admissions, HR)
Person-to-Person relations
Configurable control over access to sensitive data
Alignment with PESC
KIM Permissions
 Roles

Department Curriculum
Coordinator
 Roles assigned to Members with
Qualifiers

DCC is assigned to John the
Dept Admin for English and
History
 Role Types

Check that input qualifiers
match the role's qualifiers

Generate derived roles
memberships based on other
data in the system
 Permissions


courseService.createCourse
courseService.deleteCourse
 Role Template

Course Service Permissions
 Role Permission Mapping

Department Curriculum
Coordinator



courseService.createCourse
courseService.getCourse
courseService.updateCourse
KS ENR Functional Area:
Setup (Time): Academic Years, Terms and Milestones
Academic Years and Terms Sitemap
22
Academic Years and Terms Prototype
Administrative user will
fill in details about a
future term, including
Registration Period,
Holidays, and Start and
End dates.
23
Setup (Time):
Academic Years and Terms

Managing Academic Years
 Inherits holidays and instructional days from calendar year
 KS allows for multiple academic years at a single institution

Regular undergraduate and graduate programs may have an academic
year from late-August to mid-August

The School of Medicine’s academic year may be from July to June
 Establishes basic dates into which Terms must fall
 Will benefit financial aid module in later development
24
Setup (Time):
Academic Years and Terms

Managing Terms
 Terms are components of academic years
 Terms inherit holidays and days of instruction
 Term beginning and ending dates may not violate those of the

academic year to which they belong
Terms may contain other terms nested underneath them (sub-terms)

The Summer Semester may be comprised of the First Summer Short
Term, the Second Summer Short Term, and the Summer Long Term
25
Setup (Time):
Academic Years and Terms

Managing Academic Milestones
 Most common milestones are term-based
 Such milestones include, but are not limited to:



Registration periods
Class add period
Class drop period
• Without academic record
• With academic record





Program enrollment deadline
Mid-term grading period
Final grading period
Withdrawal deadline
Census date
26
Setup (Time):
Academic Years and Terms

Managing Academic Milestones
 Institutions may establish milestones discretely or relatively


Discrete: Last day to add classes for Fall 2012 is September 7, 2012
Relative: Last day to add classes for Fall 2012 is 21 days after the first
day of classes
 Academic milestones are not inherited from term to sub-term
27
Setup (Time):
Academic Years and Terms
 Setting up Environment
 Global and term-specific registration rules




Maximum/Minimum units/credits per term
Do waitlists count toward maximum credits per term
Mandatory advisement requirements
Time conflict parameters

Overlaps of more than x minutes constitute a time conflict
 Course registration fill percentages or minimum registration counts

Minimum number of students which must register for a course offering
for it to “go”

Minimum percentage of seats which must be filled for a course offering
for it to “go”
28
From ATP to Academic Calendar
While this service is very powerful and very flexible, it is
also somewhat confusing and cumbersome from an
application development perspective.
From ATP to Academic Calendar (cont.)
The Academic Calendar Service
Probably more than you wanted to know…

Terms are managed independently of Academic
Calendars

Nesting of Terms is performed through their own
service operations, a Term can be "included" inside
another Term to represent nesting

A Campus Calendar has separate service operations
to allow for the reuse across multiple Academic
Calendars

Holidays and Key Dates do not have states



Milestones (Registration Dates, Key Dates and
Holidays) derive state from the associated Campus
Calendar or Term
Academic Calendar and Terms have two states ::
draft and official
Registration Date Group provides easy access to a
set of well-known Key Dates associated with a Term
KS ENR Functional Area:
Setup (Environment): Registration Environment, Holds
and Exemptions
32
Setup (Environment): Registration Environment, Holds
and Exemptions

Registration Priority
 Establishing registration periods

When are registration “tools” available to student?
• “Tools” include visionary schedule builder



Defined by beginning and ending days
May assign specific periods to specific populations
Multiple periods need to be supported
 Establishing registration windows

Defined by a specific beginning time and ending time on a specific
date


May be done for resource or pedagogical reasons
Enables the assignment of specific students to specific
“appointment” times based on rules
33
Setup (Environment): Registration Environment, Holds
and Exemptions

Schedule validity criteria
 Performed after all changes to student’s schedule have been

processed
Examples include:







Maximum credit hours (do waitlist credits count toward limit)
Course schedule time conflicts/overlaps
Student athlete requirements
International student requirements
Financial aid eligibility
Full-time/part-time status
Travel time between classes
34
Setup (Environment): Registration Environment, Holds
and Exemptions

Understanding Blocks
 The system “blocks” an action based on a real-time evaluation

of a student’s record based on rules associated with the
transaction
Examples include:

The system will block a student from registering for a juniors-only
course if the student is a sophomore

The system will block a student from registering for Calculus II if
the student has not successfully completed Calculus I
 The block will no longer occur if the student’s record is updated
in such a way that the conditions of the block are met, or if the
student receives an exemption
35
Hold Setup Sitemap
36
Hold Setup Prototype
Administrative user will set
up the structure of the hold.
Applying it to students is a
separate feature.
37
Setup (Environment): Registration Environment, Holds
and Exemptions

Managing Hold Inventory
 A hold is associated to a student for a given time period (may be a


date range, or term specific)
Usually originates from another system (housing, health services,
parking, etc.)
May prevent a variety of activities (registration, dropping classes,
adding classes, obtaining a transcript, etc.)

A Bursar hold may prevent registration, the production of an official
transcript, and the issuance of a diploma, but not the production of an
unofficial transcript

An academic integrity hold may prevent the student from dropping
classes, but not the production of any form of transcript
38
Setup (Environment): Registration Environment, Holds
and Exemptions

Managing Hold Inventory
 A central administrator would be responsible for maintaining the

inventory/catalog of holds, who can administer them (placing and
removing), what activities/functions are impacted by the hold,
specific information about the hold, what office to contact about the
hold, etc.
Administration of the placement and removal of holds would be role
and qualifier based.
39
Understanding the Enrollment Environment
Holds and Exemptions

Managing Exemption Inventory
 Persisting, time-based grant of an exception to a given policy which


usually invalidates some form of block
May be initiated by students, instructors, or advisors
Examples include:

Requisite waivers
• Pre-, Co-, and Anti-

Program-based restrictions
• Credential (Baccalaureate, Masters, PhD, MBA, DDS, etc.)
• School, major, minor

Year/Class level restrictions
• Juniors, Year 3 students only

Degree audit requirements
• Course substitutions
• Waiver of requirement
40
Setup (Environment): Registration Environment, Holds
and Exemptions
 Managing Exemption Inventory
 For each type of exemption, define the following





Who can initiate
Time period of exemption
Required data for complete exemption request
Potential outcomes
Qualified workflow

May have specific routing based on organization; the School of
Engineering may have a three-step process including the instructor, the
department chair, and the student affairs dean, while the School of Fine
Arts may only require the approval of the instructor
41
Registration Setup Services

Hold


The Hold Service answers the question, "Is this person on hold?"
The Hold Service manages various Holds on a Person
 Financial hold for student registration
 Medical hold for student registration


Holds may be "hard" or "soft"
Exemption



The Exemption Service defines exceptions to rules and restrictions
used throughout Kuali Student
Exemptions are always granted to People
The exemption process begins with an Exemption Request
 Student couldn’t do something, such as register for a course

Exemptions are valid based on effective dates or number of
time(s) they can be used
Hold Service (WIP)
Exemption Service (WIP)
Population Sandbox
Processes Sandbox

Process Service
 Surface control points to an admin per process
 Interconnecting semantics around what is being checked



directly with the concept such as Holds
Set of ordered instructions, applied to a population, and the
specification of what to do if the check fails
Check also gives us a place to align/apply an Exemption, if the
check can be exempted
NEXT STEPS :: Figure out boundaries with Rules (KRMS)
Next Steps
 Module 2:: Follow-up



Date: November 2, 2011
Time: 12pm – 2pm ET | 9am – 11am PT
Post questions/issues: KS ENR Training, Module 2:: Questions/Issues
 Module 2:: Evaluation

Please complete short survey::KS ENR Training, Module 2 Evaluation
 Module 3:: Understanding Course and Course Offerings



Date: November 30, 2011
Time: 12pm – 4pm ET | 9am – 1pm PT
Functional Areas
3. Course Offering
4. Course Registration
5. Course Assessment
47