The task keeps its name while the action changes
Imagine a service team handling a request about a delivery change. The application has brought together the incoming request and the relevant guidance. It prepares a reply for a reviewer, addressed to the customer contact stored on the request. The reply is still a proposal; no message has been sent.
The reviewer reads the wording, checks the intended recipient and approves it. A few minutes later, someone corrects the recipient address. The task identifier has not changed. Neither has its position in the queue. But the action now on screen is different from the one the reviewer approved.
Keep the approved version identifiable
If approval is recorded only as approved=true on the task, the application may treat the edited message as authorized. A more specific record associates the decision with a version of the proposed action. That version can include the recipient, content and attachments, together with the identity of the reviewer and the decision time.
The exact contents of that record depend on the workflow. It need not capture every transient interface detail. It does need to preserve the parts of the action that the approval is intended to cover. Otherwise the application cannot reliably distinguish an approved message from a later edit of the same task.
Decide which edits reopen review
A corrected recipient can change who receives information. An added attachment can change what is disclosed. Both are plausible reasons to require a fresh review. A spelling correction might follow a different rule, but that rule needs to be intentional and visible to the people using the application.
One approach invalidates approval whenever the proposed action changes. Another distinguishes material fields and permits a limited set of edits. The second approach adds rules to maintain and test. The right choice depends on the business process, including who is permitted to make changes after approval. It should not emerge accidentally from the order in which screens were built.
Approval does not finish the external action
The sending service may accept the approved reply, reject it or time out without giving a clear result. These outcomes should leave different application states. An approved proposal waiting to be sent is different from a message accepted by the service, and neither label establishes that a human recipient has read it.
Keep the proposed version, approval and sending attempt connected. If the receiving service supplies a message reference or supports an idempotency key, retain the relevant reference. If its result is uncertain, use the provider’s supported lookup before repeating the action where possible. Some systems offer limited guarantees, and the application needs to make that limitation visible rather than hide it behind a retry button.
Test the transitions, then read the screen
A useful test set for this example includes a recipient changed after approval, a withdrawn decision and a repeated send click. It also includes the less tidy case where the provider accepts the message and the connection then fails. Each test should check the saved state as well as the text shown to the operator.
Finally, look at the screen from the reviewer’s position. Can they see which version is approved, what still needs to happen and whether a new attempt is safe? Those questions expose gaps that a successful API response alone will not show.