Session expiry recovery
Check whether the work exists before asking for another submission
After an expiry complaint, distinguish missing confirmation from missing data. Preserve the draft and verify the original command before retrying.
In this article
Locate the last confirmed state
Ask whether the user saw a saved-draft message, a pending submission or a confirmed reference. Use the application's approved record lookup to check the server outcome.
Do not request session cookies, access tokens or passwords for diagnosis. A transaction reference, approximate time and account context should lead to the appropriate restricted logs.
Keep the current browser state intact while investigating. Refresh or sign-out can remove unsaved work or obscure the sequence that produced the problem.
Guide the supported reauthentication path
Have the user return through the application's sign-in flow and use the original account and organisation. Explain that a different account may not be allowed to recover the draft.
If the server already accepted the command, recover or open that result. If it did not, restore the draft and let current validation run before submission.
For an uncertain outcome, escalate through the command lookup or reconciliation path. Manually recreating the request first can produce duplicate work that support must later untangle.
Diagnose loops without weakening access controls
A repeated sign-in prompt can result from cookie scope, clock issues, failed refresh coordination or an identity-provider error. Collect the application version and sanitised failure category for engineering.
Do not disable expiry or share another user's account as a workaround. Use an approved assisted process when the person cannot complete the task immediately.
If access was deliberately revoked, explain the appropriate owner for review. Successful authentication does not imply that the old task should still be available.
Close with the recovered business outcome
Confirm that the user's draft or submitted record contains the expected information. Check any attachment separately and identify work that genuinely could not be recovered.
Record the failure boundary and add a synthetic regression case when the application caused the loss or duplicate. A vague note that logging in again fixed it will not help identify a recurring defect.
Keep the support guidance current when the recovery flow changes. Staff should know which data is server-saved, which is local and which actions may destroy the only remaining copy.
Primary sources
OWASP: session managementReferences checked 11 September 2026.