Class Scheduling: Exceptions? What Exceptions? T2.2 February 5, 2013

Overview This session will cover the process the University of Arkansas uses to manage class scheduling and room assignments, and the workflow developed within our student information system (ISIS) to submit and process these requests.

Presenters: Lisa Kulczak Associate Registrar, Curriculum Nancy L. Umphres Business Analyst, Student Records

State’s flagship campus Public 4-yr & professional “Very high” research university Enrollment (Fall 2012): 24,537 students

Purpose With record growth in enrollment and classroom space at a premium, the University of Arkansas recently implemented a new policy requiring that all classes be scheduled within officially established class times. Exceptions to these times must be submitted by term, and must be approved prior to the class being scheduled. It quickly became apparent that an automated process was necessary to efficiently handle the volume of exception requests.

Background  In legacy system, room assignments rolled from term to term  With move to ISIS, needed an automated way to roll room assignments  Decision to purchase R25 software during fit/gap phase of ISIS implementation ( )

 R25 goes live for first batch room scheduling in 2005  Batch room assignment process is voluntary at this point; College of Arts and Sciences is first to participate  R25 scheduling reduces a 6 week manual assignment process to less than 1 week for Arts and Sciences alone

Setting the Stage  Record growth in attendance over the last 2 years, with continued growth predicted—14.6 % increase in enrollment since Fall 2010  Major renovation projects ongoing—over 40 separate construction projects across campus resulting in multiple campus buildings being “offline”  Re-evaluation of classroom capacities conducted by Fire Marshall resulting in a loss of classroom seats across campus

The Facts  Currently, 29 buildings on campus with classroom space  144 rooms defined as general access classrooms; 451 rooms defined as special purpose rooms  Typically, anywhere between 6, ,000 class sections scheduled per term  Of those, 2, 000 – 4, 000 sections require room assignments

The Policy  Creation of Centralized Room Scheduling Unit coincides with directive that all general access classroom space will be assigned via batch scheduling process (Fall 2010)  All colleges must participate; first term for campus-wide batch scheduling is Spring 2011  Emphasis on effective room utilization  Revision to Official Class Times Policy to facilitate scheduling

Academic Policy Series

 Official Class Times Exception form and procedure implemented along with policy  Approximately 100 Official Class Times Exception forms processed for a given term

Processing Exception Forms  Interactive PDF on Office of the Registrar’s website

 Required approvals—dean’s office and Registrar’s Office (impacts on general access classroom scheduling noted by Room Scheduling Coordinator)  Forms archived as they complete approval process  Data for all exception requests submitted entered on spreadsheet by year and term

 notifications to submitter, appropriate dean’s office, Curriculum and Room Scheduling Unit personnel  Net result—too labor intensive to continue as manual process!

Specifications for Class Time Exception Policy Requests Background Need ability to allow any academic user, other than student, to request an exception to a class meeting pattern time either before or after a class has been scheduled. User must be able to add a request, another user must be able to approve the request, and the Registrar’s Office must be able to give final approval. Main Features of Project Using delivered PeopleSoft workflow process and security, develop workflow which includes new request page and approval process. Using Official Class Times Exception Request Form (previous slide) as a template, recreate editable fields for purposes of the request. Security must allow for any user to request an exception. However, in the workflow of approvals, the appropriate dean’s office approver will need to be determined by the SUBJ/ACAD_ORG security. CLASS_TBL Class Table CLASS_MTG_PAT Class Meeting Pattern Table

User Process 1.User may search on criteria of Term, Subject, Catalog Number, Class Number, Section Number and Meeting Pattern.

2.User may elect to Add a New Value, with Term, Subject, Catalog Number, Class Number, Section Number and Meeting Pattern Number.

3. Values brought in from the Class Table which assumes class has been scheduled and values  If class has not yet been scheduled, user will need to supply all criteria  Meeting pattern number will be important in training because inaccurate or blank values may cause data to not be presented as expected and lead to an error in the request.

4. User will be able to indicate with radio buttons if new section or new meeting pattern is being requested. Once chosen, the request form because visible.

5. User will be able to add justification in free form text field (which should allow for approx. 150 words).

6. After data and justification entered, user will hit submit button. 7. Data on the page will be grayed out and un-editable to the user (but not the administrator).

8. Submitter, and subsequent approvers and administrator will be able to see approval steps and progress. 9. Submitter will receive an on each step of approval process.

10. Upon submission, an is sent to appropriate deans’ office approver notifying of pending request. 11. Dean’s office approver logs into ISIS, navigates to page and approves/denies request. 12. If denied, request is logged into table and not editable. Submitter is notified.

13. If approved, sent to Registrar’s Office notifying them of pending request.

14. Dean’s office approver and submitter will receive upon Registrar’s Office approval. 15. Final notifications to be sent to Associate Registrar, Curriculum and appropriate college room scheduler.

Assumptions 1.If user makes error in data entry, administrator may access page, allow editing, fix error and save. 2.Security will tie the Subject or Acad Org to the functional security of the appropriate approver. Example, we want a request for an ARCH class to be sent to the ARCH dean’s office approver and not the ENGR dean’s office approver. 3.If request is denied, submitter will need to complete a new request. 4.Entries on UA ClassTimeException table WILL NOT be purged but remain archived indefinitely. 5.The workflow process WILL NOT update the Schedule of Classes programmatically. The update/change will be done manually at the college deans’ office appropriate room scheduler level. 6.Dean’s office approver and Registrar’s Office will be able to approve alternate designee for approval step. 7. Administrator can override to designate alternate designee.

Navigation For Faculty requests (expected to be the originator of majority of requests), access should be given here: Faculty center>MySchedule>SelectTerm tab with a link RequestOfficialClassTimeException. Link will re-direct to the administrative navigation (see below) For Administrative requests, access should be given here: MainMenu>Records&Enrollment>UASRCustomComponent> CurriculumManagement>UAClassTimeExceptioRequest (Requestor/Approver) Security Faculty/staff: SR-AWE-REQ – requestor role SR-AWE-APPR – approver role SR-AWE-ADM – administrator role

Setting Functional Security by Role and Component

Questions?

Lisa Kulczak (479) Nancy L. Umphres (479)