Submission Expiration

Owned by James Pasta
Last updated: Mar 22, 2024
3 min read

Formerly AKA -Don't drink the milk 2 weeks after the best before
Discussions

MJF has an existing feature turned on in CHEFS called Save and Edit Drafts
This feature allows users of the Forms to Save a draft version of a Submission and come back to edit and finish the draft submission at a later date.

Problem: There is no current expiration of the draft, the user can come back years later and try to submit a version that is no longer valid from a policy perspective.

Submission versions can be older versions of the form.

My preference would be to not allow any edit of draft versions.
That being said it may not be likely that the business would enforce this request as it is useful to the end user not to be required to fill out a submission in one sitting.

The above being said leads to a couple issues if we allow draft submissions.

  1. Mistakes that are published could exist for extended periods(no expiration) as draft submissions (as long as there is one published version of the form that exists previous submissions will be available).

  2. Once there is enough volume of submissions it will be difficult to monitor the state of submissions being sent to Unity. A lack of quality information coming into the Unity system.

Design

Update (This is where the option should live if the Allow edit draft submissions is enabled)

image-20240322-183130.png

This should re-use the Keep open for but would be
Expire draft submission after for the placeholder text

 

image-20240322-183300.png

 

The submit button will not allow the form to be submitted and will have a banner message display:

The draft is expired, please contact Program Area for questions 

 

A couple ideas for mitigating this issue would be to

  1. Optionally Allow expiration of form versions based on a date that would be optional, I would appreciate how the wording of the message should be shown to a user trying to submit an expired form version would read. - This is different than expiring Forms closing date in that it is the version that expires.
    Maybe a Valid from and Valid To date that the Submission could not be activated until Start Date at the form version level. (Not sure if we need version level scheduling as it could get really complicated)

  2. Monitor the number of draft submissions in the wild in order to understand how many drafts exist. Knowing that there are 3000 version 2 submissions in a draft state might be useful before expiring a submission. If it is not expired then the mapping details for these may be important as the policies may have changed around the grant approval process.

  3. Optionaly Instead add a period of days before the submission expires. This submission will self destruct in 10 days.

    There are a couple considerations around scheduled forms, if there is also a closing date for the form then the messaging to an end user who has been told they have 90 days to complete a form would not work. As long as there is a closing date on the form and the expiration date on the submission is after the closing date then the closing date should be used on the edit of the draft as a message.

    This form is scheduled to be closed on Feb 12, 2024