Saved progress must state how long it remains valid
Aliases: progress expiry · draft TTL · application retention window
What it is
Keeping a long flow’s progress is not an unbounded promise to store an application. Seats release, policies change, stock runs out, regulators require unfinished files to be cleared. Saved data must state its lifetime: at the moment of save and on the resume entrance, people must see how long this progress remains usable and what happens when it expires. This is the lifetime of a cross-session task object, not the expiry of browsing state such as list filters.
Why it happens
An unfinished application is an intermediate server-side state that consumes resources: it may hold a slot, quote a rate from that day, include a disclosure about to go stale. If the product says “saved” and not “saved until when,” people plan as if the draft will always be there; on expiry it becomes blank or is bounced to step one by a new policy version. The failure is in planning—the day left on the calendar, the object is already dead.
Lifetime also has legal and operational layers: unsubmitted personal data cannot be stored forever; a promotional price cannot be submitted at the old rate after it lapses. If resume silently overlays a new policy on an old draft, people believe they are continuing and are in fact signing terms they have not read. The notice has to include two things: a calendar deadline, and whether expiry means deletion, read-only review, or a mandatory refill on a new version. Without that sentence, TTL is only a cron job on the server.
Studying it
Have people save progress, then open the resume entrance before expiry, on the day, and after. Compare a visible date with a mere “saved.”
- Dependent variables: whether resume is scheduled against the lifetime, whether a blank after expiry is taken as the system losing data, whether a new policy version is accepted unknowingly.
- Independent variables: whether the lifetime is visible, post-expiry treatment (delete / read-only / force new version), whether a reminder is sent before expiry.
- Methodological note: shrinking TTL to minutes in the lab makes people watch a countdown, unlike a real thirty days. Cleaner: put the date on the interface and ask “which day will you come back to finish” and “if the entrance is gone that day, how do you explain it.” Do not test browsing-filter expiry copy and a legal application cutoff as if they were the same sentence.
Where it stops holding
A local toy flow with no external constraint (a logged-out practice survey) may discard on tab close and should not promise a lifetime. Progress the user deleted is no longer a TTL problem. If a live step must be voided by a hot policy update, the lifetime is cut immediately and needs an extra “the rules changed,” not the original deadline. A permanently editable “my profile” is not a long-flow draft and does not take application-style TTL.
Applying it
- State the deadline and the post-expiry treatment (deleted / must refill on a new version) on save success, on the resume entrance, and in the reminder mail.
- Send one reminder before expiry. After expiry the entrance must not pretend it can continue; it should explain expiry and whether review is still possible.
- When policy or rates change inside the draft’s life, resume must show the change and ask for confirmation; do not silently swap in new terms.
- Verify: after save, screenshot the entrance. Someone uninvolved should be able to say how many days remain and what expiry does. Advance the system date past the cutoff; the entrance should become an expiry explanation, not a blank form. A dateless “saved” fails this leaf.