Opportunity Evaluation of an Electronic Forms-Routing System

Andy Oakland

March 25, 1992

Background

An electronic forms-routing system could serve many purposes within the MIT environment. As a replacement or supplement for existing administrative paperwork, it could reduce paper flow and redundant data entry, and speed up the processing of forms. Within the software and support communities, it could be used by computing support groups to track user’s requests, and by developers to manage bug reports.

A forms routing system is something like a railroad. Forms move through the system just as trains move along railroad tracks. When a form comes to the attention of a user, he or she can do something to the form and then select another user to send it to—just as the dispatcher at a station can shunt an incoming train along a variety of outgoing tracks leading to different stations.

Penn State’s IBIS and EASY^{1} systems have been able to automate all of their student services, such as admissions and registration, and many of the business systems, including some financial and all personnel actions.^{2} However, Penn State relies on an integrated database for all departments–far from the present situation at MIT. Given the lack of such a database here, it is currently impossible to implement as comprehensive a system as EASY. Even so, an electronic forms-routing system can act here as an adjunct to the existing information systems, and still be of significant value. In this paper, we present some first thoughts on the design of such a proposed forms-routing system for use at MIT.

General Description

A form in the system would appear on the user’s screen as a depiction of a paper form.

Although the form will be functionally equivalent to any existing paper form, it’s not guaranteed that it will look exactly the same, as some features of a paper form may not have an exact electronic equivalent.

The form will have text fields to be filled in, some of which may be constrained to be of a certain format (eg, dates; dollars and cents) and some of which would be free-form text. Other types of input fields, such as checkboxes and multiple-choice selections, may also appear. Eventually, an electronic form may include types of input which have no paper equivalent, such as pop-up menus and nested sub-forms.

Each type of form will have a unique route associated with it, which will consist of a collection of stops and a listing of which stops are connected to which other stops. In the railroad metaphor, a stop corresponds to a station, and the connections between the stations represent the tracks. The route for a form is the collection of all the possible “tracks” on which this type of form can travel. Because the route may have forks in it, the paths taken by individual forms of the same type may differ.

At each stop, a person or group of people will be assigned ownership of the form, and be responsible for ensuring that appropriate action is taken at this point and the form forwarded to the next stop. As long as the form is at this stop, these people are said to “own” the form.

For example, an auditing program could generate forms containing a list of calls made from each office phone, and assign each form to the owner of the phone. The program itself would own the forms at the first stop on the route, and moving the forms to the second stop would assign the forms to the phones’ owners.

The phone’s owner would mark off his personal long-distance calls, and send the form on to the third stop on its route. The person responsible for the third stop would likely be the administrative officer for this person’s department, who would be responsible for collecting the necessary funds and archiving or deleting the form once this was completed.

1“Integrated Business Information System” and “Electronic Approval System”

2“Presentation to Board of Trustees”, July 25, 1991, Edie Bender

Certain fields could only be filled out during a certain stop. In the example above, marking calls as “personal” or “business” could only be done when the form was at the second stop...Neither the auditing program nor the administrative officer would be allowed to edit these fields when the form was at “their” stop. In addition, fields may appear and disappear as the form moves along its route, if they are appropriate only at certain stops. This would be the electronic equivalent of the “For Office Use Only” section often seen on paper forms.

Expected features

The following items are the main features we expect of an electronic forms routing package.

• The system should be accessable from a variety of machines, including but not limited to, Athena workstations, Macintoshes, and eventually DOS machines. Furthermore, it should be possible to use the system from machines which are not directly on the Athena network, via telnet or dialup. This requires that the system must be able to work with simple character-based displays, such as the vt100, as well as on more sophisticated graphic displays.

• It should be possible, at any time, to print out a paper version of the form.

• The system must be secure. At the simplest level, this means that unauthorized people must not be able to corrupt existing forms or read forms they should not be able to access. Beyond that, if the electronic forms are ever to be able to replace paper forms, the system’s records must be made nonrepudiable...i.e., if the system shows that someone made a particular change, it’s guaranteed that he actually did it. Only the simplest level is likely to be implemented for the first version of the system.

• The system should maintain a modification history for each form. At a minimum, it should record the identity of anyone who enters values onto the form or moves it along its route. It may also be desirable to maintain histories of the values of individual fields within the form, along with the identities of the person who entered or changed the value.

• At any given stop, the current owner may have several alternatives for forwarding the form. Sending it to the next stop will always be an option, unless the form is already at a final stop on its route. Other options, such as returning it to the sender, referring it to someone else, or terminating it, will be available if appropriate.

• Tools will be available to allow non-programmers to design forms and their routings, and to enter them into the forms database.

• Fields on a form will be somewhat intelligent. They will recognize what sort of data they should contain^{3} and will provide default values where appropriate. In the first implementation, these will be hard-coded for each field. In later versions, the defaults may dynamically adjust depending on the values of other fields in the form, as well as the contents of the underlying database.

Furthermore, various attributes of each field, such as its visibility, whether a value for the field is required, and whether the user can change its value, will change depending on the values of other fields or the current status of the form as a whole. For example, a section asking for MIT office number might only appear if the originator checked a box indicating that she was an MIT employee.

3At a minimum, data types like text, numeric, and multiple choice will be supported. Formatted input, such as phone number templates, may be added later.

• It will be possible for a system outside the router to interact with the routing system. For example, if the router were to pass completed forms to the personnel database as the last step in their routing, it should be possible for personnel to tell the router that the forms are safely archived and can now be deleted from the router’s database.

Open Issues

• Must routes end with the form leaving the system? Some useful applications, such as a bug-tracking system, can run entirely within the forms system, and will not require an external department database to hand off to. However, giving users the ability to write indefinitely into the forms-router database can cause space problems, and forces the router to act as a custodian of their data. This is similar to what would happen if users could expect the post office servers to store their mail for them, instead of being required to incorporate it into their own directories.

• Should there be a single database for the entire form system, or should individual projects have their own databases? Maintaining a single database simplifies the construction of the routing server, but seperate databases will make it easier for individual projects to maintain their own databases.

• Should we allow administrative users to specify arbitrary commands to be executed as forms enter and leave various states? For example, this will allow people to get automatic notification of new forms as they arrive, or for the date any form enters a given state to be logged in a global file. However, there’s no way to write arbitrary commands which will run on all systems, and it introduces a gaping security hole. Furthermore, users may interpret any failed commands as bugs in the router, even through the router was only executing a command specified by the person who designed the form. Providing a library for common requests, such as email or zephyr, will suffice for many cases, but not all.

• At what point will the user-supplied values be checked for validity? Some simple validation can be done as the values are input, but full sanity checking of fields may have to wait until after the form exits the routing system. Expecting the router to interact with many different databases in order to confirm the validity of new data will probably be unrealistic. However, users will expect some level of dynamic checking and validation of fields, and providing this will provide a great incentive to use the electronic rather than paper forms.

Interface for the typical user

The typical user will interact with the system via a single client designed to make it as simple as possible to perform the most common tasks. This client will be accessible as widely as possible. We currently plan to put it on at least Athena workstations and Macintoshes, with a curses-based version available for dialup and telnet purposes.

Using this client, the user can:

• Select from a variety of blank forms, and fill a new form in. Simple data verification will be run on the entries (required/optional, correct data type for each field, etc.)

• Display existing forms which he is allowed access to.

• Manipulate values on a selected existing form, provided this user has authority to do so for those specific fields at the form’s current stop.

• Select the next stop and owner for a form he currently owns.

• Query the forms database for at least:

– A list of existing forms with a particular owner.

– A list of existing forms of a particular status.

– A list of existing forms which he has originated or modified.

– The current status of a specified existing form.

– The routing and modification history of a specified existing form.

Administrative Tools

In addition to the main client, a collection of administrative tools will eventually be supplied. These will include tools for:

• Defining new form templates. Modifying existing ones may not be possible, due to the problem of what would happen to forms using the old template already travelling in the database.

• Defining or editting the routing for a new or existing form.

• Running canned database queries, to list all those requests of a specific type and with a due-date in the next month, all the forms in a certain state, and so on. In addition, it would be useful to run arbitrary database queries in a standard query language, although security problems may preclude allowing this.

• Manually editting fields on a form without any sort of constraint checking, and forcibly moving forms to arbitrary stops on their route.

System Architecture

We expect that the system will consist of a centralized server, to maintain the database and control access to the forms; and a client for each supported platform, which would present the forms on the user’s screen and provide the means for the user to edit the forms. Users not on supported platforms would access the system via telnet to a client which uses a character-based interface.

A command-line or other non-graphical interface should also be supplied, so that shell scripts and other programs can interact with the router.

Administrative clients for relatively infrequent tasks such as designing new forms will eventually be added. However, we expect that these tasks will be done manually with ad-hoc tools in the early phases of the system.

Automatic Routing of Forms

Forms will often “know” where to go when they have been completed. While it’s impossible to imbed the entire structure of MIT responsibilities within an application, the router would be able to make informed guesses. In the Penn State EASY system, this is done with pre-defined tables.^{4} At MIT, the definition of a form could contain a list of people or groups responsible for this type of form at each stop. Thus, after a user completed a form of type “IP address request,” the router could assign it to the person or group designated as being responsible for this type of form at the next stop.

4“Presentation to Board of Trustees”, July 25, 1991, Edie Bender

However, this name would appear only as the default value for the “Assign to:” field of the form, and could be overridden by the person filling out the form.

Whether such a user specified name is valid cannot be checked by the router. For many important forms, the ACLs are based on data and rules which this system will be unable to cope with, such as “This form must be signed by your manager, AO, or PO.”

Support for Administrative Systems

At the present time, many MIT administrative systems are based on an old, centralized, model of computing. Updating of the databases is done either as a batch process (reading in a tape from another system) or manually (keying in data from paper).

We would like to move toward systems which are more interactive. Providing end-users the ability to interact in real time with the system would be tremendously useful...For example, after you entered a request into the system, you would be able to query the system for the status of your request whenever you liked. Also, by eliminating the slowness of routing physical pieces of paper though campus mail, users will be able to get their work done more quickly. The existing EREQ system is a good example of this.

One way of doing this is to build it into the design of each new system, as departments replace their existing ones in the natural course of business. Unfortunately, since most departments have systems completely incompatible with an interactive transaction-based approach, and have so much already invested in their current information systems that replacement of them would take perhaps fifteen years, this doesn’t seem feasible.

One factor in resistance to interactive systems is the possible security threat posed by having administrative databases accessable over the net. Reviewing bug reports doesn’t require a high level of security, and the consequences of an unauthorized person moving them through the network would be minimal. However, when the system is used for more critical information, such as voucher approval, it is necessary to incorporate some form of “digital signature” and table of authorized users to ensure that only the appropriate people interact with the database. Furthermore, it is important to be able to track the path of a form through the system, and determine with certainty who did what, and when.

Athena-created services such as Kerberos, and the ongoing work on privacy-enhanced email, should provide mechanisms for supporting whatever level of security is required. We believe that this electronic form system will be able to supplement the existing administrative systems, and that it will provide an effective migration path towards more interactive systems.

Applications Existing Entirely Within the Router

It would also be possible to build some applications which have no existance other than as a collection of forms in the system.

For example, the Help Desk needs to be able to track and report on three types of requests, namely problem/trouble reports, network installations, and IP address assignments.^{5} A collection of forms and routes within the electronic forms-routing system would suit their needs perfectly. Note that this is a case where there would be no outside database for the routing system to interact with...The entire application would be defined within the system.

5“Help Desk Database”, April 12, 1991, Joanne Costello

Bug reports for Athena software are currently kept in the memory of the programmer, in flat files, or, in exceptionally organized cases, in discuss meetings. There is no mechanism for filing bug reports, running queries to see what bugs have been reported, or for ensuring that bugs aren’t forgotten about. Again, a set of forms for reporting bugs could be arranged within the forms-routing system.

Further expansion

An obvious limitation of this system is that it cannot route physical objects such as receipts. In addition, there are more complex electronic objects which should be considered for inclusion in the system, such as voice mail and scanned images.

It must be possible to spawn child forms from an original form, though this may not be implemented in the first version. For example, it’s likely that a request for a network drop will be split into several different forms, one for each subtask required.

It would be worthwhile to ensure that the system can interact with email and other forms of electronic communication. For example, mail sent to a specific mailing list could be examined, and if it fit a predefined format, would be used to fill in (at least partially) a form of a specific type. The form would them be assigned to the designated screener for the mailing list for further work. The system should also be able to initiate communications...sending zephyrgrams when a new form arrives is one example, as is sending reminder mail when a critical form has been untouched for a certain time.

Conclusion

Constructing an integrated administrative system such as Penn State’s ISBS is not currently possible at MIT, due to the fragmentation of administrative information and databases. But although we cannot immediately eliminate all administrative paperwork, we can provide a forms-routing system with sufficient generality that it can serve as a path towards this ultimate goal, while being a tool of significant and immediate use in other areas of the university.

The next step in this project is to identify some potential users of the package and find out what they expect from an electronic forms system. This work has already been begun. We plan to use their expectations and requirements, research into similar systems, and our own beliefs as to what will make the system most generally usable, to chart the further design of the system.