UC Web New Hire Application

Introduction  (For roadmap to web entry/update screens, click here

The Web EDB Update project has been sponsored by six campuses and Office of the President. Participating campuses include Davis, Los Angeles, Riverside, San Diego, Santa Barbara, and Irvine. This is a Proof of Concept project with the initial phase limited to New Hire processing, with the intent that the system will be expanded to include other EDB update processes following the successful implementation.

Management and Requirements Groups were created with members representing Business & Financial Services; Controllers; Payroll; Human Resources, Academic Personnel; Information Technology; and academic departments and deans' offices. With guidance from the Management Group, the Requirements Group undertook the task of gathering input from all constituencies and defining detailed requirements for a Web EDB Update system for New Hires. Meetings were held at each of the six campuses with representatives from academic departments, deans' offices, Human Resources, Academic Personnel, Payroll, Information Technology services, and central administrative departments.


In 1994, the University of California implemented a distributed online EDB update system. The online system was a significant improvement over the paper forms that departments had needed to process to effect changes to employee records and it allowed campus department users to enter employment data directly into the EDB, thereby eliminating many delays associated with paper processing. The Online EDB Update system was modern for its time and introduced and relied upon a post-authorization model of approvals, a revolutionary concept when implemented. Since 1994 the EDB Update system has undergone many changes and improvements, primarily to improve system performance and to add new data elements to meet changing regulations and requirements. And while the system continues to function well, little has been done to modernize the appearance or the ways in which users interface with the system. As technology advances, the mainframe system seems more awkward and less intuitive, especially to new and younger users who are very familiar with web systems.

Although campuses have had the opportunity to customize portions of PPS (Payroll Personnel System) of which EDB is a part, virtually all EDB update screens are consistent across campuses with the exception of the fields which make up the FAU or Full Accounting Unit and the campus-specific banner information. EDB provides the ability to “bundle” various screens together to lead a user through entry of required data for a particular type of action. For example, a campus may have bundles for Staff New Hires, Academic New Hires, Separations, Reclassifications, etc.. Campuses can create their own bundles to reflect their specific campus preferences.

Campus Input

A critical part of any successful system development project is gathering user input. User input defines the audience who will use the system and describes their views of the existing system and their expectations for a new system. User input guides the system design, prevents missteps, and is invaluable if the new system is to be accepted by the population for which it is developed. Three primary methods were used to gather input from users for this project:

Campus Questionnaire – More than 700 users from six campuses responded to the questionnaire—representing approximately a 15-20% response rate of surveyed users. In addition to identifying issues and desired features, the campus questionnaire helped define our user population which is largely experienced and well-trained. It also told us how long it normally takes to process transactions and defined the most common issues with the current system. Users also provided many suggestions for new features and improvements.

Recurring Themes
63% see problems with edits, either unclear or not enough
51% believe that help is inadequate
39% have difficulty knowing what to enter
26% cited problems with system navigation

Campus User Group Meetings – User group meeting were held at each of the six campuses with work groups including between 12 and 40 participants. The discussions at the workgroups confirmed the results of the questionnaire. Users felt that there was a great opportunity to improve processing of New Hire transactions with a Web EDB update system. Specifically, users asked for improved edits and navigation, more intuitive screens, and better help. They also asked that the system be able to automatically provide some data based on criteria such as title code. Many of their suggestions are reflected in this Requirements Document.

Requirements Group Meetings – All six campuses and Office of the President have representatives participating on the Requirements Workgroup which is made up of systemwide and campus experts who understand the details of how the update process currently works as well as its strengths and weaknesses. The group meets on a regular basis to review features, work through issues, and recommend overall system design.

Project Description

Developing a Web EDB Update front end to the mainframe EDB system provides the opportunity to modernize and enhance the view or interface between users and the system by developing a new look while leveraging the existing technically-complex EDB mainframe system.  The development team plans to take a Service Oriented Architecture (SOA) approach to this project; creating a number of web services on the mainframe system that will expose the existing PPS architecture to the web. The goal is to leave existing system logic as is, and to create an external web application that will use the web services pass information to and receive information from PPS.

System Requirements

Smart Processing” – The Web EDB system is able to handle certain fields automatically based on specific entered data. For example, the citizenship code controls many aspects of a New Hire and the system makes decisions about which fields are presented to the user based on the entered citizenship code. 

Navigation – Navigation through the system is accomplished by accessing fields through tabs. This navigation process has improved upon the existing system, which only allows users to progress sequentially through the application via PF keys on the keyboard. Additionally, the system automatically navigates to fields identified in edit messages.

Display – Required fields have visual distinctions. Edits are displayed in an effective way.

Saving of Partially Completed Transactions – For most users it takes between 15 and 30 minutes to process a New Hire transaction, and because users experience frequent interruptions, it is often difficult to complete transactions. Web EDB allows partially completed transactions to be suspended and completed at a later time. Transactions must be saved for a period of:

  • 36 hours during the normal workweek
  • 60 hours during a workweek that contains a holiday
  • 84 hours if any of the 36 hour period occurs on a weekend, and
  • 108 hours if a weekend and a holiday are included.

The count of how many hours to save the transaction begins when the transaction is originally suspended. If a user later accesses the transaction and suspends it again the count does not restart. Only the user who initiated the transaction is able to access and complete the suspended transaction. When a New Hire transaction is suspended, the original employee number assigned at the beginning of the transaction will be cancelled and a different employee number will be assigned once the transaction is resumed.

Copy/Template Capability – Users are able to create a list of favorites or templates for fields such as department address information and appointment/distribution and FAU information.

Security Access and Authorizations - Web EDB update uses the same security access controls and authorizations as are currently employed by the mainframe EDB update system. The system interfaces with or accepts logon/password authorization or authentication from existing campus systems and will allow for multiple sources of authorization identification information.

User Guidance - Help function is extensive but not intrusive, and uses a layered approach so that users can access only the amount of information they need to accurately enter transactions. The first level of help is the drop down menu from which users can select appropriate values. Drop down menus contain understandable translations rather than the actual codes that are stored in the system. It is assumed that the existing mainframe help function and data element tables will be employed to provide the much of the drop down menu data. The system will also need to provide links to campus manuals and training materials and allows for campus-specific links. 

Edits – Web EDB update system interfaces with the current mainframe EDB, all existing online mainframe edits are applied to transactions being entered through Web EDB. Although the appearance and presentation of the existing edits may differ between Web EDB and mainframe screens, the actual edits and severity levels are the same. Additional edits are also defined and will be applied only in the Web EDB system. 

System Performance – Because of obvious technology differences and factors affecting system performance, it is difficult to set meaningful standards for transaction processing times. However, we think it will take less time to process transactions in Web EDB than it currently takes in the mainframe system, given the additional help features, automatic filling of data, templates and favorites, and more informative edits.

Organization of Fields – Field layout is designed with the specific goal of making input of data easier and more logical. There is no requirement to consider or be consistent with current grouping of fields on mainframe screens.

Print Capability – The current mainframe systems allows for printing only on networked printers that have been defined to the system. This oftentimes makes it difficult for users to print various documents. Web EDB provides printing capability so that users can print directly from their web browser, eliminating the need to configure network printers for the application.

Entry of Data – While many users prefer to select translations from drop down menus, other “power users” prefer to enter codes. The system allows for either selection from drop down menus or entry of codes. Fields are a combination of drop down menus and data entry fields. In the case of drop down menus—especially for long lists--the system provides predictive selection so that a user can begin entering data and the system will select the appropriate entry from the list or take the user to that place in the list.

Applicability of Design Decisions to Future Developments - Although the EDB update project will be completed in phases, design decisions are consistent with future development efforts. For example, while Phase I of the project addresses only New Hire processing, system architecture and design apply to other types of actions such as Change and Separation processing as well. This approach ensures that system design will easily be applied to all subsequent phases of development.

Review of Entered Data – A review page is provided to allow review BY THE PREPARER of all entered data before update. A confirmation page is also provided to document all entered data.

More Information

General Campus Information

University of California, Riverside
900 University Ave.
Riverside, CA 92521
Tel: (951) 827-1012

Career OpportunitiesUCR Libraries
Campus StatusDirections to UCR

Accounting Office

Physical Address:
14350 Meridian Parkway, Riverside, CA 92518
Visitors to the IntelliCenter must be registered in advance

Mailing Address:
UC Riverside, Accounting Office-002
Riverside, CA 92521

Office Hours:
Mon-Fri (8:00 am - 5:00 pm)
Sat-Sun (Closed)

Tel: (951) 827-3303
Fax: (951) 827-3314
Contact Us