Fictional recovery record
Keep the successful requests out of the repair run.
Assume independent task creates, a complete response and no downstream action beyond those creates. The identifiers below are illustrative. In a real job, retain the original request mapping and use the destination identifiers that its API returns.
| Request | Recorded outcome | Recovery decision |
|---|---|---|
| R-101: onboarding call | Created task T-501 | Keep the existing task; do not submit another create |
| R-102: access review | Created task T-502 | Keep the existing task; do not submit another create |
| R-103: welcome task | Rejected: subject too long | Correct the subject, then submit this request once it is safe |
Missing results
A missing result needs an explanation.
The contract says it was not attempted
Suppose processing stops at R-102. A later R-103 may never have run. Record it as unprocessed, rather than giving it the same validation error as R-102. Check whether it depends on the earlier request before scheduling it.
The response was lost
A connection failure leaves a different problem: the task might exist. Check a documented job-status endpoint or a suitable destination identifier. If the API offers a documented idempotency mechanism, follow its scope and lifetime. A locally invented key is not a guarantee the CRM honours.
Recovery run
Build a recovery run someone can inspect.
01
Account for every original request
Keep its source reference, intended operation and result together. Separate completed, rejected, unprocessed and unknown outcomes. Record why you assigned each state; do not infer it from a missing row alone.
02
Repair the rejected input
For R-103, shorten the subject without losing the task meaning. Retrying the unchanged validation error is not a repair. Other faults may be transient; use the provider guidance for those.
03
Check for dependencies and concurrent recovery
A task that depends on a missing account cannot simply proceed alone. Give the repair run a named owner and prevent two operators from submitting the same work together. Recheck uncertain destination state before a consequential write.
04
Confirm the repaired result
Link the recovery attempt back to R-103 and retain the new task identifier. Verify the intended task exists once. If creation succeeded but a later notification failed, recover that step separately rather than creating another task.
Test the repair path before someone needs it.
Use fictional records in a controlled environment. These are proposed checks for this example, not evidence of a deployed implementation.
| Test | Expected evidence |
|---|---|
| One validation rejection among successful creates | Only the corrected rejected request enters recovery |
| Processing stops before the last request | Later requests are identified as unprocessed, with dependencies checked |
| Destination creates a task but its response is lost | The outcome remains unknown until checked; no blind second create |
| A change set rolls back | Recovery follows the group boundary, not a guessed list of individual successes |
| Two operators start the same repair | The recovery design prevents duplicate execution or safely handles it through a documented guarantee |
