ATS data hygiene checklist: duplicates, required fields, stale records and a monthly audit
On this page
- What does a clean ATS database look like?
- How should duplicate records be merged?
- Which fields should be required, and to what standard?
- How do you purge stale records without breaking retention law?
- How do you clean up statuses on closed requisitions?
- Where does dirty ATS data come from?
- The monthly audit routine
- Starting from a messy database: the order of operations
- Common mistakes
- Questions people ask
ATS data hygiene means keeping the database accurate enough to search, report on and defend: one record per person, a small set of required fields filled the same way by everyone, statuses closed when jobs close, and records deleted when the retention schedule says so. The checklist below covers duplicate-merge rules, required fields and naming standards, retention-safe purges, closed-job cleanup and a monthly audit. As of October 2026, both directions of the law apply: US hiring records have a minimum keep period (29 CFR 1602.14), while EU and UK data protection law requires personal data to be "accurate and, where necessary, kept up to date" and not kept longer than necessary (GDPR Art. 5(1)(d) and (e)).
This is database-level hygiene. What a good note says is in how to write candidate notes in your ATS, and preventing a candidate being sent twice to the same client is in how to avoid double submissions. If you are about to switch systems, clean first, then follow the ATS migration checklist.
What does a clean ATS database look like?
Write your own targets; these are examples of measurable checks, not benchmarks.
- Possible-duplicate queue under [50] records and reviewed weekly.
- Required fields complete on [98%] of applications created this month.
- Zero candidates in an active stage on a job closed more than [14] days ago.
- Zero records past their deletion date that are not under a legal hold.
- Every rejected or withdrawn application has a disposition reason from the standard list.
How should duplicate records be merged?
| Match | Confidence | Action |
|---|---|---|
| Same email address | High | Merge, automatically if your system supports it |
| Same mobile number | High | Merge after a quick look (shared family numbers exist) |
| Same name and same LinkedIn or portfolio URL | High | Merge |
| Same name and same city or employer | Medium | Human review |
| Same name only | Low | Never merge on this alone |
Survivor rules, so a merge never loses evidence:
MERGE RULES
- Keep: all applications, stage history, notes, scorecards, attachments
and emails from both records.
- Dates: keep the EARLIEST application date per job and the LATEST
consent or privacy-notice date.
- Contact details: keep both emails and phones; mark the most recent
as primary.
- Owner: keep the owner with the most recent activity; note the other.
- Agency: keep every submission record with its original date and
client; never overwrite an ownership date.
- Legal hold: if either record is on hold, the merged record is on hold.
- Log: who merged, when, and the two original record IDs.Which fields should be required, and to what standard?
| Field | Standard | Why |
|---|---|---|
| Email or phone | Lowercase email, phone in one international format | Duplicate detection only works on clean keys |
| Source | From a fixed two-level list | Source reporting; see source of hire tracking |
| Job title on requisitions | [Level] [Function] [Specialty], e.g. "Senior Engineer, Payments" | Searchable history and clean reports |
| Requisition ID | One format, set at approval | Links ATS, HRIS and finance; see what is a requisition number |
| Disposition reason | From a list of 8 to 12 reasons | Funnel analysis and adverse impact checks |
| Consent or notice date | Date, not a yes/no box | Retention clocks and access requests |
Resist requiring more. A field people must fill but do not care about collects "n/a", "test" and full stops, which are harder to spot than blanks.
How do you purge stale records without breaking retention law?
- Start from the written schedule, not from what feels old. Our candidate data retention policy template lists the periods by location.
- Respect the minimums. Title VII employers keep hiring records for one year from the record or the personnel action, whichever is later, and all relevant records until final disposition once a charge is filed (29 CFR 1602.14). Federal contractors with 150 or more employees and a contract of at least $150,000 keep records for two years, including resume-database search records (41 CFR 60-1.12).
- Exclude legal holds before running anything.
- Respect the maximums. Delete or anonymize records past their period, including attachments and email copies, which many purges miss.
- Keep a deletion log: date, count, criteria, who ran it. Not the deleted data itself.
- Handle individual requests separately, on their own deadlines; see candidate data access requests.
All as of October 2026. This is general information, not legal advice.
How do you clean up statuses on closed requisitions?
Candidates left "in process" on closed jobs inflate pipeline reports, break time-to-fill numbers, and usually mean someone never heard back. When a job closes:
- move every active candidate to a final disposition with a reason from the standard list;
- send the candidates who were interviewed a personal message and the rest a template; see the candidate rejection email templates;
- tag strong runners-up for future roles, with the reason, rather than leaving them active;
- record the hire, start date and source on the job so the job's history is complete.
Where does dirty ATS data come from?
Cleaning without finding the source means cleaning the same records every month. The usual sources, and the fix at each:
| Source | What it creates | Fix at the source |
|---|---|---|
| Job board and career site applications | A new record each time someone applies with a different email | Duplicate check on phone as well as email at import |
| Recruiters adding sourced profiles by hand | Records with a name and a URL only | Search before create; URL as a required field for sourced records |
| Resume parsing | Wrong names, merged phone numbers, odd titles | A quick check of parsed fields before the record is saved |
| Integrations writing back | New picklist values, overwritten fields | Map values in the integration settings; review new values monthly |
| Notes pasted from other tools | Stray formatting, notes on the wrong record | Paste into the application, not the person, when the note is about one job |
| People leaving the team | Orphaned candidates and jobs with no owner | Reassignment as part of the leaver checklist |
Give each area one owner. In a small team that is one person for the whole database; in a larger one, recruiting operations owns standards and the audit, each recruiter owns the records they create, and HR or legal owns the retention schedule and legal holds.
The monthly audit routine
ATS MONTHLY AUDIT Month: [ ] Owner: [ ] Time: about 45 minutes
DUPLICATES
[ ] Possible-duplicate queue reviewed; merges logged
[ ] Count this month: [ ] Last month: [ ]
REQUIRED FIELDS
[ ] Report: applications created this month missing source,
disposition reason or consent date
[ ] Fixed, and the recruiter or integration causing gaps identified
STATUS
[ ] Jobs closed 14+ days with active candidates: [list] -> cleared
[ ] Candidates with no activity in [60] days at an active stage:
[list] -> owner asked to update or close
RETENTION
[ ] Records past deletion date, excluding legal holds: [count]
-> deleted or anonymized, logged
[ ] Legal holds reviewed: still needed? [yes / release: ______]
STANDARDS
[ ] New picklist values added this month reviewed (sources, reasons,
titles); duplicates of existing values merged
[ ] Users who left: access removed, records reassigned
FOLLOW-UP
Top issue this month: [ ] Fix at source: [ ] Owner: [ ]Starting from a messy database: the order of operations
- Purge first. Records past their deletion date do not need to be deduplicated or standardized; they need to be deleted.
- Fix the picklists. Collapse sources, stages and reasons to the standard lists and map old values.
- Deduplicate on the cleaned keys, high-confidence matches first.
- Close stale statuses on closed jobs.
- Switch on required fields and duplicate checks so new data arrives clean.
- Start the monthly audit. A one-time cleanup without it lasts a quarter.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Merging on name alone | Two people's histories in one record | Email, phone or URL match, or human review |
| Bulk "delete everything over 2 years" | Records under hold or longer state minimums lost | Schedule by location, holds excluded first |
| Free-text sources and reasons | Reports nobody trusts | Fixed lists; new values reviewed monthly |
| Too many required fields | Placeholder values hide the gaps | Require only what you report on |
| Cleanup as a project, not a routine | The database drifts back | Forty-five minutes a month, one owner |
Questions people ask
How do you clean up duplicate candidate records in an ATS?
Match on the strongest identifiers first, such as email and phone, merge automatically only on exact matches, and send name-only matches to a person to review. Keep every application, note and attachment from both records, keep the earliest application date and the latest consent, and log each merge. Merging weekly keeps the queue small.
How often should you clean ATS data?
Run a short audit monthly and fix issues at the source: duplicates, missing required fields, candidates still active on closed jobs, and records past their deletion date. A one-time deep cleanup is worth doing before a migration or a reporting project, but without a monthly routine the database drifts back within months.
Can you delete old candidate records from an ATS?
Yes, and privacy law often requires it, but not before the minimum retention period ends or while a record is under a legal hold. US employers covered by Title VII generally keep hiring records for at least one year, federal contractors may need two, and some states require longer. Delete on a written schedule and keep a deletion log. This is general information as of October 2026, not legal advice.
Which fields should be required in an ATS?
Only fields you report on or need for compliance: email or phone, source, the job and stage, a disposition reason when a candidate is rejected or withdraws, and the consent or notice date where you need one. Requiring more than that tends to produce placeholder values that are worse than an empty field.