Your automation says “success.” The work still isn’t done.

Start at the destination

When someone reports a missing task or file, begin with the destination they expected to see. Identify the exact record, time range, and missing item. Then work backward to the source event. This keeps the investigation anchored to the business outcome.

“The automation succeeded” may only mean a request was accepted or a step completed without throwing an error. A later operation can still fail, a filter can skip the record, or the result can land on the wrong job.

Example: the file arrived on the wrong job

The upload succeeded, but the workflow matched “Morgan Lee” to a different project with the same contact name. Compare the source project ID with the destination job ID. Correct the matching rule and identify affected files before recovery. A second upload without fixing the match would repeat the problem.

Collect a small evidence trail

You usually need one failed example and one known-good example before changing the workflow. Record identifiers and timestamps are more useful than a broad claim that the system is broken.

• The original event or source record
• The run or request identifier, if available
• The matching and routing decisions
• The destination response and actual destination record
• Any subsequent step that moves, changes, or removes the result

Do not retry blindly

A failed workflow may have completed some of its steps. Replaying the entire sequence can create duplicate contacts, tasks, or notifications. First establish what already happened and which operation is safe to repeat.

For example, a document might have uploaded successfully while the tracking sheet failed to update. Retrying the upload would not repair the actual issue. A targeted correction may be safer than replaying the complete workflow.

Repair the cause and the missed work separately

Fixing a field mapping stops the next failure. It does not automatically recover records missed yesterday. Treat repair and recovery as two explicit pieces of work, with a list of affected items and a completion check for each.

Keep the recovery scope bounded. Establish the time window and matching rules, check for items already delivered, then verify the corrected destination. If you cannot identify the affected set confidently, record that uncertainty instead of guessing.

Leave a usable recovery procedure

A dependable handover says where failures appear, who reviews them, and how to retry safely. It also explains when to stop and ask for help. A diagram without an operational owner will not keep a workflow healthy.

GoodHandoff starts repair work with diagnosis. Depending on the evidence, the recommendation may be a small fix, a rebuild, or a change to the underlying process. The goal is an outcome your team can verify.