What exactly should Undo reverse?

Undo is a small word that can conceal a large requirement. It might mean removing the last line you added, restoring an entire record, reversing a business action or recovering an earlier version for comparison. Those operations have different consequences when another person has also worked on the record.

Before adding an Undo button to an operational tool, ask what the user is entitled to reverse and which later work must survive. A concrete example makes that question easier to answer than a general request for version history.

Separate two legitimate editing histories

Consider a fictional supplier's quote Q-31. An operator accidentally adds optional fitting line L-8. Before they notice, a colleague corrects the delivery instruction from the old warehouse gate to the customer-approved receiving point. The fitting line should be removed; the delivery correction should stay.

The proposed implementation offers to restore the record from the snapshot taken before L-8 was added. That snapshot contains the old delivery instruction. Restoring it would erase a correct, independent change while appearing to undo the mistake.

The reviewer records both operations:

The business owner is then asked a precise question: should Undo restore the whole earlier quote, or reverse the specific accidental line addition while preserving unrelated work? For this tool, the owner chooses the second meaning.

Inspect whether the application can support that promise

The example application records operation identity and line identity, retains an audit history and supports an authorised line reversal with a current-condition check. Those capabilities are inspected before the button is promised. A system that stores only occasional whole-record snapshots might need additional work or a different operating procedure.

The reversal refers to OP-81 and L-8, not simply “the last change”. It verifies that Q-31 is still in a state where the operator may make the correction and that L-8 has not been changed or used in a consequential later action. The condition check and the supported reversal belong to one controlled operation so another edit cannot slip between an inspection and an unconditional change.

This is not a claim that every application supplies such an operation. It is a requirement to establish the actual supported behaviour before offering a reassuring label.

Complete the narrow correction

In the isolated fixture, the operator reviews the proposed reversal. It names the fitting line and explains that other quote changes will remain. The application removes the effect of OP-81 through its supported correction path and records reversal OP-83, linked to the original operation and the responsible account.

Q-31 now contains no active L-8 fitting line. Its corrected delivery instruction remains exactly as approved in OP-82. The history still explains why the line appeared and who reversed it; it has not been rewritten to imply that the mistake never occurred.

The reviewer compares the resulting quote with the intended outcome. A total that happens to match is not enough. The specific line state, delivery instruction and audit relationships all matter.

Decide what happens when Undo is no longer simple

The second fixture starts from the same mistaken addition but gives L-8 a later authorised quantity change. The original reversal request is now refused because its condition no longer holds. The tool explains that the line has changed and asks the operator to review its current state. It does not delete the colleague's work under the earlier permission.

Another fixture uses quote Q-32. Reversing Q-31's OP-81 cannot alter a similarly named fitting line on Q-32. A user without correction authority cannot perform the operation even if they can view its history. Repeating an already completed reversal should follow the application's documented result rather than removing another line.

Some consequential actions may require a different correction entirely. An issued financial document, fulfilled order or externally accepted instruction cannot be treated as an ordinary draft line merely because both appear on a screen. The responsible business and provider rules determine the appropriate route.

Turn the answer into a project requirement

The useful specification names the action, eligible record states, authorised role, condition that must still hold, affected fields, preserved work and audit evidence. It also describes the refusal message and what the operator does next.

That makes the interface copy more honest. “Remove this unmodified optional line” may be more useful than an ambiguous Undo label. Where Undo is retained, its confirmation should explain the bounded effect.

Use project planning to bring one correction that matters to your team. The answer can determine the data and operating model long before a developer chooses where to place the button.