An ATS handoff needs a defined retry rule so an uncertain response does not create duplicate notes. Before repeating a transfer, establish whether the first attempt reached the destination and how the workflow identifies the same source event.
Separate three outcomes
| Observed state | Appropriate next investigation |
|---|---|
| Confirmed failure before write | Correct the cause, then retry under the agreed process |
| Confirmed success | Do not repeat the same write |
| Timeout or unknown result | Reconcile the destination before retrying |
The exact mechanism depends on the integration. This is an operational test plan, not a claim that an ATS or Recruit Recap automatically provides idempotency.
Use a repeatable test case
Fictional test: a reviewed screen is sent to a sample candidate record. The connection times out after the request. The tester checks the destination and finds the note already present. Repeating the request without reconciliation would create a second copy in a workflow that does not deduplicate.
Agree what identifies the source: for example, a stable meeting or export reference in the integration design. A title such as “Candidate screen” is usually insufficient to distinguish repeated attempts from genuinely separate conversations.
Distinguish corrections from retries
A corrected note is not necessarily the same operation as repeating a failed transfer. Decide whether the workflow edits an existing note, adds a dated correction, or creates a new version. Test that behavior explicitly.
Also distinguish a new meeting with the same candidate from a duplicate attempt. Overly broad deduplication can suppress legitimate follow-up information.
Make the status visible to recruiters
The person using the workflow should know whether the transfer succeeded, failed, or needs reconciliation. “Processing” indefinitely is not a useful completion state. Identify who handles exceptions and how long the team should wait before escalating.
Keep test records and logs in the agency's authorized environment. Do not publish actual candidate payloads as troubleshooting examples.
The ATS integration checklist covers the overall handoff; correction propagation covers changed content. Recruit Recap integrations are scoped on demand. Include uncertain outcomes and repeated submissions in the acceptance criteria rather than assuming a successful demo establishes reliable retry behavior.