Record each external action separately

Give the case a stable identifier when it enters the workflow. Keep that identifier across attempts so an operator can find the entire history, including the original input and any later correction. A new execution attempt should have its own identifier linked to that case.

Then record the steps that have independent effects. In this example, preparing a proposal, receiving approval, creating the external record and sending the notification are separate steps. The external write can succeed while the notification fails. A single failed flag for the whole case would lose the information needed to restart at the right place.

For an external action, I would record:

• the intended operation and the destination account or environment;
• the approved input version and a protected reference to the request;
• a stable operation identifier, plus identifiers for individual attempts;
• when dispatch began and what response, if any, came back;
• the destination's record or request identifier;
• the latest observed result and how it was checked.

Write the intended operation to durable storage before dispatch. If the worker stops after sending it, the next worker needs to see that an attempt may have occurred. Store later observations as additions to the history. Replacing the original timeout with a success label would make it harder to explain why recovery happened.

A database transaction can protect related local changes. It normally cannot make a remote API call and the local completion record one atomic operation. There is still a gap in which the remote change succeeds and the local update fails. Design a way to investigate that gap using the saved operation identifier.

Keep sensitive payloads in storage with suitable access controls and retention. The operational record can point to them. Copying an entire source document into every log entry makes access and deletion harder to manage, and usually gives the operator more text than they need.