Employee Forms Framework
Chris Malek designed and implemented a PeopleSoft bolt-on for National University called the Employee Forms Framework (EEFF). The EEFF is a flexible system that allows for employee submittal, routing, approvals, notifications and auditing of forms. The EEFF is completely setup driven and allows for different departments to create new forms within the framework without any intervention from the IT department. This EEFF bolt-on was developed using several lessons’ learned from other electronic forms implemented for various clients.
Project Goals
When you port paper processes to the electronic world, there are two high level problems that are generally being solved.
- The ability to track approval history and to easily figure out the “pipeline” of forms in queue. The end user who submitted the form generally only cares about the following questions:
- “What is the current status of my form and who is it waiting on?”
- The administrators of the forms generally need to look at historical forms and also find forms that are out for approval that they may need to be aware of. This could be time sensitive forms that are pending a manager approval who is on vacation or forms that are “stuck” in someones queue for too long.
- The ability to electronically capture data and get better data up front. In the paper world there is no way to enforce certain fields are filled out properly before the person sends it up the approval chain which can cause delays. In the electronic process you can enforce certain fields are filled out properly or with “better” data.
Having successfully implemented several workflow/electronic approval bolt-ons within PeopleSoft, we have found that 90% of the pain points that are solved come from number 1 above. Once you have an electronic system where forms can be instantly re-routed back to the originator for modification, corrections, and additional information it actually makes number 2 from above less of an issue.
This fact heavily influenced the design of the EEFF. We spent most of our technical design and coding efforts making sure the routing functionality is flexible and easy to understand. We did not spend a large amount of time making the framework handle the enforcement of proper data. (There will be more discussion on this later.)
High Level Functionality Goals and Assumptions
The following is a high level breakdown of the functionality goals of the EEFF.
- Forms can be created or changed with setup table data entry. No IT coding will be required to do the following:
- Create, change, deactivate forms
- Change the text on forms
- Maintain the number and types of fields on the form
- Control of routing and different types of users on the form level.
- Setup and maintain emails that go to different users throughout the life cycle of a form.
- Forms should have data security so that one employee cannot see another employee’s forms.
- The forms framework should be flexible and allow for text formatting in HTML and different questions and response types like numbers, text, dates, etc.
- Forms should have a routing mechanism where an employee can submit a form and submit it to HR, their manager, or another employee. There should be an audit trail of who touched each form and what they did on the form and their comments.
- Approvers should get an automated email when forms are routed for their approval.
- The employee should get an email when the form is closed.
- Routing should be flexible and not hard-coded as some business processes can evolve over time.
- Some forms may need to include the employee’s manager and some should not include the manager until HR has approved the form.
- Some forms may need approvers outside of the HR department and some forms may also not really be HR forms at all (more on this later).
- The forms to be automated by this framework are assumed to be rather simplistic and not have any if/then logic or complex routing requirements which would require that IT get involved for new forms or maintenance of the logic as the business changes.
- It is assumed that an HR (or other department) person (aka Form Owner/Administrator) will serve as the “policy police” to make sure that all forms have the required information and the proper approvals where attained. The system will not be coded to force this routing and approvals. It will be up to Form Administrator to manage the policy and usage. This “human centric” routing will keep the system flexible and adaptable to change.
- Other departments outside of the form’s department owner may serve key roles in the processing of certain forms.
- Not all forms will be based on employee data. Therefore, EMPLID should be optional.
- Employees should be able to easily submit forms without any training or process guide/cheat sheet. The user interface design should be simple and resemble other self-service pages and follow general “web” guidelines.
- Employees and managers should be able to check the status of forms easily and view who it is pending and view historical forms.
- Functional Leads should be able to easily and quickly create, change and remove forms without contacting IT. All aspects of form maintenance and up keep will be maintained and owned by Functional Leads.
- Functional Lead should be able to control routing and move along “stuck” forms in anyone’s queue.