Form Workflow and Lifecycle

Overview

Each form consists of any number of sections, each section represents a stage in the lifecycle of that form.  Online Form HTML Specification describes how sections are represented technically in the system.

Moving the Form Between Sections

At each section, whoever is responsible for that section, can take one of four actions.

Save

This saves data without moving the form forwards or backwards in the lifecycle.  Form creators may optionally make this option unavailable in a given section.  E.g., a section that only requires a signature may not need to save data in a draft state to be approved later.  The user saving the form will receive a confirmation email.

Approve

This saves data and advances the form forward to the next stage of the lifecycle, assuming all required fields are filled out.  If a required field is missing or invalid, a save operation will take place.  The next responsible user/s will receive an email alert that the form is ready for action.

This option must always be present when creating the form, though with JavaScript form creators may conditionally show and hide this button based on the form being complete.

Reject

This saves data and terminates the form.  It can no longer be edited by any party, though people who had access can still view it in read-only mode.  The original submitter will receive an email alert that the form was rejected, but no one else in the approval chain will be notified.  The rejector may give a reason for rejecting.  This reason, if provided, will be included in the email alert and displayed across the top of the form in read-only mode.  Form creators may make reject unavailable in a given section.

Return

This saves data and initiates a return.  When returning the user may indicate any previous section to return the form to, provided the current section has visibility to the previous section.  I.e., if the current section doesn't have visibility to the previous section, it won't be a candidate for return, even if the returning user might otherwise know about the previous section.  Form creators may make this option unavailable in a given section of the form, but it is always an option in the active form queue.  The user or group the form is returned to will receive an email alert that the form was returned, along with an optional message from the returning user.

Section Assignments

Sections can be assigned one of three ways:

1. The first section may be set to any, which allows any NetID to initiate a form.

2. A section, including the first, may be set to a given group or groups, which restricts use and initiation to those groups.

3. A section, not including the first, may be assigned to either a particular user or particular group based on user input.  See Assigning Form Sections for more details.

4. A section, not including the first, may have its user or group inherited from a previous section. See Assigning a Section to the Approving Group of a Prior Section and Assigning a Section to the Approving User of a Prior Section for more details.

Form sections can be made optional based on values in previous sections.  This is discussed further under Making Sections Optional.

Assigning to "Any"

Only the first section should be set to "Any."  Subsequent sections set to "Any" must have a user or group assignment take place prior to the "Any" stage of the lifecycle.  This can be an assignment based on user input or inherited from a previous section as described in Assigning Form Sections.

Archiving

Once the last section is approved, it will appear in the active form queue as "ready to be archived."  Pressing the archive button will permanently remove the form from the queue.