Handle changes that cannot simply be undone

If an external record was created with the wrong values, recovering the workflow may require a correction in that system. Deleting the local run will not remove the remote record or undo anything that used it.

Write down which actions can be reversed and which need a separate compensating action. Releasing a reservation, cancelling a draft and issuing a correction have different business consequences. The allowed response depends on the system and the organisation's rules. An email that has already been delivered cannot be treated as though nobody received it.

A compensating action should have its own approval where needed, its own operation identifier and a result that can be checked. Link it to the action it addresses. Compensation can fail too, so give it the same uncertain-result handling as the original operation.

Check for intervening changes before restoring an old value. Someone may have corrected the destination record after the failed run. Blindly writing the earlier snapshot back could erase their work. Where supported, use the destination's version or conditional-update mechanism to detect that conflict. Otherwise compare the current record and ask for review when it no longer matches the recovery assumptions.

Keep recovery scoped to the affected case or known batch. If an integration is producing further incorrect writes, pause that write path through the approved operational control while preserving evidence. Record which work is held so it can be accounted for when service resumes. An indiscriminate restart can make it harder to separate the original problem from new attempts.

Before carrying out a destructive correction, have the responsible person review the affected records and the recovery plan. Keep an appropriate backup or export where the system permits it. The runbook should name that approval requirement at the relevant step, where the operator is about to need it.