eServices Provisioning SC

eServices Provisioning

All requests for assistance are completed using the Tracker Customer Portal

• eServices provisioning begins with an Identity Management layer, parts of which are automated and parts of which are not. All persons who receive eServices must first have a record in the Banner database (Oracle). Since Banner is at heart a Student Information System, students are a natively identified constituency based on a variety of status indicators. Alumni are a subset of Student with a different set of eServices provided. State employees are imported into Banner programmatically, and indicators present in their records are used to identify them regarding creation of eServices. Other constituencies are employees of non-state campus agencies, guests and EC English. These individuals are put into Banner either individually or through load files.
• eServices provisioning is in two parts. 1) The identity management part determines who is eligible for eServices; 2) the act of provisioning takes place by determining when those services should be provided. Each constituency has its own sets of rules that prompt the creation of eServices for members of that constituency.

eServices provisioning is a basic service provided to all regular constituencies on campus as identified in the overview.

eServices may include the following: Active Directory membership, Google Apps membership (which includes email), network logon, WiFi logon, FredCard, Door Access. 

There are a number of downstream services for whom eServices provisioning is a necessary prerequisite, and these services provide their own sets of services. For example, our LMS, Maintimizer, FSA’s myFredCard and many other applications depend on membership in AD for authentication. AD itself is a root service which is populated primarily by the eServices provisioning program in Oracle. FSA’s IDMS (Identity Management System) is the generator of FredCards and that is likewise primarily populated from eServices provisioning. ProWatch, the door access system, is populated from FSA’s IDMS when the eServices application inserts records to the FSA IDCard table.

There are a number of packages, procedures and tables that support eServices provisioning within Oracle itself. The heart of it, though not the whole of it, is in frd_Services package.

No fees

For guest or Campus Community (campus employees other than state employees) requests for eServices are made via FredQuest. For students and state employees, no special requests need to be made as they are provisioned programmatically based on status and timing.

Typically, requests for access are worked on during normal business hours. FredCards and door access can be available immediately after data entry into Banner. A daily process at noon creates load files for Active Directory.

How does a user request assistance for the service? Via FredQuest.

Who can ask for certain aspects of assistance?

• Anyone using eServices and having difficulty may request assistance and review
• Any sponsor of guests may do the same
• Responsible persons in non-state campus agencies for their staff

The ITS Service Center handles all typical user issues with eServices. They should only pass on a ticket to the FredQuest eServices team (a cross-ITS team group consisting of persons from Enterprise Infrastructure Services and Enterprise Reporting and Development Services) when the issue is technical beyond their ability to analyze and address.

All requests for assistance are completed using Tracker Customer Portal

Users should request access for guests or incoming employees 2 weeks prior to the time when they will be on campus and need to have services available.

Who is responsible, accountable, consulted and informed for each function of your service?

Function 1

Name: Identity Management

Description:

Function 2

Name: Provisioning

Description:

Function 3

Name: End User Support

Description: