9 Make Filtering Techniques That Fix Onboarding Data Precision in 2026

Onboarding automation fails at the filter layer, not the connection layer. These nine Make.com filtering techniques address every major failure mode — from incomplete records entering payroll to duplicate provisioning requests firing twice. Build them in sequence and your onboarding scenarios produce clean, routed, traceable data on the first trigger.

Onboarding automation breaks at the data layer, not the integration layer. The scenario connections work fine. What fails is the logic controlling which data moves, when, and to where. A new hire’s first week is shaped entirely by whether the right provisioning triggers fired, the right payroll fields populated, and the right benefits enrollment path activated — all of which depend on filters you either built or didn’t. This listicle covers the nine filtering techniques that eliminate every major onboarding data failure mode, ranked by the breadth of problems each one solves. For the full framework connecting filtering to mapping and HR data integrity, see the parent guide on data filtering and mapping in Make for HR automation.

1 — Field-Existence Checks: Block Incomplete Records Before Anything Fires

The first filter every onboarding scenario needs is the simplest: confirm that required fields are not empty before allowing any downstream action. An incomplete record that reaches payroll or IT provisioning creates more work than doing nothing at all.

• Required fields to gate: Start date, department, employment type, employee ID, legal name.
• Operator to use: “Exists” or “Is not empty” on every mandatory field — chain them with AND logic so all conditions must pass simultaneously.
• What happens on failure: Route the incomplete record to a separate error branch that logs it to a spreadsheet and sends a Slack or email alert to the HR coordinator for manual review.
• Why it ranks first: Every other filter on this list depends on having valid field values to evaluate. If the field is empty, downstream filters produce false positives or silent errors.

Verdict: Non-negotiable. Build this before any other filter in the scenario. No exceptions.

2 — Deduplication Filters: Stop the Same Record From Triggering Twice

ATS webhooks fire more than once. Recruiters update candidate records mid-process. Integrations retry on timeout. Without a deduplication gate, a single new hire receives two equipment orders, two payroll entries, and two system provisioning requests. The Make.com Data Store module solves this cleanly.

• Mechanism: Before any action module, query a Data Store using the candidate’s unique ATS ID. If the ID already exists, a filter set to “does not exist” stops the scenario for that record.
• Write the ID: On first successful pass, write the ID to the Data Store so subsequent triggers are blocked.
• Include a reset path: Build a separate administrative scenario that removes IDs from the store when a legitimate re-trigger is needed — a rehire, for example.
• Pairs with: The guide on filtering candidate duplicates in Make covers this pattern in detail for recruitment pipelines.

Verdict: Essential in any scenario that uses webhooks or scheduled polling. Skipping this is the single most common cause of downstream double-entry errors.

3 — Employment-Type Routing: Branch the Workflow by Hire Classification

Full-time, part-time, contract, intern — each classification triggers a different set of onboarding actions. Benefits enrollment only applies to qualifying employees. Equipment provisioning varies by role type. Training paths differ by classification. A single unfiltered scenario that treats all hires identically produces errors on every run.

• Filter to build: After the field-existence gate, add a router module with a dedicated branch for each employment type. Set the branch condition to match your HRIS’s exact field values — “FT”, “Full-Time”, and “full_time” are three different strings.
• Map each branch explicitly: Branch 1 (full-time) → benefits enrollment + equipment order + systems provisioning. Branch 2 (contract) → systems provisioning only, no benefits. Branch 3 (intern) → limited systems access + onboarding task creation. Build an explicit fallback branch for unrecognized values so they error cleanly instead of silently routing to the wrong path.
• Validate against your HRIS: Pull the exact employment-type field values from your HRIS before building filters. Mismatched string values are the most common reason employment-type filters fail silently.

Verdict: Required for any organization with more than one hire classification. Without it, every benefits enrollment and provisioning step runs for the wrong people.

4 — Start-Date Windowing: Trigger Actions at the Right Time, Not All at Once

New hire records land in your HRIS days or weeks before the start date. IT provisioning, welcome emails, and Day 1 checklists should not fire the moment a record is created — they fire at specific intervals before and after the start date. Start-date windowing filters solve this.

• How it works: Use Make.com’s date comparison operators to calculate the number of days between today and the start date. Gate each action module behind a filter that checks whether that interval has been reached.
• Common intervals to gate: Equipment order (10 business days before start) → account provisioning (3 business days before) → welcome email (1 business day before) → Day 1 checklist creation (on start date) → 30-day check-in task (30 days after start).
• Scheduled trigger required: This pattern requires a scheduled scenario (daily at 6 AM works for most teams) rather than a webhook-triggered scenario, since the action timing is relative to the start date, not the record creation date.
• Build a “too early” branch: If the record arrives more than 30 days before start date, route it to a holding log rather than processing it. This prevents premature provisioning when offers are accepted far in advance.

Verdict: Without start-date windowing, every action fires at record creation. IT provisions accounts three weeks early. Welcome emails arrive before offer letters. The scenario is technically running and completely wrong.

5 — Location and Department Routing: Different Offices Have Different Everything

A new hire in Austin and a new hire in Chicago don’t get the same equipment vendor, the same state-specific compliance documents, or the same benefits broker contact. Department matters too — a warehouse hire and a marketing hire have different system access requirements. Location and department filters handle both dimensions.

• Layer the router: After employment-type routing, add a second router that branches by location (state or office) and a third that branches by department. Each combination produces a unique action set.
• Don’t build a branch for every combination: Use AND conditions on a single branch to match “Texas AND Marketing” rather than creating separate branches for every location-department pairing. Combinatorial branch structures become unmanageable at scale.
• State-specific compliance documents: Location-based routing is where you gate state-specific forms — California CCPA notice, New York wage notice, state-specific I-9 supplement requirements. Miss this filter and compliance exposure follows.
• Connect to your OpsMap™ process map: If you’ve documented the process map for each location before building, translating it into routing logic is straightforward. If you haven’t, build the map first.

Verdict: Multi-location and multi-department organizations cannot run a single unrouted scenario. The compliance and provisioning differences are too significant.

6 — Status-Transition Filters: Only Fire When the Record Moves to the Right Stage

ATS webhooks and HRIS polling triggers fire on every record update — not just the updates that matter. A recruiter fixing a typo in a candidate’s last name sends the same webhook payload as a status change from “Offer Accepted” to “Active Employee.” Without a status-transition filter, every edit triggers every downstream action.

• The filter to build: Compare the incoming status value against the exact target status string your downstream actions require. Gate every action module behind a filter that passes only when the status field equals your trigger value — “Hired,” “Active,” or whatever your HRIS uses.
• Previous-state comparison: For scenarios that need to detect a transition (moved from one status to another), store the previous status in a Make.com Data Store and compare incoming status against stored status. Only proceed when the two values differ in the expected direction.
• Avoid “contains” operators here: Use exact-match operators (“equals”) for status fields, not “contains.” A status field with value “Offer Accepted — Pending Background” contains the word “Accepted” but is not the same as a confirmed hire status. Exact match prevents false triggers.

Verdict: This filter eliminates the most noise in webhook-triggered scenarios. Without it, every record update generates unnecessary scenario runs and downstream errors. See also: how HRIS required fields interact with manual validation for the broader data integrity picture.

7 — Format and Pattern Validation: Catch Bad Data Before It Reaches Downstream Systems

A valid hire record can still contain malformed data. Employee IDs with letters where digits belong, email addresses missing the domain, phone numbers with dashes in the wrong place — these all pass an existence check but break every downstream module that consumes them. Format validation filters catch the structural problems field-existence checks miss.

• Operators to use: Make.com’s “matches pattern” operator accepts regex. Build patterns for each formatted field — employee ID format, email structure, phone format, ZIP code length — and route non-matching records to an error branch for manual correction.
• Common patterns worth gating: Email address (contains “@” and “.”, no spaces) — Employee ID (all digits, 6 characters) — Phone (10 digits after stripping non-numeric characters) — Start date (valid date format, not a past date more than 30 days old).
• Log the specific failure: When a record fails pattern validation, the error log entry should name the field that failed and show the actual value received. “Employee ID format invalid: received ‘EMP-045A'” is actionable. “Record failed validation” is not.
• Don’t over-engineer regex: Build the minimum pattern that catches real errors in your specific data. Overly complex regex breaks on legitimate edge cases and creates more manual review than it prevents.

Verdict: Format validation is the difference between an error that surfaces immediately (good) and one that propagates through payroll, IT provisioning, and benefits enrollment before anyone notices (expensive).

8 — Numeric Range Filters: Gate Eligibility and Compliance Thresholds

Salary bands determine benefits eligibility. Weekly hours determine overtime classification. FTE percentage determines which benefits tier applies. These determinations happen at numeric boundaries, and every downstream action depending on them requires a numeric range filter to fire correctly.

• Benefits eligibility gate: Filter on hours-per-week or FTE percentage before routing to the benefits enrollment module. Employees working fewer than 30 hours per week route to the ineligible branch — no enrollment trigger, but a notification to the HR coordinator that the record was processed without benefits enrollment.
• Salary-band routing: If your organization uses tiered benefits or compensation-linked perks (laptop tiers, travel policies, equity grants), numeric salary filters route records to the correct tier without manual lookup.
• ACA and overtime thresholds: ACA compliance triggers at 30 hours per week. FLSA overtime classification depends on salary thresholds that change annually. Build these as scenario variables, not hard-coded values in filter fields, so updating the threshold requires changing one variable — not hunting through every filter in every scenario.
• Use “greater than or equal to,” not “greater than”: Boundary cases (exactly 30 hours, exactly the salary threshold) belong in the eligible bucket. Get the operator right the first time.

Verdict: Numeric range filters are where compliance risk lives. An ACA-eligible employee who doesn’t receive a benefits enrollment offer because a filter used “greater than” instead of “greater than or equal to” is a compliance exposure, not just a data error.

9 — Compound Condition Chains: Stack Filters Into a Single, Auditable Gate

Each filter on this list solves a specific problem. The ninth technique is about combining them correctly so the scenario remains readable, auditable, and maintainable six months after you build it. Poorly chained conditions create logical gaps. Deeply nested routers become unreadable. Compound condition chains solve both problems.

• AND vs. OR logic placement: Use AND chains for eligibility gates (all conditions must pass). Use OR logic for notification routing (any of several conditions triggers an alert). Mixing them without documentation produces scenarios that pass records they should block and block records they should pass.
• Document every compound filter: Add a Make.com note to every filter module that explains what the filter allows through and what it blocks — and why. “Passes: FT employees with valid ID, active status, start date within 14 days. Blocks: everything else → error branch” is the correct level of detail.
• Build the error branch first: Before configuring the pass condition, build the failure path. When you know where blocked records go, you write cleaner pass conditions. Most filter failures happen because the failure path wasn’t considered during build.
• Test with adversarial data: Run the scenario with records designed to find gaps — missing fields, wrong employment type, boundary-case dates, malformed IDs. The goal is to trigger every error branch intentionally before production data finds them accidentally. This is how the onboarding automation in this case study went from 45 minutes to under 4 minutes without introducing new errors.

Verdict: A scenario with eight correctly configured filters and a broken compound gate at the end still fails. Compound condition logic is the last line of defense before data exits your scenario and enters payroll, IT, and benefits systems.

How These Filters Work Together

Run them in sequence. Field-existence check first, deduplication second, then employment type, then start-date windowing, then location and department routing. Status-transition, format validation, and numeric range filters apply at the module level closest to the downstream system they protect. Compound condition chains wrap the final eligibility gate before any write action fires.

That sequence produces onboarding scenarios where bad data surfaces immediately, incomplete records never reach downstream systems, and every failure produces a traceable log entry — not a silent wrong action.

For organizations building these filters from scratch, the OpsMesh™ framework structures the discovery step that identifies which filters each scenario actually needs before anyone opens Make.com. Start with the process map. Build the filters the map reveals. Skip that step and you build filters for failure modes you guessed at, not the ones your data actually produces.

The non-technical HR automation guide covers how HR teams without technical backgrounds are building these exact patterns in Make with AI assistance — including filter configuration without writing a single line of code.