How to Build Predictive Filtering in Make for Error-Proof HR Workflows

Predictive filtering in Make stops bad HR data before it enters your workflow — not after. Build field-level validation rules, wire reject paths to named human owners, and test with controlled dirty data. Done right, this is the difference between a workflow that scales and one that breaks silently on week three.

HR automation breaks at the data layer. A candidate record with a missing required field, a salary entered as “$85,000” instead of “85000,” or a duplicate application that slips past your ATS creates downstream damage no platform can repair after the fact. The fix is predictive filtering: define what valid data looks like, catch deviations at the entry point, and route bad records to a named human owner before they contaminate the pipeline.

This guide builds the filter logic step by step — from prerequisites through production verification. For the strategic foundation on why data integrity is the prerequisite for any HR automation investment, see HRIS Required Fields vs Manual Data Validation and the broader HR operations repair playbook.

What You Need Before Touching Make

Predictive filtering is not a Make feature you configure in isolation. It requires upfront data work. Skip these prerequisites and your filter stack will be incomplete from day one.

• An active Make account with access to the scenario builder and at least one live data source — ATS webhook, Google Form, HRIS API, or spreadsheet.
• A field inventory for your target workflow. List every field the scenario will receive, its expected data type (text, number, date, boolean), and whether it is required or optional. This document is your filter specification.
• A defined list of valid values for any enumerated fields (department codes, employment types, status flags). Filters that check against undefined value sets let exceptions through every time.
• A fallback destination decided before you build. Where do failed records go — a Slack channel, an email alias, a Google Sheet row, an Airtable base? Every filter path that rejects a record must have a named owner.
• A test dataset of at least 5 records: one clean valid record, one with a missing required field, one duplicate, one with a numeric field entered as text, and one with an out-of-range value.

Time estimate: Single-use-case filter (candidate qualification check): 2–4 hours to build, test, and deploy. Multi-branch workflow (onboarding routing or payroll change validation) with full fallback handling: 1–2 days.

Risk to know: Overly aggressive filters that reject too broadly suppress valid records and create false exceptions. Build tight but not brittle — use OR logic where legitimate variation exists in source data formatting.

Step 1: Map Your Data Quality Rules in a Document First

Open a blank document and answer three questions for every field your workflow will process: What is the expected data type? What values are valid? What happens when the field fails validation? This is your filter specification. Do not skip it.

For a candidate screening workflow, a field inventory looks like this:

• years_experience — Number. Valid: 0–40. Invalid if: text, blank, negative, or greater than 40. On fail: route to exception log + Slack alert.
• email — Text. Valid: matches standard email regex pattern. Invalid if: blank or malformed. On fail: reject and notify source system.
• role_applied — Text. Valid: exact match to one of your approved role codes. Invalid if: blank, misspelled, or not on the approved list. On fail: route to recruiter triage queue.
• consent_gdpr — Boolean. Valid: true. Invalid if: false, null, or missing. On fail: hard stop — do not process.
• start_date — Date. Valid: ISO 8601 format (YYYY-MM-DD), within the next 12 months. Invalid if: past date, wrong format, or blank. On fail: route to coordinator for correction.

Complete this inventory before opening Make. The filter logic in Step 2 maps directly to these rules. Teams that skip this step spend their build time discovering their own data — the least efficient place to do it.

Step 2: Build the Filter Stack in Make

Open your target scenario in Make. Add a Filter module immediately after the trigger — this is the gate all incoming records must pass before reaching any downstream action.

Set Up the Primary Validation Filter

In the Filter module, configure condition logic to validate your required fields. For each required field from your inventory:

1. Add a condition row for the field.
2. Select the appropriate operator: Is not empty for required text fields, Is numeric for number fields, Matches pattern for regex-validated fields like email.
3. Connect conditions with AND logic for required fields (all must pass) and OR logic for format variations (multiple acceptable formats for the same field).

A candidate screening filter with four required fields will have four AND-connected conditions in a single Filter module. If any condition fails, the record stops.

Add a Router for Multi-Path Validation

When different failure types need different destinations, replace the single Filter with a Router module. Each route gets its own filter condition plus a dedicated action for failed records.

Standard routing structure for HR candidate workflows:

• Route 1 — Valid records: All required fields present and correctly formatted → proceed to main workflow.
• Route 2 — Missing required fields: Any required field is empty → log to Google Sheet + send Slack alert to HR coordinator.
• Route 3 — Format errors: Required field present but wrong format (e.g., salary entered as text) → send automated correction request to the source system or submitter.
• Route 4 — Duplicate detection: Record with matching email already exists in the data store → route to duplicate review queue, do not process.

Configure Duplicate Detection

Duplicates are the most common silent failure in HR pipelines. To catch them:

1. Add a Data Store: Search Records module before the main action modules.
2. Search by the unique identifier — email address for candidate workflows, employee ID for HRIS workflows.
3. Add a Filter after the search: if records found > 0, route to the duplicate path. If records found = 0, proceed.

Name every module explicitly: “Check for Duplicate Candidate,” not “Search Records 3.” Unnamed modules create support problems the first time a filter fails in production.

Step 3: Wire Every Reject Path to a Named Owner

A reject path with no destination is a black hole. Records disappear, the workflow looks clean in the Make dashboard, and bad data never gets corrected. Every route that rejects a record must execute at least one notification action.

Standard reject path configuration for HR workflows:

• Slack message — name the specific channel and the person responsible for reviewing exceptions. “HR-exceptions” is a channel name; “@coordinator-name” is a named owner. Both are required.
• Google Sheet append — log the rejected record with: timestamp, record ID, failure reason, the field that failed, and the raw value that triggered rejection. This log is your audit trail.
• Email notification — for high-priority failures (missing consent field, GDPR compliance issue, duplicate in a benefits enrollment workflow), send a direct email with the failure detail and a link to the record.

Do not combine all failure types into one generic exception destination. Recruiters need a different view than payroll coordinators. Routing failures to the wrong person delays resolution and trains your team to ignore the alerts.

Step 4: Test With Controlled Dirty Data

Testing with real production data tells you almost nothing about filter effectiveness. Real data is self-selected for validity — records that made it into your system already passed some level of human review. You need records engineered to fail.

Build this test set before running a single scenario execution:

Run each test record through the scenario individually. Check three things for each: Did the correct route fire? Did the reject log capture the right failure reason? Did the right person receive the alert? Do not move the scenario to production until all five test records produce the expected outcome.

Step 5: Verify the Filter Holds in Production

The first week in production is the validation period, not the cruise period. Monitor the exception log daily. Three signals confirm the filter is working:

1. Exceptions are appearing in the log. A filter that logs zero exceptions in the first week is almost certainly misconfigured. Real HR data is messy. Exceptions will appear.
2. Exception reasons are specific. Log entries that say “validation failed” are useless. Log entries that say “years_experience value ’99’ exceeds maximum of 40” are actionable. If your logs are vague, fix the logging module before trusting the filter data.
3. Named owners are resolving exceptions. Confirm with whoever owns each reject path that they receive alerts and clear the queue. An unmonitored exception queue defeats the entire system.

After the first full week, review the exception rate. If more than 15% of incoming records fail validation, your filters are either too tight or your source data has a structural problem the filter alone cannot fix. Either outcome is worth investigating before month two.

For teams building this filter architecture alongside a broader HR operations cleanup, the HR team automation guide covers how small teams scope and execute these builds without developer support. The routed error handling guide covers the reject-path architecture in greater depth.

Predictive Filtering in Make: FAQs

How many filter conditions can a single Make Filter module handle?

Make does not publish a hard limit on filter conditions, but practical performance degrades past 10–12 conditions in a single module. For workflows with more validation rules, split conditions across multiple sequential filter modules or use a Router to separate validation categories by type.

What happens to records that fail a filter in Make?

By default, Make stops processing the scenario for that record and logs it as a skipped execution. Without a configured reject path — a Router with a fallback route plus a notification action — the failure is invisible. Always wire explicit reject paths before deploying any filter-based scenario to production.

Should I validate data in the source system or in Make?

Both. Source-system validation (required fields in your ATS, HRIS, or form) catches errors before they reach Make. Make-level validation catches errors the source system missed or that were introduced by API transformation. The two layers are not redundant — they catch different failure modes. See HRIS Required Fields vs Manual Data Validation for the full breakdown.

How do I handle valid data that legitimately falls outside expected ranges?

Build a review path, not a hard reject. For edge cases where out-of-range values are legitimate — a hire with 45 years of experience, a contractor with no standard employment type — route to a human review queue with the specific flag noted. The reviewer approves the exception and the record proceeds. This keeps the filter tight without suppressing valid records.

What is the difference between a filter and a router in Make?

A Filter module is a binary gate — the record either passes and continues, or it stops. A Router module creates multiple parallel paths, each with its own filter condition and action sequence. Use a Filter when there is one valid path and one stop condition. Use a Router when different failure types need different destinations — which is the standard configuration for production HR workflows.