How to Automate Candidate Pre-Screening and Qualification with Make.com and Keap

By Jack DeePublished On: August 17, 2025

To automate candidate pre-screening with Make.com and Keap, create a webhook-triggered scenario that captures application data, scores answers against documented pass/fail criteria, applies qualification tags in Keap, and routes each candidate to the correct pipeline stage—all without recruiter involvement in the triage step.

Manual candidate triage is where hiring speed dies. A recruiter opens an inbox of 80 applications, reads each one for minimum criteria, copies data into a CRM, and decides who gets a follow-up—before doing any actual recruiting work. The fix is a deterministic pre-screening workflow that runs the moment a candidate submits an application, scores their answers against your exact criteria, writes the result into Keap, and routes them into the right pipeline stage with no human in the loop. This guide shows you how to build that workflow step by step using Make.com and Keap.

This is one component of a broader recruiting automation strategy. Before drilling into this specific workflow, review the foundational concepts behind automation-first process design and why structured workflows outperform ad-hoc AI augmentation in early-stage recruiting operations. For teams considering their tooling, the Make vs. Zapier breakdown for 2026 provides useful context on platform selection.

If you are part of a lean HR team wondering whether this is buildable without developer support, the answer is yes—see how a non-technical HR team built their own Make automations for a real-world proof point.

What You Need Before You Start

Complete these prerequisites before opening Make.com. Skipping them is the most common reason pre-screening workflows fail within two weeks of launch.

Active Make.com account with a plan that supports webhooks and multiple scenario modules. The free tier is insufficient for production use.
Keap account (formerly Infusionsoft) with API access enabled and sufficient custom field slots for your qualification data.
Qualification criteria documented in writing. List every screening question, the field type (number, yes/no, text), and the exact pass/fail threshold. This document is the specification your scenario executes—without it, you are guessing.
Application form ready to configure. Whether you use a Keap web form, a third-party form, or a custom HTML form, you need control over the form’s submission destination so you can point it at a Make.com webhook.
Keap tags pre-created. Build your qualification tags (Qualified, Needs Review, Not Suited, plus any role-specific tags) in Keap before building the scenario. Referencing tags by ID in Make.com modules requires them to exist first.
Time budget: Allow four to eight hours for a three-branch workflow with no external assessment integrations. More complex builds require proportionally more time.

Expert Take

McKinsey research on talent operations consistently finds that structured process discipline—not AI augmentation—drives the largest initial productivity gains in recruiting workflows. Build the deterministic filter first. Layer AI-assisted scoring only after the base workflow is running cleanly. Teams that reverse this order spend more time debugging AI outputs than they save on triage.

Step 1 — Map Your Qualification Criteria and Keap Custom Fields

Before opening Make.com, define exactly what “qualified” means for this role and where that data lives in Keap. This step is the specification your entire scenario executes.

Create a three-column table: Screening Question | Keap Custom Field Name | Pass Threshold. A practical example for a mid-market operations role:

Screening Question	Keap Custom Field	Pass Threshold
Years of relevant experience	`exp_years` (Number)	≥ 3
Required certification held	`cert_required` (Yes/No)	Yes
Available to start within 30 days	`start_availability` (Yes/No)	Yes
Salary expectation within band	`salary_expectation` (Number)	≤ band maximum

Go into Keap and create every custom field on this list before touching Make.com. Note the exact field name as Keap stores it—capitalization and spacing matter when Make.com maps values to fields via the API.

Define your three routing outcomes at this stage:

Qualified — All hard criteria met. Routes to interview scheduling.
Needs Review — Meets most criteria but one or more soft conditions warrant human review. Routes to recruiter queue.
Not Suited — Fails one or more hard criteria. Routes to rejection sequence or archive.

If you want a broader framework for deciding which processes to automate before building anything, the OpsMap™ checklist is the right starting point. It prevents common mistakes that cause workflows to be rebuilt within 90 days.

Step 2 — Build Your Application Form and Webhook Trigger

Your application form must collect every field defined in Step 1 and deliver the data to Make.com the instant the candidate submits. A webhook is the correct delivery mechanism—it fires in real time with no batch delay.

Create the Make.com Webhook URL

Open Make.com and create a new scenario.
Add a Webhooks → Custom Webhook module as the trigger.
Click Add to generate a unique webhook URL. Copy this URL.
Leave the scenario open—you will run a test submission to populate the data structure in the next step.

Configure Your Form

Point the form’s submission action to the Make.com webhook URL you just generated. The exact method depends on your form platform:

Keap web form: Use a post-submission redirect or the Keap-to-Make.com trigger (New Contact or Tag Applied) as an alternative entry point if the native form cannot post to an external URL.
Third-party form (Typeform, Google Forms, JotForm): Use the form platform’s webhook or integration settings to post submission data to the Make.com webhook URL.
Custom HTML form: Set action to the webhook URL and method to POST.

For teams new to Make.com’s module architecture, this plain-English guide to Make scenarios explains how triggers, modules, and routes connect before you start building.

Step 3 — Parse the Incoming Webhook Data

With the webhook URL configured, submit a real test application using sample data that covers every field. Make.com captures this submission and maps the incoming JSON into a usable data bundle.

In Make.com, click Run once on your scenario to put it in listening mode.
Submit your test form using sample candidate data—fill in values that correspond to a “Qualified” outcome so you can verify the happy path first.
Make.com captures the submission and displays the full data structure in the webhook module output panel.
Verify that every field from your Step 1 table appears in the data bundle: exp_years, cert_required, start_availability, salary_expectation, plus contact fields (first name, last name, email).
If any field is missing, return to the form and confirm the field name in the form matches what you expect. Field name mismatches between form and webhook are the most common source of silent data loss.

After verifying the data structure, add a Set Variable or Tools → Set Multiple Variables module immediately after the webhook. Use this module to cast incoming data to the correct types—convert string numbers to actual numbers, normalize yes/no values to boolean, and trim whitespace from text fields. Type mismatches in downstream filter modules produce silent failures that are difficult to diagnose.

Step 4 — Build the Scoring Logic with Filters and Routers

This is the core of the workflow. Make.com’s Router module creates parallel branches, and Filters on each branch act as the pass/fail gates for your qualification criteria.

Add a Router Module

Connect a Flow Control → Router module after your variable-setting module. The Router creates three branches—one for each routing outcome defined in Step 1.

Configure Branch 1: Qualified

Add a Filter to Branch 1. Set the conditions to match ALL hard criteria passing simultaneously:

exp_years ≥ 3 (Greater than or equal to)
cert_required = true
start_availability = true
salary_expectation ≤ [band maximum]

Candidates who clear every condition enter this branch.

Configure Branch 2: Needs Review

Branch 2 catches candidates who pass hard criteria but have soft conditions warranting review. A common example: experience years are borderline (e.g., 2.5 when threshold is 3) or salary expectation is within 10% of the band ceiling. Define the specific soft conditions for your role and encode them as filter conditions on this branch.

Configure Branch 3: Not Suited

Branch 3 requires no filter—it is the fallback branch. Any candidate who does not satisfy Branch 1 or Branch 2 conditions flows here automatically.

For teams who want AI to help generate the filter logic from a plain-English description of the criteria, building Make scenarios with Claude is a practical accelerator at this stage.

Step 5 — Write Qualification Data to Keap

Each branch now needs modules that create or update the Keap contact record and write the qualification outcome. The sequence inside each branch is identical in structure but different in the values applied.

Inside Each Branch

Keap → Search Contacts — Query by email address to check whether the contact already exists. This prevents duplicate records.
Flow Control → Router (inner) — Branch on whether a contact was found or not found.
- Found: Use Keap → Update a Contact to write custom field values.
- Not Found: Use Keap → Create a Contact, then write custom field values in the same module.
Keap → Apply/Remove Tag — Apply the branch-appropriate tag: “Qualified”, “Needs Review”, or “Not Suited”.
Keap → Create a Task (Branch 2 only) — Assign a follow-up task to the recruiting owner with the candidate’s name, role, and the specific soft criteria that triggered the review flag.

Custom field mapping precision matters here. The case of David—a manufacturing HR manager whose team suffered a $27K overpayment from a single data entry error—illustrates what happens when field values are written incorrectly to HR systems. In an automated workflow, a misnamed field means every candidate gets the wrong data written silently.

Step 6 — Configure Automated Candidate Communications

Once the Keap record is updated and tagged, trigger the appropriate communication sequence from Keap. This step runs in parallel with or immediately after the data-writing step.

Branch 1 — Qualified Candidates

Trigger a Keap sequence that sends a personalized acknowledgment email confirming receipt and next steps.
Include a scheduling link for the initial screening call if your process allows self-scheduling at this stage.
Optionally, notify the hiring manager via a Keap task or an HTTP module posting to your team’s messaging tool.

Branch 2 — Needs Review

Send an acknowledgment email that sets a realistic timeline expectation without revealing the review status.
The Keap task created in Step 5 surfaces this candidate in the recruiter’s queue with context attached.

Branch 3 — Not Suited

Trigger a respectful decline sequence from Keap. Write this sequence before launching the scenario—candidates in the not-suited branch experience radio silence if the sequence is missing.
Consider a time-delay step in the sequence to avoid an instantaneous rejection, which candidates find jarring.

Recruiters at firms like Nick’s three-person recruiting team reclaimed 15 hours per week each—150+ hours per month across the team—by removing manual communication steps like these from their daily workflow. The time savings come directly from replacing individual send decisions with deterministic sequence triggers. See the full case study on eliminating manual handoffs with Make for the workflow pattern behind that result.

Step 7 — Add Error Handling Before Going Live

A pre-screening scenario that fails silently is worse than no automation—candidates disappear into a void with no acknowledgment and no record. Add error handling before the scenario touches real applicants.

Right-click each module in Make.com and select Add error handler. Choose Resume for non-critical modules (notification failures) and Rollback or Break for data-writing modules where partial execution creates corrupt records.
Add an error notification route — Connect a final error-catch module that sends an alert (email, Slack via HTTP module, or similar) with the full error payload whenever any module fails. This alert goes to the scenario owner, not to the candidate.
Test failure states explicitly. Submit test applications with intentionally malformed data—a letter in a numeric field, a missing required value—and confirm the error handler fires correctly and no partial records are created in Keap.

For teams building more complex error handling, setting up routed error handling in Make with AI assistance covers the pattern for multi-branch error routing in detail.

How to Know It Worked

Run the following verification sequence after completing the build and before processing real applicants.

Submit three test applications—one that should qualify, one that should trigger “Needs Review”, and one that should route to “Not Suited”. Use distinct email addresses for each.
Check Keap for all three contacts. Confirm each contact exists, all custom fields contain correct values, and the correct tag is applied.
Verify the “Needs Review” task. Open Keap tasks and confirm the recruiter-owner task was created with the correct candidate name and review reason.
Check your inbox for all three communication sequences. The qualified candidate should receive the interview next-steps email. The needs-review candidate should receive the realistic-timeline acknowledgment. The not-suited candidate should receive (or be queued to receive) the decline sequence.
Check scenario execution history in Make.com. All three runs should show green (successful) status with no errors. If any module shows a warning, investigate before going live.
Run an error-state test. Submit a malformed application and confirm the error handler fires, the alert notification arrives, and no corrupt contact is created in Keap.

If all six checks pass, the scenario is ready for production traffic.

Common Mistakes That Break This Workflow

Building before documenting criteria. Scenarios built without a written specification drift as team members make “small” changes to filter conditions without updating the spec. The spec is the source of truth—keep it.
Skipping type normalization. A form that returns “3” as a string will fail a numeric filter expecting 3 as a number. Normalize types in the variable-setting module before any filter logic runs.
Creating Keap tags after building the scenario. Make.com references tags by ID. Tags created after the scenario is built require returning to every Apply Tag module to update the reference. Create all tags first.
No fallback for missing webhook fields. If a form field is optional and a candidate leaves it blank, the webhook payload omits that key entirely. Modules downstream that reference the missing key throw an error. Use Make.com’s ifempty() function to supply safe default values for optional fields.
Launching without the decline sequence in Keap. The “Not Suited” branch fires immediately. If the Keap sequence it triggers does not exist, candidates receive nothing. Build and activate all sequences before the scenario goes live.
No error alerting. Scenarios fail. API rate limits get hit. Keap’s API returns a 500 at 11 PM on a Tuesday. Without an error alert, failed applications sit in limbo. Wire in the error notification before going live.

Expert Take

The most expensive mistake in pre-screening automation is not a technical one—it is treating the scenario as done after the first successful test. Production traffic surfaces edge cases that test data never hits: candidates who submit twice, candidates who use a different email than their application, form submissions with emoji in text fields. Build a 30-day monitoring cadence into the project plan. Review execution history weekly for the first month before moving to monthly reviews.

Scaling Beyond the Base Workflow

Once the three-branch qualification workflow is running cleanly in production, these extensions add measurable value without rebuilding the core scenario.

Add a Skills Assessment Integration

Connect a skills assessment platform (TestGorilla, Vervoe, or similar) as a fourth module in the Qualified branch. After creating the Keap contact and applying the Qualified tag, fire an HTTP POST to the assessment platform’s API to create a candidate and send the assessment link automatically. The candidate receives the assessment without any recruiter action.

Add a Duplicate Detection Layer

Before the Router module, add a Keap search that checks whether the contact’s email exists and whether a specific tag (e.g., “Applied — [Role Name]”) is already present. If the tag exists, route to a duplicate-handling branch that logs the reapplication without creating a new contact or triggering communications a second time.

Add a Recruiter Dashboard Feed

Use an HTTP module to post a summary of each processed application to a shared team channel or a Google Sheet used as a live dashboard. Each row includes the candidate name, role, qualification outcome, timestamp, and a direct link to the Keap contact record. Recruiters get a real-time feed without logging into Make.com.

Add AI-Assisted Soft Scoring

For the “Needs Review” branch, add a Make.com HTTP module that posts the candidate’s free-text responses to an AI API endpoint. The AI returns a structured evaluation—fit score, key strengths, potential concerns—that gets written to a Keap custom field and appended to the recruiter task created in Step 5. Recruiters enter each review decision with a pre-digested summary instead of raw text. For the full pattern behind AI-assisted Make builds, see AI-assisted Make builds vs. manual builds.

Frequently Asked Questions

Does this workflow require a developer?

No. Make.com’s visual builder handles every step described here without writing code. The HTTP modules used in advanced extensions require copying API documentation into the correct fields, which is a structured task, not programming. Teams with no technical background complete builds like this after a focused learning session—see the non-technical HR team automation case study for evidence.

What happens if Keap’s API is down when a candidate submits?

Make.com retries failed operations automatically based on your scenario’s error handling configuration. With proper error handling (Step 7), a failed Keap API call triggers a retry queue and an alert notification to the scenario owner. No candidate data is lost—Make.com stores the webhook payload and retries the execution once the API recovers.

Can this workflow handle multiple open roles simultaneously?

Yes, with one scenario per role or with a role-routing layer at the top of a single scenario. The single-scenario approach uses a Router module before Step 4 that branches based on a “Role” field in the application form. Each role branch then has its own criteria filters and Keap tag set. Single-scenario architecture is more efficient but requires more careful maintenance when criteria change for one role without affecting others.

How does this comply with EEOC guidance on automated screening?

The scenario applies only the criteria you define explicitly—it does not infer, predict, or score on proxies. Every pass/fail decision is auditable from the Make.com execution history and the Keap contact record. Maintain documentation of every criterion, threshold, and routing rule as your compliance record. For a detailed review of AI and automation compliance requirements, see the EEOC AI compliance guide for HR teams.

How long does it take to build this workflow?

Four to eight hours for a three-branch workflow with no external integrations, as noted in the prerequisites. Teams using AI assistance to generate module configurations and filter logic reduce build time significantly. The Make scenario build guide using Claude shows how to accelerate the configuration steps specifically.