# Troubleshoot a recruiting note that did not reach the ATS

When a note does not appear where expected, check source completion, destination identity, permissions, transfer status, and the actual record before retrying.

Canonical source: https://recruitrecap.com/blog/ats-note-transfer-troubleshooting
Author: Recruit Recap editorial team
Published: 2026-10-06T13:45:00+11:00

When a note does not appear where expected, check source completion, destination identity, permissions, transfer status, and the actual record before retrying. Work through the chain so you can distinguish a generation problem from a handoff problem.

## Locate the failed stage

| Stage | Question |
| --- | --- |
| Capture | Was the intended conversation captured? |
| Output | Was the expected note generated and reviewed? |
| Mapping | Is the destination record and field correct? |
| Transfer | What result or error was returned? |
| Visibility | Can the intended user see the final record? |

This diagnostic sequence is an original operational checklist. It is not a product-specific troubleshooting command or a promise that every system exposes each status.

## Check the destination before repeating work

A timeout can leave the outcome uncertain. Search the intended test or candidate record through the authorized interface and reconcile whether the note exists. If it does, investigate visibility or location rather than creating another copy.

Fictional example: a recruiter expects a note under an opportunity, but the agreed mapping wrote to the candidate record. The issue is destination design or expectation, not necessarily a failed API call. Confirm which behavior the agency needs before changing it.

## Preserve useful error evidence

Record the time, source reference, intended destination, exact non-secret error text, and steps already taken. Keep candidate content and credentials out of screenshots or tickets unless the receiving support channel is approved for that information.

Avoid changing several settings at once. A narrow correction makes it easier to establish which change resolved the issue and reduces the risk of introducing a second problem.

## Close the incident with a verification

After the repair, run an approved test and inspect the destination as the intended user. Confirm that a retry did not create duplicates and that the note still preserves the required context. Document any manual work that remains.

Use [record matching](/blog/ats-candidate-record-matching), [permission testing](/blog/ats-handoff-permission-testing), and [retry handling](/blog/ats-integration-duplicate-notes-retries) for focused checks. Recruit Recap integrations are scoped on demand; troubleshoot against the actual agreed implementation rather than assuming a named ATS is supported out of the box.