Start with the record, not the settings
An integration problem feels like a connection problem, but the first useful question is smaller. Which record is wrong, and what did you expect it to show? Open the candidate in the interview tool and in the ATS. Write down the email address, the vacancy, the stage and the last action. If those values already differ, you have found the place to start.
Changing settings before you can reproduce the issue makes the next check harder. You no longer know which change fixed what. Keep the original record untouched until you have written down the expected and actual state.
Check field mapping and stage names
Field mapping is the first place to look when data arrives in the wrong place. Compare the field labels, not only the field names. A field called status in one system can mean the hiring stage, while the other system uses the same word for the invitation status.
Stage names deserve their own check. If the ATS expects Interview and the interview tool sends Interview round, the record can exist while the stage stays empty. Write the exact values next to each other and decide which system owns the list.
Follow one candidate through every step
Pick a test candidate and move that record through the process in order: invite, start, submit, review and decision. At each step, note what the recruiter sees in both systems. This turns a vague complaint into a list of handoffs that either work or do not.
- Does the invitation create a candidate record before the first answer is recorded?
- Does the recording link appear on the right candidate and vacancy?
- Does the review status change when a reviewer opens or finishes the review?
- Does the decision reach the ATS stage the team expects?
Test one step at a time. If you change the mapping and move several records at once, you cannot tell which action caused the result.
Keep a log that support can use
Write a short entry for each failure. Include the candidate id, the exact time, the action, the expected result and the error text. Add the browser or the integration job name when you know it. A log with five clear entries is worth more than a long description written from memory.
Do not paste personal candidate data into a public ticket. Use the candidate id and the minimum detail needed to reproduce the issue. Keep the full record in your own system.
Decide who owns the fix
Some failures belong to a setting, some to the ATS administrator and some to the vendor. Name an owner for each category before the next problem arrives. The owner of the connection keeps the field map and the log, and decides when a ticket needs to go to the vendor.
Give recruiters a simple route to log a symptom. A short form with the candidate id, the time and the expected stage is enough. The owner can then check the log and respond with a clear next action instead of starting from zero each time.
Run a recurring check
Plan a recurring review of the connection. Open a recent candidate, compare the fields, and confirm that the stage names still match. Add new fields to the map when the hiring process changes, and remove fields that nobody uses.
An integration stays healthy when the team knows which record is the source of truth, which fields must match and who answers when a handoff fails. That routine is quieter than a rescue, and it keeps the hiring workflow predictable.