About the Signature Application

Is forms.uoregon.edu the right solution for you?

The Signature Application hosted on forms.uoregon.edu offers improved efficiency, ease of use, security and accessibility for many documents and processes.  Below are some characteristics of documents and processes that are good matches for the Signature Application.  

• Existing paper or fillable PDF documents that must be scanned and emailed for approval
• One or more files (.pdf, .doc, .docx, .xls, .xlsx, .txt, .csv) are needed with the document
• Or, no additional files are needed with the document
• Completed document must be reviewed and approved by supervisor, department manager, or someone in administration
• Once completed, the document proceeds along a forward-moving path; there is no need to revisit the original document to make updates during the process
• The document itself and its information should be accessible only to those invited to view it
• The document’s fields do not directly access or pull information from Banner, IDR/Cognos, Singularity, or Advance
• The document is initiated only when there is a need.  There is no requirement for regularly prompting or repetitive submission of the document
• Document reviewers can access, review and approve the document on a computer, tablet or mobile device
• Any associated files, as well as the document, can be electronically archived

Next Steps

 If you decide to move forward, designing your own Signature Application-enabled online form, the following information and guidelines may help speed the form design process and reduce the chance of unforeseen problems.

Collecting Sensitive or Protected Data

Collect the minimum information needed to perform the business transaction.
Do not collect SSN, bank account or credit card number, or other sensitive information.
Limit student information collected to Directory Information.

Form processing roles

• Form Development Contact - There needs to be at least one person who has overall responsibility for your online form, notifies supervisors or others in administration of the plan to develop an online form, someone who keeps the project moving forward, recruits testers, writes the test plan, and is the central point of contact with the BAO application development team.
• Document Type Admin - An optional Document Type Admin may be given admin rights to the form, enabling them to add/edit content in the instructions, signature block, and add/remove people from the Document Owner list.
• Document Type Owner(s) – While there may be one primary contact and Document Type Admin, others involved with the online form development may also be assigned the role of Document Owner if they need to monitor submissions or transactions, or utilize the custom report and/or .xls download.
• Form Originators – these can be students, faculty or staff who access the forms.uoregon.edu website using their DuckID.  In the future, the Signature Application may also permit those without DuckIDs to initiate forms.
• Signers/Reviewers – if your form will route to others for online approval, these signers and reviewers should be informed about plans to develop the online form and their role.
• Processors – if your form will route to others to initiate back office processing tasks, these processors should also be informed about plans to develop the online form and their role.
• Application Developers – one or more individuals in the Business Affairs Office who take the information you provide about your form and create it.

Considerations when making the transition from paper to electronic

While developing the online form may be the primary objective, there are additional things to consider early in the process. Don’t be satisfied to just automate the current item or form – as part of moving to an online form, ask how the whole process might be improved or streamlined.

• Each online form comes with a custom report, and can also have a .xls download which includes all fields in the form as well as additional fields you request that are not in the form
• As you leave paper and fillable PDF forms behind, ask yourself if there are any process steps or approvals you can also leave behind?  For example:
  • Can any steps be consolidated by adding fields to the online form or adding more approvals? 
  • How much FTE might be freed up by moving to online forms? 

The remainder of this document describes the various steps to develop and test an online form.  Providing the recommended level of detail at each step to the application developers reduces the time it takes to develop your form, and lessens the probability of downstream problems.  This development methodology is based on a series of successful online forms built, tested and used since July 2015.

Developing Your Form:  Fields

 Review existing paper or fillable PDF forms to see what fields should be included in the online form.  Do the existing fields capture all the data needed?  Whether using an existing document to develop an online form, or developing a new form from scratch, answer the following questions for each field:

• Is the field required?
• Are multiple responses or answers permitted within the field?
• What is the field type (text, integer, decimal, email, etc.)?
• Are abbreviations allowed in text fields?
• How should the field be presented in the form (radio buttons, drop-down menu, text entry etc.)?
• What is the logical sequence of fields in the form?

 One useful method of presenting information about the fields to the application developers is to complete a table similar to this one:

*indicates field is required; the online form will not advance without entries in these fields.

Helpful tips

• Share the field table with others who are familiar with your document or process. Gather any input on additional fields or different characteristics of the fields.
• Organize the field table sequentially, so the order is the same as it will be on the form.
• Think patiently and broadly about the fields – changes requested at this early stage are far easier and take less time for the application developers to complete.

Form Description and Instructions

Once the fields are defined, other important elements of the form need to be determined:

Describe the purpose of the form, and what a form originator must do.

• What is the title of the form?
• What is the business purpose of the form?
• What information should the form originator have on hand before beginning the form?
• Will the form originator need to enter contact information for others who must review the form?
  note: The Signature Application works with uoregon.edu email addresses, not personal or departmental email addresses.
• Will there be any files uploaded along with the form?  Are there any file type restrictions?
• Is it clear to the form originators when they are “done” with the form?
• Will the instructions include a link to a non-forms.uoregon.edu website?
• Does an office manager, supervisor or department head need to review and approve instructions before they are included in the online form? If so, get their sign-off before asking the application developers to include the instructions.  Tip: if a Document Owner is given admin rights, they can enter and edit instructions directly

 EXAMPLE:  UO Athletics Vacation and Sick Leave Usage form
 

 EXAMPLE:  Business Affairs eCommerce Site Access form

Signature Routing

If the form routes to others for review and approval, determine the routing scheme and individuals involved.

• Does the form require different routing schemes or just one?
• How many individuals must review and approve the form?
• Should the form be sent serially to the reviewers, or can they review in parallel?
• Is it likely that a reviewer cannot complete the review, requiring reassignment to a different reviewer?  Who will determine the reassignment?  When will it be initiated?
• What information must the form originator enter about the reviewers?
• What message will the reviewer/approver see when they access the online form?  What message will they see when they have approved the form?

 EXAMPLE:  Clark Honors College Thesis Committee Form

 and

Back Office Processing

After all signature requests have been completed, any back office processing tasks are addressed. If Processors are assigned a task, they receive a message describing the requested action, with a link to access the form and mark it “complete” when they are done.

Please note: Any comments included in the form are seen by everyone that has access to the form – form originator, reviewer/approver and Document Owner, there are no private comments.

EXAMPLE:  Clark Honors College Thesis Committee Form

Reports:

Submission Overview

By default each document type generates a Submission Overview report viewable by any of its assigned Document Type Owners.

Custom reports

While Document Owners can see all submissions and transactions from the Submission Overview report, custom reports organize key fields (identified by the Document Owner) from each submission or transaction in a table.

• What fields should be in the custom report?  In what order?
• Which fields serve as filter or sort fields?
• If there is a “name” field, should it be web-enabled to automatically bring up an email client by clicking on the name?

EXAMPLE:  Clark Honors College Affiliated Faculty Course Proposals (test phase example)
 

The .xls Download

Each custom report can also have an .xls download which consists of any or all fields in the form, including time and date for signature approvals, as well as optional (blank) fields. 

Q: Beyond the fields in the current online form, are there other fields that the Document Owner associates or combines with information from the online form? 

If so, specify those additional fields so the application developer can include them.

Communication

When the online form routes to others for review and approval, are those individuals familiar with the forms.uoregon.edu site, and emails requesting approval coming to their inbox?

• Confer with the application developers to make sure the content of emails from the forms website accurately describes what a reviewer or processor needs to do.
• Determine how to handle forms that “bounce” from the system such as when a uoregon.edu email is entered incorrectly.  Tip: have the Document  Owner access the submitted form and reassign to the same individual but with their correct uoregon.edu email address.
• If the online form is referenced on a department or unit website or Canvas site, don’t forget to include the link to forms.uoregon.edu on those sites.

Testing Your Form

The application developers will develop the online form after you provide the field definitions and other form elements.  While the core Signature Application functionality is solid and reliable for a wide variety of forms, your form still needs to be tested.  Don’t be tempted to skip or do only cursory testing; problems not caught during testing can significantly influence the adoption and use of your form in the future.

Develop a short (1-3 page) test plan:

• Identify testers who can play various roles – form originator, reviewer/approver etc.  If they have not logged into forms.uoregon.edu before, they need to do that so the application developers can establish them on the forms site.
• Develop some test cases – form originators, no matter how clear the instructions might be, may not enter data appropriately or completely.  Think about ways things could go wrong and write short descriptions for testers playing various roles.   For example, a form which requires the uploading of three files is initiated with only two files uploaded – how will you handle that situation?
• Recruit the testers; explain their roles and which test cases they will complete.
• Plan to test the form under four browsers – Chrome, Firefox, Internet Explorer, and Safari.  Again, while the core Signature Application functionality has been thoroughly tested, the implementation of your specific form and its fields may exhibit different characteristics across different browsers.
• Determine the appropriate test window – is a week or two sufficient?  Are the testers available and ready to participate in that timeframe?
• Send the test plan to the application developers for their review and suggestions.

Conduct the testing:

• Before initiating testing, make sure to remove the application developers from the Autopopulated Fields list, unless they have agreed to be part of the test process.  Tip:  if a Document Owner has been given admin rights they can remove the developer(s) from the list.
• Run through the test cases for your form.
• Encourage the testers to send you email and/or a screen shot to illustrate a problem or something that is confusing.
• Collect all input from the test phase as it comes in.  When testing is over, ask testers for additional feedback, such as “were the instructions clear?” and “did you know what to enter in the signature block?”
• Summarize the results, noting any issues or perceived problems which are serious enough to be an impediment to adoption and use.  After sending the summary to the application developers, discuss the issues and collectively agree on what needs to be fixed/modified prior to launching your form.
• Depending on the application developers’ workload, it may take a few days to complete final modifications to your form.