Refreshing or closing a long statement editor can lose substantial input. Local draft storage can reduce that anxiety, but a promise that the draft will appear on another computer is a different feature. The archived implementation distinguishes browser working material from server documents. When I design recovery, the wording needs to explain not only what can be recovered but where that preservation exists and which later actions remain necessary.
Local preservation helps in the current browser
The preserved code finds records under a designated browser-storage prefix and checks their structure. Those records belong to the browser and the site's storage area. They do not have the same responsibility as a document saved to the server. Clearing browser data or moving to another origin or device does not imply that the same local draft follows. Company-level persistence requires a separate server-backed path with the relevant identity and access rules.
Locally preserved and saved as a server draft should therefore have different messages. One helps recover from interruption; the other creates a document staff can locate through the business system. Displaying unsaved input like a company document can make staff believe it has already been retained centrally. An owner's overview should also avoid treating a person's local working input as recognized business activity. The underlying distinction needs to survive the interface's attempt to make saving feel easy.
Recoverable structure still needs validation
An older draft may not fit a revised editor. The archived helper checks a schema version, document kind, line array and expected value types. It separates recognizable drafts from malformed JSON rather than letting one damaged record break the whole reading operation. Unrecognized records are not automatically deleted. That preserves a possible recovery clue instead of destroying it because the current code does not understand it.
Passing a structural check does not make the draft a currently valid business document. A partner may be disabled, a price may change or the user's authority may differ. Server saving and confirmation should review current conditions after restoration. New defaults also should not silently replace a memo or value the user already edited. Recovery is useful when it brings work back for review, rather than promoting earlier assumptions into present confirmed facts.
Different windows need distinct drafts
If staff can work on different transactions in several windows, the drafts need distinguishable identifiers. One shared last-opened key can make a later window overwrite an earlier transaction. Separate records and update times help people identify the material they intend to resume. Sorting by recency is useful, but it should not automatically apply the latest draft to an unrelated task. Recovery needs a clear choice of identity as well as retained values.
The preserved delete helper checks an expected modification time and avoids deleting a record whose value has changed. That reduces a stale screen's chance of removing newer work. It is not a claim of atomic coordination across all concurrent operations: reading and deleting are separate storage actions. The consuming application still needs an appropriate policy for changes in other windows and conflict resolution. A narrow protective check should be explained within its actual boundary.
Failure to preserve must not clear the input
Browser storage can fail because of limits or policy. Defining a draft-size boundary and offering server draft saving is more useful than assuming storage is unlimited. The especially harmful response would be to clear the editor after preservation fails. Staff need to know that current values remain on screen and which path can retain them. An actionable failure message supports recovery more reliably than a silent exception or an unconditional saved badge.
Prepare synthetic cases for refresh recovery, two documents in different windows, malformed values, schema change, storage failure and stale deletion. Also define which local record is removed after successful server saving. This account reviews preserved helpers and test code; I did not open or alter anybody's current unsaved window. Local recovery becomes trustworthy when it is clearly distinguished from permanent company storage. The easier a feature feels, the more carefully its interface should explain the boundary of the promise it makes.