7 Duplicate Candidate Filters to Build in Make for Cleaner Talent Pipelines in 2026

Duplicate candidate records corrupt pipeline counts, break source-of-hire analytics, and route the same person into two competing outreach sequences. Make’s filter layer intercepts duplicates at the intake point – before they reach your ATS – not after the damage is done. These seven filters implement that logic, ranked from simplest to most comprehensive.

Every ATS ships with some form of duplicate detection. Every recruiting team discovers within six months that it isn’t enough. Candidates apply through LinkedIn, your careers page, a job board, and a referral link – each submission arrives with enough field-level variation to clear native duplicate checks without a flag. The result is bloated pipelines, distorted analytics, and recruiter confusion about who owns which candidate.

The fix lives at the automation layer. A Make scenario placed between your intake sources and your ATS normalizes, compares, and routes records before they ever touch the database. The filters below build on a foundational principle covered in why clean processes must come before any HR automation: enforce data integrity at intake, not after the fact. Each filter stands alone or stacks with the others.

1. Email Exact-Match Filter Using Make’s Built-In Condition

The email exact-match filter is the fastest, cheapest deduplication check available and belongs at the front of every candidate pipeline.

• How it works: A Make filter condition placed immediately after the trigger module checks whether the incoming email address is populated, then evaluates it against a stored reference – a Make Data Store or a live ATS lookup via an HTTP module.
• Trigger point: Fires on every new candidate submission regardless of source – web form, job board webhook, CSV import, or direct API push.
• Match behavior: If the email exists in the reference store, the record routes to a review branch or triggers a merge workflow. If no match, the record passes through to the ATS write module.
• Limitation: Fails when the same person uses different email addresses across submissions – common for candidates with both personal and work accounts.
• Verdict: Non-negotiable first layer. Stops the majority of straightforward duplicates with zero additional API calls beyond the lookup.

2. Normalized Email Filter (Lowercase + Trim Before Match)

Case variation and leading or trailing whitespace cause exact-match filters to miss duplicates they should catch. One additional module closes that gap entirely.

• How it works: Before the filter condition runs, a Make Tools > Set Multiple Variables module applies toLowerCase() and trim() to both the incoming email and the stored reference value. The comparison then runs on the normalized strings.
• Use case: Catches Jane.Smith@Email.com and jane.smith@email.com as the same record – a miss for raw exact-match logic.
• Build location: Insert the normalization module between the trigger and the filter condition. It adds one step and zero latency.
• Pairing rule: Run normalization before every string-comparison filter in the pipeline, not just email. The pattern applies to any text field used as a deduplication key.
• Verdict: A two-minute addition to Filter 1 that meaningfully improves catch rate. There is no reason to skip this step.

Expert Take

Normalization is the unglamorous work that determines whether your deduplication logic actually functions. Teams skip it because it feels trivial. Then they spend hours chasing ghost duplicates that a single toLowerCase() call would have stopped at intake.

3. Composite Key Filter (Name + Phone Combination)

When email alone fails, a composite key built from two or more fields creates a more resilient deduplication signal that survives email variation.

• How it works: Make concatenates normalized first name, last name, and phone number into a single string key – for example, johnsmith5551234567. That composite string is stored in the Data Store and compared against incoming records.
• Why it works: A candidate who applies with two different email addresses almost always uses the same name and phone number. The composite key catches what the email filter misses.
• Normalization requirement: Strip all non-alphanumeric characters from the phone number and apply toLowerCase() to the name fields before concatenation. Inconsistent formatting produces false negatives.
• Limitation: Fails when a candidate changes phone numbers between applications – less common than email variation, but it happens.
• Verdict: The right second layer after email normalization. Adds minimal complexity and covers the most common email-variation scenario.

4. Phone Number Normalization Filter (Strip Formatting Before Match)

Phone numbers arrive in more formats than any other field in a candidate record. A standalone normalization pass prevents the composite key filter from generating false negatives on format variation alone.

• How it works: A Make text function strips all characters except digits from the incoming phone number using replace(phone, /\D/g, "") or an equivalent regex module. The result is a digit-only string that matches regardless of how the number was entered.
• Format examples caught: (555) 123-4567, 555.123.4567, +15551234567, and 5551234567 all normalize to the same string.
• Where to apply it: Apply this normalization both to incoming records and to stored reference values. A mismatch in stored format defeats the purpose.
• Edge case: International candidates with country codes require an additional strip of the leading country code, or the comparison will fail for domestic applicants using the same number without a country prefix.
• Verdict: Required supporting module for any pipeline that uses phone as a deduplication field. Run it before Filter 3, not after.

5. LinkedIn URL Match Filter

LinkedIn URLs are one of the most stable candidate identifiers available. A candidate changes email addresses and phone numbers, but their LinkedIn profile URL changes far less frequently – and it’s unique by definition.

• How it works: When a candidate submission includes a LinkedIn URL field, Make extracts and normalizes the URL – stripping query parameters, trailing slashes, and www. prefixes – then checks it against the Data Store reference.
• Normalization steps: Convert to lowercase, remove https:// and http:// prefixes, strip everything after the profile path slug. The result is a clean string like linkedin.com/in/janesmith.
• Trigger condition: This filter only runs when the LinkedIn URL field is populated. Use a Make filter condition to route records with a blank LinkedIn field past this check to the composite key filter instead.
• Why it matters for recruiting: LinkedIn-sourced candidates and referral submissions almost always include a profile URL. It’s the most reliable deduplication signal for those specific channels.
• Verdict: High-value filter for any pipeline with LinkedIn or referral intake. Worthless for job board submissions that don’t capture the field – handle those with Filters 1 through 4.

6. Fuzzy Name Match Filter Using Make Text Functions

Typos, nicknames, and name order variations cause composite key filters to miss real duplicates. A fuzzy match layer catches what exact comparison logic cannot.

• How it works: Make calculates a similarity score between the incoming candidate’s full name and stored reference names using a custom code module. The simplest implementation uses Levenshtein distance – the number of single-character edits required to transform one string into another. Records with a distance below a set threshold route to a review branch.
• Practical threshold: A Levenshtein distance of 2 or fewer on a full name string catches most typos and nickname variations without generating excessive false positives. Tune based on your pipeline volume.
• Build approach: Use Make’s built-in JavaScript code module to run the distance calculation. Pass the incoming name and a candidate list from the Data Store as inputs. The module returns a match flag and the closest matching record ID.
• When to deploy it: Add this filter after Filters 1 through 5 as a secondary catch layer, not as the primary check. Running fuzzy match on every record against a large Data Store adds execution time. Reserve it for records that cleared the faster filters.
• Verdict: The right tool for high-volume pipelines where name variation is a documented problem. Adds complexity – deploy it after simpler filters are running cleanly.

7. Multi-Signal Scoring Filter (Weighted Combination)

No single field is a perfect deduplication key. A scoring model that weights multiple signals produces the most accurate duplicate detection available at the automation layer.

• How it works: Make passes the incoming record through a custom code module that evaluates each available field against stored reference values and assigns a weighted confidence score. Email exact match scores highest (40 points). Phone normalization match scores second (25 points). Name fuzzy match within threshold scores third (20 points). LinkedIn URL match scores fourth (15 points). Records above a total threshold route to a confirmed duplicate branch. Records in a middle range route to a human review queue. Records below the threshold pass through as new.
• Threshold calibration: Start with a confirmed-duplicate threshold of 65 and a review threshold of 40. Adjust after reviewing the first 200 records the scenario processes.
• Review queue structure: Route middle-range records to a Make Data Store queue with a timestamp and the specific signals that fired. A recruiter reviews and confirms or dismisses the flag. The outcome feeds back into the scoring model threshold over time.
• Why this is the final layer: The scoring model handles the cases every single-field filter misses – partial data submissions, name changes between applications, and the candidate who applied twice with slightly different contact information across a multi-year gap.
• Build complexity: This is the most complex filter in the set. Run Filters 1 through 6 first. The scoring model solves the residual problem after simpler logic has removed the obvious duplicates.
• Verdict: The right architecture for enterprise recruiting pipelines processing hundreds of submissions per week. For smaller volume, Filters 1 through 4 handle the majority of real-world duplicate scenarios with far less build overhead.

Which Filters to Build First

The question isn’t which filters are best in isolation – it’s which combination solves your actual duplicate rate at your current pipeline volume.

Start with Filters 1 and 2 running in sequence. Add Filter 3 the moment email normalization starts returning missed duplicates on the same candidate. Deploy Filter 5 if LinkedIn or referral intake is a significant portion of your volume. Build Filter 7 only after the simpler layers are running cleanly and you have enough review data to calibrate the scoring thresholds.

Every filter in this list runs inside a single Make scenario. No external deduplication service required. No ATS customization required. The entire stack sits at the automation layer, which means it works regardless of what ATS you’re writing records into – and it works immediately, before a single duplicate record enters your pipeline.

For teams looking at how this fits into a broader HR automation build, the Make features that elevate HR automation beyond Zapier covers the infrastructure decisions that inform which of these filters you can realistically maintain long-term. And if the candidate data problem is one piece of a larger broken hiring process, why clean processes must come before any HR automation addresses the process layer these filters support.

The filters are the mechanics. The process is what makes them matter.