Recover an approved proposal with an uncertain submission

Keep the proposal and operation distinct

Locate the approved proposal and the execution operation created from it. Confirm the payload, reviewer decision and operation identifier. A proposal can be validly approved while its execution result remains unknown.

Inspect whether the downstream request was rejected, accepted or lost after transmission. The absence of a response is not proof that the target was unchanged. Preserve the request and timing evidence before making another attempt.

Prevent competing recovery attempts if multiple workers or operators can handle the same proposal. Use the application's supported ownership or state transition rather than relying on informal coordination.

Reconcile with the target system

Query by the operation identifier where the downstream service supports it. Otherwise use the documented reconciliation method, taking care not to confuse a matching target value with proof that this operation caused it.

For example, an address may already match because a staff member changed it manually. That may satisfy the desired business state, but it does not automatically establish the history of the timed-out request. Record the distinction honestly.

If the downstream service supports idempotent retries, use the same operation identifier and unchanged payload within its supported retention period. Do not create a new identifier simply to get past a pending status.

Check whether further execution remains authorised

If the original operation definitely did not execute, confirm that approval and target eligibility are still valid before retrying. An overnight delay may have allowed the order to enter dispatch or the decision to expire.

When a new proposal is required, retain the link to the previous attempt so support can see why another review exists. Do not erase the uncertain history by resetting the original record to draft.

If the result cannot be established reliably, escalate through the defined business recovery path. Some operations require a person to reconcile downstream state before further action is safe.

Finish with one recorded outcome

Once resolved, update the operation and proposal according to the workflow's state rules. Confirm that delayed responses cannot reverse the final status or trigger another mutation.

Tell the requester whether the change completed, was not performed or needs renewed review. Use the recorded business result as the basis for that message. Then capture the recovery gap, such as missing downstream correlation or an unclear pending state, so the next incident can be resolved with less manual investigation.