How to Rediscover Candidates in Your ATS: A Seven-Step Recruiting Playbook

Why ATS rediscovery needs a repeatable process

A new requisition opens, and the first move is usually to post the job or start a fresh search on an external platform. The applicant tracking system, which may hold thousands of people who already applied, interviewed, or were shortlisted, gets a quick keyword search at best. Often it gets none.

The reason is rarely laziness. Having candidate records is not the same as being able to find, evaluate, and appropriately contact the right ones. If job titles are inconsistent, the same person exists three times, stages were never closed out, and nobody is sure which records can still be used, searching the database feels slower and riskier than starting over.

Rediscovery fixes that by turning ad hoc searching into a process with seven steps: audit the data, check what you may do with it, clean it, match it to the role, prioritize the groups worth reviewing, contact candidates properly, and measure and record what happened. This guide covers each step, a data dictionary you can adapt, and a 30-day pilot. It focuses on implementation. If you are comparing tools, the candidate rediscovery software guide is the better starting point.

Step 1: Audit your ATS data

Before you search or clean anything, find out what you actually have. An audit shows how much of the database is searchable, which problems will distort your results, and what you need to fix first. It also gives you a baseline, so you can tell later whether the work made a difference.

What to review

• Record counts. Total candidate records, and the subsets that matter for the roles you hire most: by job family, location, last application date, and last stage reached.
• Field completeness and consistency. How many records have a usable job title, skills, location, application date, source, and stage? Do the same values appear in several forms, for example Sr. Developer, Senior Software Dev, or Software Engineer III?
• Duplicates and fragmented histories. The same person applying through different channels, with different email addresses, or being re-entered by a recruiter.
• Contact details. Records with no email or phone, obvious typos, role-based addresses, or details that have never been checked since entry.
• Searchability. What your ATS can actually search: structured fields only, full resume text, saved searches, Boolean operators, or semantic matching. Test it with a handful of known candidates and see whether they come back.
• Access and ownership. Who can view, edit, merge, export, or delete records, and who is accountable for data quality. If the answer is everyone or nobody, that is a finding.

Record the figures with the date you took them. Do not assume every ATS exposes every report above. If a number cannot be pulled, a manual sample is better than a guess.

Step 2: Review retention, permitted use, and contact restrictions

This step comes before cleaning and searching, because it decides which records are in scope at all. A record sitting in your ATS does not automatically give you permission to use it for a new vacancy or to contact the person again.

Five separate questions

Treat these as different decisions, each with its own answer:

1. Retaining. Are you still allowed to hold this record under your retention policy and the privacy notice the candidate saw?
2. Searching and using. Can you use it to consider the person for a different or later vacancy?
3. Enriching. Can you add or update details from other sources, and are those sources acceptable?
4. Contacting. Can you message this person now, on this channel, about this kind of opportunity?
5. Sharing. Can the record be seen by other recruiters, clients, or connected systems? In agency work, a candidate who applied through one client role may not be shareable with another.

What the UK regulator says and what is still in draft

The UK Information Commissioner Office publishes employment practices guidance on recruitment and selection. It is aimed at employers and at recruitment agencies, head-hunters, and consultancies. When we checked on 26 October 2026, the ICO still marked it as draft guidance that is under review following changes made by the Data Use and Access Act, with a final version to follow. Check the live page before you rely on it.

The draft chapter on keeping recruitment records makes several points relevant to rediscovery. It does not set a fixed retention period. It says that, unless there is a clear business reason, you should not keep records of unsuccessful candidates beyond the statutory period in which a claim arising from the recruitment could be brought. It also covers keeping candidate information for a new purpose, and gives an example of an organization that tells applicants on the application form that it will keep details of its top-scoring candidates for six months in case further vacancies arise. That is an example from the guidance, not a recommended period for everyone.

The practical takeaway is that a keep everyone indefinitely, just in case approach is hard to defend, and that candidates should be told at the point of application what you intend to do with their details. Whether you rely on legitimate interests, consent, or something else for a talent pool depends on your circumstances and the final guidance, so take advice on that choice.

What to put in place

• A written retention schedule that matches your privacy notice, with a review date stored on each record or derived from the last application date.
• A contact restriction status on every record, for example may contact, do not contact, contact on request only, or under review. Apply it before any search results are exported or messaged.
• Rules for confidential records, such as current employees who applied internally, candidates from a client restricted program, or people who asked for their data to be removed.
• A record of the source and notice under which each candidate applied, so you know what they were told.
• Access permissions that limit who can export, merge, or bulk message from historical records.

Step 3: Normalize candidate data and resolve duplicates

Searching a messy database produces messy results. Normalizing means making the same thing look the same everywhere, so a search for one title or skill finds every record that means it. The procedures below are recommended practice. Whether you can run them natively depends on your ATS, and in many systems you will use a combination of bulk edit, import tools, and an integration.

Standardize the fields searches depend on

• Job titles. Keep the original title as entered and add a normalized title or job family alongside it. Never overwrite the original.
• Skills. Build a short controlled vocabulary for your core roles, with aliases, for example Forklift, Reach truck, and MHE operator mapped to one skill group.
• Dates. Use one format and make sure the application date and the last-activity date are different fields.
• Locations. Use a consistent structure such as city, region, country, plus a flag for willingness to relocate or work remotely if you collect it.
• Stages and outcomes. Agree what each stage means and add a reason code for rejection or withdrawal. Rejected with no reason is nearly useless for rediscovery.

Map equivalent titles and skills

Keep a simple mapping table that your team owns and updates. Include the raw term, the normalized term, the job family, and a note about any ambiguity. Associate can mean a junior lawyer, a retail assistant, or a warehouse operative, so map by context, not by word alone.

Find likely duplicates

Match on identifiers that are specific to a person: email address including old addresses, mobile number, and a profile URL where you hold one. Combine weaker signals, such as name plus current employer plus location, only to flag a pair for human review.

Handle merges safely

• Auto-merge only on exact matches of strong identifiers. Put everything else in a review queue.
• Keep the full application history, recruiter notes, consent and notice records, and activity log of both records after a merge.
• Preserve the audit trail: who merged, when, which records, and why.
• Find out whether your ATS can reverse a merge. If it cannot, export both records before merging and treat every merge as final.

Step 4: Match old candidates to the new requisition

Matching works best as a sequence, with each stage narrowing the field while keeping the reasoning visible.

1. Define the mandatory requirements. Separate what the role truly needs, such as a licence, a certification, a work authorization, a language, or a shift pattern, from what is preferred. Write both down before you search.
2. Search normalized titles, skills, and structured fields first. This is the cleanest signal and the easiest to explain.
3. Expand with synonyms and Boolean logic. Add alternative titles and skill terms with OR, exclude confusing terms with NOT, and group terms with parentheses.
4. Use semantic matching only where your system supports it. Semantic search compares meaning rather than exact words, so it can surface a fulfilment operative for a warehouse associate role.
5. Review adjacent experience and transferable skills. Look for people whose work overlaps with the role even if the title differs.
6. Inspect the evidence behind each match. Read the actual resume lines, assessment notes, and interview feedback. A score or a keyword hit is not evidence on its own.
7. Record the recruiter decision and reason. Shortlist, hold, or reject, with a short reason. This protects consistency and helps the next search.

An illustrative search

The following is an illustrative example for a backend engineering role. Boolean syntax differs between systems, so adapt it to your ATS.

(backend engineer OR back-end developer OR platform engineer OR software engineer)
AND (Go OR Golang OR Python)
AND (PostgreSQL OR MySQL OR SQL)
AND stage_reached:(Technical interview OR Final)
AND NOT (contact_status:Do not contact)
AND last_application_date:[after your retention cut-off]

Notice that the last two lines apply restrictions inside the search itself, and that stage and date filters only work if Step 3 was done properly. If your ATS cannot filter on contact status, filter the results before anyone sees them.

Limits of each method

Keyword and Boolean search finds exactly what you ask for, so it misses people who describe the same work in different words, and it will match someone who merely mentions a term. Semantic matching catches related wording but can rank people highly for reasons that are hard to explain, and it does not know about restrictions or availability unless those are in the data. Neither method proves a person is qualified. Both produce a list for a recruiter to review, not a decision.

Step 5: Prioritize the right historical candidate groups

When a search returns hundreds of records, you need a sensible order for review. Decide the order from the job requirements and the evidence in each record, not from habit.

Groups worth reviewing

• Silver-medal candidates and previous finalists. People who reached late stages and were not selected. Their records often contain real assessment evidence. A reason such as another candidate had stronger domain experience is useful. A reason such as failed a required check may be disqualifying.
• Eligible past applicants. Applicants who were never fully assessed but whose profile fits, provided the retention and contact checks pass.
• Alumni and former employees, where relevant. Check why they left, any agreements or restrictions, and whether re-hiring is permitted. Do not assume they are free to contact.
• Former contractors and temporary workers. Often strong for short-notice or recurring work. Check assignment feedback, end reasons, and any client conditions on who may be re-engaged.
• Candidates from related roles or job families. People who applied for adjacent jobs, with skills that transfer.

How to order them

A workable approach is to rank within each group on these factors, in roughly this order of weight, then adjust for your hiring context:

1. Match against the mandatory requirements.
2. Strength and relevance of previous assessment evidence.
3. Recency of the last application or contact. Older does not automatically mean unsuitable. It means the details need more checking.
4. Any stated candidate preferences, such as location, hours, or pay range.
5. Current restrictions, including contact status and retention review.
6. Data quality: records you can verify and contact reliably go first.

Illustrative scenarios by role type

These are hypothetical examples of how the prioritization might work. They are not customer results.