Decide What Happens to an Unsent Form When a User Signs Out

A field employee starts a service note on a shared tablet, then signs out before sending it. The next employee signs in and sees the unfinished text. The login screen worked, but the draft crossed an account boundary.

Decide this behavior before accepting a mobile form. A useful specification names the draft owner, explains what sign-out removes, and includes a two-account test. The example below is a proposed acceptance exercise using synthetic records, not a report about a Dynelink client.

Name the state before choosing an action

Separate text that exists only on the device, a draft saved to an account on the server, an item queued for transmission, and a submission the server has accepted. Those states require different messages. Removing a local draft should not silently delete a submitted business record.

Record the account and organization associated with each draft. Also list attachments, previews and queued operations that belong to it. A form is not fully cleared if its text disappears but a photograph or an old background task remains available to the next account.

Write one explicit sign-out policy

For this shared-tablet example, choose to discard the current account's unsent local form and temporary attachments when sign-out is confirmed. Show a clear warning before that action and allow the employee to return to the form. Do not describe discarded work as saved.

If the product instead supports an account-bound server draft, define a separate save step and require confirmation that it succeeded before promising recovery. Specify who may reopen it and when it expires. Keeping drafts is a product and security decision; it should not happen accidentally because a storage entry survives.

For a mobile website, MDN documents that localStorage belongs to an origin and persists across browser sessions without a built-in expiration time. Signing into another account does not make that storage automatically account-specific. Ask the developer to show how the selected draft policy is enforced.

Check sign-out beyond the visible form

OWASP's session guidance requires server-side session invalidation for web logout and addresses removal of sensitive client-side data. Treat clearing the form and ending access as separate checks. A cleared screen alone proves neither complete draft cleanup nor invalidation of the server session.

If sign-out occurs offline, distinguish local cleanup from a server action that has not been confirmed. Define how that pending action is handled and test it after reconnecting. Do not claim that every remote session ended merely because the device displayed a sign-in screen.

Inspect queued work too. For Android apps using WorkManager, the official documentation provides cancellation by ID, name or tag and a stop signal for running workers. The implementation must handle that signal. In your test, verify that old work never adopts the next user's identity; cancellation is not evidence that a server-side action was undone.

Run the two-account rehearsal

1. Sign in as test user A and enter a distinctive invented note with a harmless attachment. Leave it unsent.
2. Start sign-out, read the warning, then cancel. Confirm that the form remains available to A.
3. Repeat and confirm sign-out. Check that the agreed local cleanup completes.
4. Sign in as test user B on the same device. Open the form, attachment picker and recent draft list. None should expose A's discarded material.
5. Restart the app and repeat the checks. Reconnect if the test began offline; inspect whether old queued work attempts to run under B.
6. Sign back in as A. Under this discard policy, the local draft should remain absent. Separately verify that previously submitted records were not deleted.

Keep evidence that explains the outcome

Record the app build, device, network condition, draft state, chosen action and observed result. Use synthetic labels rather than session tokens or customer content. Ask the developer to inspect the relevant storage and queue as well as the screen. Assign an owner to any mismatch and repeat the same sequence after correction.

Discuss your mobile form workflow with Dynelink to define draft ownership, sign-out messages and acceptance cases before handing a shared device to another user.

AI-generated conceptual illustration; not a client screenshot.