Business applications
Correcting an approved record needs a deliberate path
Keep a mistaken entry repairable without silently rewriting an earlier decision.
A colleague notices an error in an approved request. The system offers either unrestricted editing or no way to correct it at all. Neither choice necessarily matches the business need: some corrections are ordinary, while others change what was agreed.
Separate types of correction
For a fictional Estonia-connected service, distinguish a contact spelling fix, a corrected internal note and a change to an approved specification. Ask who may make each correction and whether another person must review it.
Preserve enough context to explain the change appropriately. A record that merely displays the latest text may hide why staff acted on different information earlier. The business should define the history it needs and who may see it.
Explain the consequence before confirming
Show the proposed correction and any important effect on linked work. If another approval is required, label that state instead of carrying the old approval forward automatically. W3C's validation guidance includes user confirmation and ways to address mistakes; the particular business rule remains yours to agree.
Do not demand a lengthy justification for every harmless edit just to make the interface look controlled. Match the review to the consequence of the change.
Follow one correction to the next person
Use an invented specification change after an approval. Check the staff record, any customer summary and information already sent to another tool. Ask colleagues which version they would now use and whether another decision is outstanding.
A business application project should support this repair path. A useful system helps people correct mistakes while keeping consequential decisions understandable.
Further reading: W3C guidance on validation and user confirmation.