Approach to save a submission as a draft, recall it, and continue
We have a potential user requirement for a user who is filling out a form in a Workflow and attaching files but is not ready to actually hit the “Submit” button; but they want to have a “Save as draft” option.
Our thought process has been to have this in itself be a “Submit” function but would instead send the json-payload and attachments to another restful endpoint and save them with some key information.
Then when the user returns we have a sequence of steps on the workflow first loading to see if they have any drafts saved and if so display a “Load a previous draft” button that would then list the draft submissions and when they select one would then read it's content back into appropriate form properties to allow them to continue from their.
Has anyone put any thought into this kind of workflow? Or are we going to be blazing a new trail??
-
If this is in the same browser session, store the data with Set Application Data Activity and reload it with the Get Application Data Activity.
See
https://docs.vertigisstudio.com/workflow/latest/help/set-application-data.htmlhttps://docs.vertigisstudio.com/workflow/latest/help/get-application-data.html
0 -
Nico Burgerhart But can you store attachments as application data?
0 -
This would be across different sessions so just relying on session-state or local-cache wouldn't work
As for the attachments we use a Feature service attachment to move the binary file.
0 -
I've got these sorts of workflows here and there. It's nobody's favorite solution, but the simple thing remains to have a status field of some sort in the data.
This could be a “Status” or “Submitted” field per se, but there are often existing data fields available that can be recycled for this purpose:
- Date posted/uploaded/submitted/etc (not the builtin created_date field)
- User posted/submitted/authorized by/etc (not the builtin created_by field)
- Any derived fields that would otherwise be calculated by WF downstream of a submission
In each case, the field is not user-entered but rather generated by the workflow. If the field is null, then the record is a draft.
This also opens up the possibility of auto-saving on every form element update, which takes longer to write but the users tend to quite like the functionality. Some WFs create a record when they open, then update the record every time the form changes. This way, if even if the app refreshes the user gets to keep their data!
0
Please sign in to leave a comment.
Comments
4 comments