Adding LLM screening to your ATS without creating duplicate records

Adding LLM screening on top of an existing ATS without creating duplicate records comes down to three rules: keep the ATS as the only system of record, sync candidates on the ATS’s stable record ID rather than on email addresses, and write screening results back to the original record as fields instead of letting the tool keep its own copies. The screening layer should hold a reference to each candidate, never a second version of them. Break any one of those rules and you will be reconciling two candidate databases by the end of the quarter.

Why do screening tools create duplicates in the first place?

Most layered screening tools were built to demo standalone, so the first thing they do is build their own candidate table. They ingest CVs from your inbox, careers page or ATS export, then try to keep their records aligned with the ATS by matching on email address. That matching step is where the trouble starts:

• Candidates use more than one address: a personal one, a work one, an alias kept for job hunting.
• People reapply months later from a new address, so the tool mints a new identity for someone you already track.
• Typos, case differences and plus-addressing all defeat exact matching.
• When no match is found, many tools helpfully push their record back into the ATS as a brand new candidate.

Every missed match is a second record for a person you already have, and the push-back behaviour means the duplication compounds in both systems at once. The cleanup playbook lives in deduplicating candidate records in your ATS, but cleanup is the wrong fix here: the seam between the two systems has to stop producing duplicates, or you are mopping under a running tap.

What does one source of truth mean in practice?

It means each candidate exists in exactly one place: an ATS record with an internal ID. The screening tool is a processor that borrows data and returns results, nothing more. Concretely:

• The ATS creates the record first. Only then do the CV and the record’s ID go to the screening tool.
• The tool stores your ID on everything it computes. No row should exist on the tool’s side without a valid ATS candidate ID attached to it.
• Results flow back to the same record. The tool never creates candidates in the ATS and never edits contact details.
• Recruiters work in the ATS. The day your team starts triaging queues inside the screening tool, it has become a second ATS in everything but name.

Two systems both claiming to own the candidate is the same disease that breaks out when a CRM and an ATS overlap without a boundary, a split we unpack in recruitment CRM vs ATS. Ownership is not a feeling; it is whichever system the team trusts when the two disagree. Decide it once, in writing, before the integration goes live.

Why sync on stable IDs instead of email addresses?

An email address is an attribute of a person. A record ID is the identity of a record. Attributes change: people switch providers, retire old inboxes, apply from a phone with whichever account autofilled. A record ID assigned at creation never changes, which is exactly the property a sync key needs.

The practical wiring is short. On application, the ATS fires a webhook (or the integration polls) carrying the candidate ID and the CV. The tool returns results keyed by that same ID, and a periodic reconciliation job flags any tool-side row missing one, which should be a rare event rather than a daily report.

If a screening vendor can only match on email, treat that as a finding, not a limitation to work around: it tells you the product was designed to own its own database rather than reference yours. There is a compliance edge too. When a candidate exercises their right to erasure, ID-keyed references let you cascade the deletion in one motion. Email-matched copies have to be hunted down, and the ones with the typo in the address are precisely the ones you will miss.

How should scores get written back?

As fields on the existing record, not as documents and not as copies. The minimum useful set: a score or band, a short rationale, a timestamp, and the model or prompt version that produced the result. Structured fields can be filtered and compared across a pipeline, and they give you something to point at when you must show how a screening judgment was reached, which the EU AI Act’s high-risk classification for hiring AI turns from a nicety into an obligation. A score you cannot audit is a score you cannot defend, a problem with its own discipline covered in auditing AI candidate scoring for bias.

The anti-pattern is the PDF report attached to the record. It preserves the words and loses everything else: you cannot filter on an attachment, compare it across candidates, or prove later which model version wrote it.

What are the warning signs your stack is splitting?

The split rarely announces itself. Watch for these:

• Recruiters ask which system has the real status of a candidate.
• The two systems report different counts for the same role, and nobody investigates anymore.
• Outreach leaves from the screening tool and never appears in the ATS timeline.
• A GDPR deletion request requires action in both systems, and only one has a process for it.
• The ATS dedupe backlog grows in step with the tool’s import schedule.
• The screening tool sprouts pipeline-like features and your team quietly starts using them.

Any two of these and the candidate already has two owners. That is the moment to repair the integration or rethink it, not after the next audit.

When does a layered tool make sense, and when should you switch?

Situation	Better move
ATS has a real API: webhooks, writable custom fields	Layer; the seam can be built properly
Screening is the only gap; pipeline, comms and reporting are fine	Layer; narrow gap, narrow tool
Mid-contract with years of data history	Layer now, revisit at renewal
ATS has no API and exports by CSV	Switch; you cannot build a clean seam on file drops
The layer already owns scoring, notes and outreach	Switch; you are paying twice for one workflow

The honest cost of layering is that the seam is forever: sync code to maintain, reconciliation to run, two vendors, two data processing agreements. That is a fair price when the ATS is good and the gap is narrow. When the gap list keeps growing, you are assembling an AI-native recruiting stack one bolt-on at a time, and the comparison worth making is legacy ATS vs AI-native ATS, where screening is a property of the system rather than a passenger on it.

Where does Recruitifly fit?

Recruitifly’s answer to the seam is not to have one. Screening lives inside the system of record: Fly, the assistant built into the platform, parses CVs into profiles, scores and ranks candidates against a job, builds shortlists and compares candidates side by side, and everything it produces lands on the one candidate record it read from. There is no second database and no email matching anywhere in the path. Every write is propose-then-confirm: Fly prepares the score or the shortlist, and a recruiter approves before anything changes, which is the human-oversight shape EU rules expect. GDPR tooling (retention windows, consent tracking, deletion requests) operates on that same single record, so erasure happens in one motion.

We are in private beta. If you are weighing a screening layer against a switch, talk to us and bring your current stack diagram; the conversation is more useful when we can see where your seams are.