Decide when a saved draft becomes staff work

Saving an applicant's progress and submitting work for review are different events. If a new application treats every saved draft as a staff task, incomplete private preparation can appear in an operational queue before the applicant intended anyone to act. The deeper planning question is not whether autosave works; it is what saving means in the agreed process.

This fictional supplier application allows an applicant to prepare a technical-review request over several sessions. The proposed first design writes each saved request into the same list used by reviewers. The project owner is asked to decide whether that is the intended boundary before development proceeds.

Compare the two tasks

Applicant U-8 begins draft D-41, adds a description and leaves the specification attachment unfinished. The applicant needs to return later without losing the description. A technical reviewer, however, needs a deliberate submission containing the required information and a clear indication that review has been requested.

The initial design conflates persistence with intent. D-41 exists in storage, so it appears in the staff queue. A reviewer cannot tell whether the applicant has finished or merely stepped away. Adding a “draft” colour to the same queue would expose the state, but it would not answer whether staff should receive this work at all.

The business owner chooses a different boundary: applicant-owned drafts remain outside the ordinary review queue; an explicit submission requests staff review. This is an approved rule for the fictional project, not a universal policy for every application. Access, retention and specialist requirements are separately determined by the organization.

Make the chosen rule concrete

The draft view allows U-8 to save and resume D-41. It explains that the work has not yet been submitted. The submission action checks the required information, records the applicant's request for review and creates the staff-visible review item. The application preserves the relationship between the draft content and that submission.

An administrator's authorized support capability, if required, is defined separately. Keeping a draft out of an ordinary review queue does not justify vague promises that nobody can ever access stored information. The interface should describe the actual agreed visibility and workflow rather than make an unverified privacy claim.

The project also decides how later changes work. In this exercise, a submitted item is not silently rewritten by further edits to an applicant's working draft. A correction follows the existing review process and is presented as such. That prevents autosave from becoming an accidental replacement for the organization's submission and correction rules.

Demonstrate both sides of the boundary

The reviewer signs in with the intended staff role. D-41 is absent from the ordinary queue. U-8 resumes it, changes the description and saves again without submitting. The staff queue remains unchanged. The applicant can reopen the saved description, proving that persistence still works even though staff work has not been created.

A separate fixture D-42 is completed and explicitly submitted as review item R-42. The staff queue now contains R-42 with the intended content and submission reference. D-41 remains absent. An incomplete attempt to submit another fixture produces correction guidance and creates no review item.

These controls distinguish the approved behavior from two tempting shortcuts: disabling save entirely, which would prevent the applicant from resuming, or admitting every stored row to the queue, which would erase the submission boundary. The selected result supports both tasks without treating them as the same event.

Questions worth resolving before the estimate

Ask who may resume a draft, what action requests review, which information is required then and how a correction relates to the submitted version. Identify the person who can approve those rules. Also ask what evidence an operator needs when an applicant says they submitted but only a saved draft can be found.

The acceptance record for this example includes D-41's saved and resumed state, R-42's deliberate submission and the incomplete-submission refusal. It leaves no need to infer intent from the mere presence of a database row. Workflow application development can turn such decisions into a usable interface and a reviewable operating record.