Oracle Administrative Systems Access

Users log on to the Oracle Administrative System using a BlazerID and strong password, but what a user is able to access within Oracle is based on their Responsibilities.  "Responsibility" is the term used to identify the sets of web pages, menu options, forms, data, and reports that users can use within the system.  Some responsibilities are set up automatically for the users based on certain criteria, and other responsibilities must be set up with the Access Control Form (ACF).

In addition to access responsibilities, employees may be assigned certain “roles” within Oracle so that they may view and/or update data, and receive notifications and reports.  Click here for information about the roles assigned in the Oracle Administrative Systems.

BlazerID and Strong Password

Anyone needing access to Oracle must have their own BlazerID and a strong password. First the individual must be appointed in Oracle HR via an ACT document as an employee to become eligible for a BlazerID. After the ACT hire document has reached the complete status, an overnight process adds the individual to the UAB Electronic Phonebook, which is used to validate requests for BlazerIDs.

If the individual does not have a BlazerID, they can easily obtain one by accessing http://www.uab.edu/blazerid. System users are not permitted to share their BlazerIDs with other people, so they must sign up for their own. They will also create a strong password, which consists of a combination of letters and numbers from 8 to 16 characters long. Learn more about a Strong Password by accessing the UAB Electronic Phonebook.

After entering the BlazerID and Password, users must accept the "Signon Agreement" to gain access to the system. The "Signon Agreement" references the Oracle Access Agreements for Employees.

Responsibilities

Users log on to the system using a BlazerID and strong password, but what a user is able to access within Oracle is based on their Responsibilities. "Responsibility" is the term used to identify the sets of web pages, menus, forms, data and reports that users can use within the system.  Below is a list of end user responsibilities.  Click the responsibility name to get a description of the responsibility and the menu options available for that responsibility.

How does an individual get access responsibilities?

To be eligible for access to Oracle, an individual must be appointed via an ACT document as a Person Type of Employee.  Responsibilities are set up in one of two ways:  by default and by an approval process.

Default responsibilities -- The term “default” responsibilities refers to responsibilities that are set up systematically (automatically) for a user based on certain criteria.   After an employee has obtained a Blazer ID, a process is run granting access based on the criteria shown below in the Eligibility column.  Below is a table listing the responsibilities set up by default.   

Approved Responsibilities - Responsibilities that are not assigned by default must be requested via the Access Control Form, and the request is routed through workflow for approval.  Below is a table listing the end user HR and Finance approved responsibilities. 

Does everyone with a specific responsibility see the same data?

The type of access for a responsibility is “restricted” or “open”.   If the responsibility has restricted access, the user is limited in what forms and data they can view or update.  If the responsibility has open access, all users with the responsibility have access to all forms, data and ad hoc reports associated with that responsibility.

Responsibilities that are restricted limit access based on one of three criteria:  individual, HR org or GL org range.

Individual – responsibility limits access to the user’s (individual’s) personal data.  Responsibilities that are “restricted by individual” are:  UAB Self Service Applications, UAB Self Service Views, UAB TEL, UAB Effort Report User

HR Org – responsibility limits access to designated HR organization hierarchy.  Responsibilities that are “restricted by HR org(s)” are:  UAB HR Officer, UAB Timekeeper, UAB Salary Reclass, UAB ACT Input.

GL Org Range -- responsibility limits access to designated GL organization ranges.  Responsibilities that are “restricted by GL org range(s)” are: UAB GL End User, UAB Budget Model User.

Open access means the user has access to all forms, data and ad hoc reports associated with that responsibility.  The responsibilities with open access are:  UAB AP End User, UAB FN Document Entry/Approval, UAB GA End User, UAB Requisition Input, and UAB Sunflower Custom Reports.

How or when are responsibilities terminated?

Responsibilities are end dated (terminated) in one of two ways:  (1) systematically or (2) through the approval process.

1. Responsibilities are end dated systematically when:
   1. an ACT Termination document is Complete, or
   2. an employee's transfer document is Complete, or
   3. an ACT Leave document for biweekly-paid employees is Complete.
      1. When an employee’s ACT Termination document reaches Complete status, all responsibilities are systematically end dated effective the date of the ACT Termination document.   Note:  UAB Self Service Views is systematically assigned to an individual when the ACT Termination document reaches Complete status.
         

      2. When an ACT “transfer” document reaches Complete status, all approved responsibilities are systematically end dated effective the date of the ACT document.  The ACT transfer document must have document reasons of Transfer Lateral/Different Department or Transfer with Promotion and a change in org.

      3. When a biweekly-paid employee’s ACT Leave document reaches Complete status, all responsibilities except UAB Self Service Applications are systematically end dated effective the date of the ACT Leave document.
               --Default responsibilities are systematically reinstated when employee’s status returns to “Active”
               --Approved responsibilities must be requested after employee’s status returns to “Active”

2. The approved responsibilities may be end dated via the Access Control Form, and the request is routed through workflow, with the final approval(s) being made at the appropriate School, Hospital or VP level.