Duplicate resumes don’t get fixed inside your ATS — they get fixed upstream, in the automation layer, before any record touches the system of record. Make.com’s data store modules give HR teams a deterministic email-keyed deduplication gate that eliminates wasted recruiter review time and corrupted pipeline metrics at the source.

The conventional fix is to configure the ATS to catch duplicates. That instinct is wrong, and it costs recruiting teams real money — in wasted review time, corrupted pipeline metrics, and avoidable compliance exposure in regulated environments.

Duplicate candidates are not a volume problem. They are an architecture problem. The ATS is a system of record. Systems of record are not deduplication engines. Putting deduplication logic inside the ATS is like putting a water filter inside a drinking glass — the contamination has already traveled the entire pipeline before the filter engages.

The correct fix is upstream: deterministic deduplication logic built into the automation layer, running before a single record touches the ATS. This is foundational to how the Make.com layer changes automation work for HR teams — and the one component most HR automation stacks get wrong.

Why the ATS Is the Wrong Deduplication Layer

Most ATS platforms offer some form of duplicate detection. Most of it fires too late.

Here is what happens when the ATS catches a duplicate: the record was already created. The webhook already fired. The recruiter notification already sent. The pipeline stage count already incremented. The ATS then either merges the records — often imperfectly — or flags the duplicate for manual review, creating a task in a recruiter’s queue that should never have reached them.

Deloitte’s Global Human Capital Trends research confirms that data integrity failures in HR systems compound over time — bad records trigger downstream automation, produce misleading analytics, and require exponentially more effort to remediate than to prevent. A duplicate that enters the ATS today contaminates time-to-fill calculations, source-of-hire attribution, diversity reporting, and recruiter capacity models. Every number downstream is corrupted.

Parseur’s research on manual data handling estimates the fully loaded cost of a knowledge worker managing redundant records — including interruption recovery time — at $28,500 per employee per year when aggregated across a team. In a 12-person recruiting operation, duplicate record management is a measurable drag on team capacity, not a minor annoyance.

Email Is the Right Unique Key — Composite Keys Are Not

Deduplication belongs upstream only if the deduplication logic is deterministic and reliable. That starts with choosing the right unique identifier.

The recruiting industry has debated composite keys — combinations of first name, last name, phone number, and location — as alternatives to email. This debate produces noise. Composite keys fail in predictable ways:

• Name collisions: Two distinct candidates share a first name, last name, and city. Your dedup logic blocks a legitimate new applicant.
• Data drift: Candidates update their phone numbers. The same person re-applies 18 months later with a new phone, and your composite key treats them as a new candidate — defeating the purpose entirely.
• Formatting inconsistency: Phone numbers arrive in a dozen formats depending on the source channel. Your composite key comparison fails silently because “(555) 867-5309” and “5558675309” do not match as strings.
• Missing fields: Not every job board requires the same fields. A composite key built on four data points breaks when any of those points is absent or malformed at intake.

Email addresses are persistent, unique to a person, and arrive consistently formatted across every major job board, career site, and ATS integration. Normalize to lowercase before every lookup — that single transformation eliminates the only common formatting variance in email-based matching.

The 5-Step Make.com Deduplication Architecture

This is the upstream architecture that stops duplicates before they reach the ATS. Each step is a discrete Make.com module. No custom code required for the standard implementation.

Before building, run an OpsMap™ audit of your current intake flow to document every channel feeding your ATS. Any channel not covered by your deduplication trigger is a gap — and gaps let duplicates through.

1. Capture the Inbound Record via Webhook

Set a custom webhook as your scenario trigger. Every resume submission — from your ATS’s application form, LinkedIn Easy Apply, job boards, or third-party sourcing tools — routes to this webhook before any ATS write occurs. The webhook is your single intake point.

If your ATS doesn’t support outbound webhooks natively, use a polling module instead: set Make.com to check the ATS API on a schedule and pull newly created records into the deduplication layer for retrospective processing.

2. Normalize the Email Address

Before any lookup, run the incoming email through a text transformation: trim whitespace and convert to lowercase. This single step handles the most common real-world deduplication failures — trailing spaces from form autofill and case mismatches between “John.Smith@email.com” and “john.smith@email.com.”

Make.com’s built-in string functions handle this transformation inside a Set Variable or Tools module with no additional app connection required.

3. Query the Deduplication Data Store

Make.com’s native Data Store acts as your candidate registry. The data structure is simple: one record per unique email, with optional fields for timestamp and source channel.

On every inbound record, run a Data Store Search module using the normalized email as the key. If a matching record exists, this is a duplicate. If no record exists, this is a net-new candidate.

For high-volume pipelines, Make.com’s data stores support up to 500MB per store — sufficient for enterprise-scale candidate registries without additional infrastructure.

4. Route on the Lookup Result

Use a Router module with two routes: one for new candidates (no match found) and one for duplicates (match found).

New candidate route: write the email to the data store, then pass the full record to the ATS via API. Clean record, no review required.

Duplicate route: do not write to the ATS. Route to your exception handling — a Slack notification, a logging module, or a suppressed queue depending on your workflow. The ATS never sees this record.

5. Write to the ATS — Only on Clean Records

The ATS write is the last step, not the first. By the time a record reaches your ATS module, it has already passed the deduplication gate. The ATS receives clean data, every time.

This architecture is compatible with any ATS that exposes an API or accepts webhook payloads — Greenhouse, Lever, Workday, iCIMS, Bullhorn, and most mid-market platforms. The Make.com layer sits between intake and ATS, invisible to applicants and requiring no ATS configuration changes.

What Happens to Caught Duplicates

Stopping a duplicate from entering the ATS is the right call. But the duplicate record carries information worth capturing — specifically, the timestamp and source channel of the re-application. That data tells you something about candidate intent.

Build a secondary path in your Router for duplicates:

• Log the re-application event: Write the duplicate attempt to a separate data store or Google Sheet with timestamp, source channel, and original application date. This surfaces re-engaged candidates worth reviewing.
• Update the existing ATS record: If your ATS supports partial record updates, use a PATCH call to append the re-application event to the candidate’s existing record — without creating a duplicate entry.
• Trigger a recruiter alert for aged candidates: If the original application is more than 90 days old and the candidate re-applies, route a Slack notification or task to the owning recruiter. That is a warm re-engagement signal.
• Suppress silently for recent duplicates: If the original application is less than 14 days old, suppress without notification. This handles accidental double-submits without generating recruiter noise.

This exception architecture is the difference between a deduplication system that loses candidate data and one that turns duplicate signals into recruiting intelligence. Fixing broken hiring processes requires capturing re-engagement signals, not just blocking duplicate records.

When to Add a Time-Window to the Deduplication Logic

Permanent deduplication — blocking any candidate who ever applied — is the right default for most organizations. But roles with high seasonal churn or multi-year hiring cycles benefit from a time-window approach.

A time-window implementation stores the application timestamp alongside the email key in the data store. On each lookup, the scenario checks two conditions: does the email match, and is the original application within the defined window (12–24 months is the standard range)?

If both conditions are true, suppress. If the email matches but the window has expired, treat the record as a legitimate re-application, update the data store timestamp, and pass the record to the ATS as a new candidate.

This requires one filter module added between the data store search and the router — a two-condition filter checking for record existence and timestamp recency. The entire window logic adds one filter to the existing five-step architecture.

Non-technical HR teams build and maintain this architecture in Make.com without developer support. The scenario structure is logical and readable — the filter conditions map directly to plain-language business rules.

Frequently Asked Questions

Why does deduplication need to happen before the ATS receives the record?

Once a record enters the ATS, the downstream effects are already in motion — recruiter notifications, pipeline stage counts, and webhook events have all fired. Merging or removing the record after the fact is remediation work, not prevention. Upstream deduplication stops the contamination before it spreads.

What unique identifier works best for resume deduplication?

Email address, normalized to lowercase. It is persistent across job applications, unique per person, and arrives consistently formatted from every major intake channel. Composite keys built on name, phone, and location fail due to name collisions, data drift, and formatting inconsistency across sources.

Can Make.com’s data store handle high-volume recruiting pipelines?

Yes. Make.com data stores support up to 500MB per store, sufficient for millions of email records. For organizations processing thousands of applications per day, the data store lookup adds negligible latency — the search operation runs in under 200ms in standard conditions.

What should happen to a candidate record when Make.com catches a duplicate?

Route it to an exception path instead of suppressing it entirely. Log the re-application event with timestamp and source channel. If the candidate is re-applying after 90 or more days, send a recruiter alert. If the original application is less than 14 days old, suppress silently — that is an accidental double-submit, not a re-engagement signal.

Does this architecture require changes to the ATS configuration?

No. The Make.com deduplication layer sits between intake and the ATS API. The ATS receives clean records via its existing API endpoints. No ATS configuration changes are required, and applicants see no difference in the application experience.