Recruitment automation fails at the data layer — before any AI or decision logic runs. These eight Make.com filters stop the damage: duplicate records, missing fields, malformed phone numbers, misrouted applications, and compliance violations. Place each filter at the right point in your scenario and your pipeline runs clean.

Automation breaks where you least expect it — not in the logic, not in the API call, but in the moment a blank field or duplicate email address slips past an unchecked module and cascades through every step downstream. In recruiting workflows, that cascade means fragmented candidate histories, skewed pipeline analytics, wasted outreach, and payroll feeding malformed phone numbers it was never built to handle.

The fix is not a smarter AI layer. The fix is a filter placed at the right point in the execution chain. This post covers the eight that matter most in Make.com recruitment scenarios — what each one does, where it sits, and what breaks without it. If you want the strategic framing first, start with the companion piece on fixing broken hiring processes. Here, the focus is applied.

1. Duplicate Candidate Check Filter

The duplicate check is the highest-ROI filter in any recruiting scenario. Without it, every new intake trigger risks creating a second or third candidate profile for someone already in your ATS — fragmenting engagement history, skewing pipeline metrics, and generating redundant outreach to the same person across disconnected records.

• Placement: Immediately after the intake trigger — form submission, email parse, or webhook — before any enrichment or communication module fires.
• Logic: Run a Search Records module against your ATS or Make.com data store using the candidate’s email address as the unique identifier. After the search, add a filter: if result count is greater than zero, stop execution or route to an Update Existing Record path.
• Why email: Email is the most reliable deduplication key in recruiting data. Phone numbers change. Names have variants. If your intake source does not capture email, combine first name + last name + postal code as a composite key.
• Operation cost: Filters do not consume Make.com operations. The Search Records module does — but it costs far less than allowing duplicate records to cascade through every downstream module and corrupt reporting data.

Non-negotiable. Every recruiting scenario starts here. This single filter eliminates the most common source of pipeline reporting errors in recruiting automation.

2. Required-Field Validation Filter

A candidate record without an email, resume link, or phone number cannot move through your pipeline without manual intervention. The required-field validation filter enforces minimum data standards at intake — stopping incomplete records before they waste downstream operations or stall a recruiter’s queue.

• Placement: After the duplicate check, before any module that depends on the validated fields.
• Logic: Use Make.com’s built-in “Exists” or “Is not empty” operators on each required field. Chain conditions with AND logic so all fields must pass for execution to continue.
• Required fields for most recruiting workflows: Email address, resume URL or attachment ID, job requisition ID, application date.
• Failed-record routing: Do not silently drop records that fail validation. Route them to a dedicated “Incomplete Applications” sheet or queue with a timestamp and the specific field that failed. This creates an auditable backlog your team works manually without losing the candidate.

Incomplete records that require manual follow-up are a direct contributor to recruiter admin overhead. This filter surfaces the problem immediately at the source — where it costs one manual fix — instead of downstream, where it costs five.

3. Phone Number Format Normalization Filter

Phone numbers enter your system in every format imaginable: (555) 867-5309, 555.867.5309, +15558675309, 5558675309. Every downstream module that touches that field — SMS triggers, payroll exports, HRIS syncs — expects a specific format. Without normalization, those modules fail silently or, worse, pass malformed data into systems that treat it as valid.

• Placement: After required-field validation, before any module that sends SMS, dials a number, or exports contact data to an external system.
• Logic: Use Make.com’s built-in replace function to strip non-numeric characters, then reformat to E.164 (+1XXXXXXXXXX for US numbers) using string concatenation. Add a filter after transformation: if the resulting string length is not 12 characters, route to an exception queue.
• Why E.164: It is the format accepted by every major SMS provider, VOIP system, and HRIS platform. Standardize once at intake and every downstream module works without modification.

This filter catches format errors before they reach payroll, onboarding, or SMS outreach — the three places where a malformed phone number causes the most damage.

4. Application Status Routing Filter

Not every incoming record belongs in the same pipeline path. A new application, a returning candidate, a referral, and a rehire all require different module sequences. Without a status routing filter, every record runs through the same logic regardless of where it belongs — triggering wrong communications, skipping required steps, or writing to the wrong ATS stage.

• Placement: After validation filters, at the fork point where execution paths diverge.
• Logic: Use Make.com’s router module to split execution by application source or candidate status. Add a filter on each route: one for new applicants, one for returning candidates (flagged by the duplicate check returning a match), one for internal referrals with a referral code field populated.
• Common routes: New application → full intake sequence. Returning candidate → record update + resume version compare. Referral → referral attribution module fires before standard intake.

The routing filter is what makes one scenario handle multiple intake types cleanly. Without it, you build separate scenarios for each case — and maintain them all separately when your process changes.

5. Resume Attachment Verification Filter

Many application forms allow resume upload to be optional. Your ATS does not. If a record reaches your ATS sync module without a resume URL or attachment ID, that sync either fails, writes a blank field, or throws an error that stops the entire scenario. The resume verification filter catches missing attachments before that happens.

• Placement: After required-field validation, before any module that reads or processes the resume field.
• Logic: Use the “Exists” operator on the resume URL or file ID field. If the field is empty, route to a separate path that sends the candidate an automated email requesting the missing document — with a direct upload link — and writes the record to a “Pending Resume” queue in your data store.
• Don’t block; park: A candidate without a resume at intake is recoverable. A candidate whose record is silently dropped or errored out is not. The filter creates a holding state, not a rejection.

Pair this filter with a follow-up trigger on the “Pending Resume” queue: when the resume is uploaded and the record is updated, the scenario continues from where it paused. No manual handoff required.

6. Compliance Data Routing Filter

EEO data, OFCCP-required fields, and voluntary self-identification responses require different handling than standard applicant data. They cannot flow into the same modules as core profile fields — not into ATS records tied to hiring decisions, not into manager-visible dashboards, and not into any field that downstream logic reads when making routing decisions.

• Placement: Immediately when compliance fields are identified in the incoming record, before any module writes core profile data.
• Logic: Use a router to split compliance fields into a separate execution path that writes only to a dedicated compliance data store. The main execution path continues with PII and profile data stripped of protected class identifiers. No module on the main path reads from the compliance store.
• Separation is the requirement: The goal is not anonymization — it is separation. Compliance data is collected and stored, but it is structurally inaccessible to any module involved in candidate evaluation or routing decisions.

This filter is architectural. It does not slow down your scenario — it protects the organization from a class of compliance failure that is difficult to audit and expensive to remediate after the fact. For teams managing inherited HR operations at scale, the OpsMesh™ framework builds this kind of structural separation into every workflow design from the start.

7. Date and Timestamp Normalization Filter

Application dates, interview scheduled times, and offer expiration timestamps arrive from different sources in different formats. ISO 8601, Unix epoch, MM/DD/YYYY, relative strings like “tomorrow at 2pm” parsed by a form — every format mismatch is a potential failure in any module that calculates intervals, sends timed triggers, or writes to a calendar integration.

• Placement: After intake parsing, before any module that uses date values in calculations, comparisons, or scheduled triggers.
• Logic: Use Make.com’s parseDate function to normalize all incoming date strings to ISO 8601 format (YYYY-MM-DDTHH:MM:SS). Add a filter after parsing: if the resulting value does not match the expected format pattern, route to an exception queue with the raw input value logged.
• Time zones matter: Recruiting workflows span time zones. Normalize to UTC at intake and convert to local time only at the display layer — in notification copy, calendar invites, and candidate-facing outputs. Never store local time in your data layer.

A timestamp normalization failure in a background check or offer letter scenario does not surface immediately. It surfaces three weeks later when an offer expires 24 hours early because a UTC offset was applied twice. Catch it at intake.

8. Source Attribution Filter

Knowing which job board, referral channel, or campaign produced each hire is the data that tells you where to spend your recruiting budget next quarter. Without a source attribution filter, that data either does not get captured, gets overwritten downstream, or arrives in inconsistent formats that make aggregation impossible.

• Placement: Immediately after the intake trigger, before any enrichment module has a chance to overwrite the source field.
• Logic: Read the UTM parameters or source field from the incoming webhook or form submission. Apply a filter: if the source field is empty, check for a referral code field and populate source from that. If both are empty, write “Direct/Unknown” — never leave source blank. Map all source values to a controlled vocabulary list (LinkedIn, Indeed, Referral, Direct, etc.) using a Make.com text parser or data store lookup.
• Why controlled vocabulary: “LinkedIn,” “linkedin,” “LINKEDIN,” and “LinkedIn.com” are four different values in any pivot table or reporting query. Normalize at intake so your analytics layer never has to compensate.

Source attribution data that gets cleaned at intake is usable from day one. Source attribution data that gets cleaned retroactively takes two to three weeks of manual reconciliation for every six months of dirty records. Build the filter once.

How These Eight Filters Work as a System

Each filter addressed above is independently valuable. Together, they form a data quality layer that sits between your intake triggers and every downstream module in your recruiting scenario — ATS sync, background check vendor, onboarding system, payroll export, and compliance store.

The sequence matters. Run them in this order:

1. Duplicate check — stops bad records from entering the system at all
2. Required-field validation — stops incomplete records before they waste operations
3. Resume attachment verification — parks recoverable records instead of dropping them
4. Phone format normalization — standardizes contact data before it reaches any external module
5. Date normalization — locks in clean timestamps before any timed logic runs
6. Source attribution — captures origin data before enrichment can overwrite it
7. Application status routing — splits execution paths based on verified, clean data
8. Compliance data routing — isolates protected class fields from all decision-relevant paths

None of these filters require custom code. All eight are buildable with native Make.com operators, router modules, and data store lookups. The investment is configuration time — not development time.

For teams evaluating where to start, an OpsMap™ discovery session maps your current scenario structure, identifies which of these filters are missing, and prioritizes the order of implementation based on where your recruiting data is actually breaking today. That mapping step — running the diagnosis before building the fix — is what separates recruiting automation that scales from recruiting automation that creates new problems at higher volume.

The eight filters above are not advanced Make.com features. They are baseline hygiene. Build them in, and every AI layer, every analytics query, and every downstream integration runs on data it can actually trust.