7 Make.com Automation Steps That Route Candidate Applications Into Keap Automatically

A Make.com™ webhook scenario routes every form submission directly into Keap in real time — creating or updating the contact, applying role and source tags, capturing the resume file link, and triggering a confirmation sequence. The result for Nick’s three-person firm: 150+ hours reclaimed per month and zero missed applications.

Why Manual Candidate Intake Breaks Small Recruiting Teams

Manual candidate intake is one of the highest-frequency, lowest-value tasks in recruiting operations. Every application that arrives through an online form creates the same sequence of decisions: open the submission, copy the data into Keap, file the resume, send the acknowledgment email, apply the right tag. Multiply that by 30–50 applications per week across a small team and you have a process consuming 15 hours per week — before a single recruiter conversation happens.

Nick’s firm placed candidates in light-industrial and warehouse roles. Volume was high, margin was thin, and speed-to-contact was the primary competitive lever. Before automation, the intake process looked like this:

• A recruiter received an email notification from the form provider.
• The recruiter opened the submission and manually typed contact details into Keap.
• The resume file was downloaded, renamed, and uploaded to a shared folder.
• A folder link was copy-pasted into a Keap contact note.
• The recruiter manually applied a source tag and a role tag in Keap.
• A confirmation email was sent manually — or forgotten.

Across three recruiters handling 30–50 applications per week, the cumulative drag was 15 hours per person per week. The cost was not just time — it was data quality. A transcription mistake on an email address meant a candidate never received their confirmation and, in several cases, was never followed up with at all. Gartner research on talent acquisition confirms that speed-to-contact is a primary driver of offer acceptance rates in high-volume recruiting. A two-to-four-hour intake lag was costing placements.

The fix was a single Make.com automation that even a non-technical recruiting team could own. This post documents every step — and the sequence matters. Skip one and the scenario breaks in production.

What Is the Scenario Actually Doing?

Before walking through each step, it helps to name the design principle: deterministic sequencing. Every application follows the same path, in the same order, without recruiter intervention. The scenario handles four cases cleanly:

1. New applicant — no existing Keap contact
2. Returning applicant — existing Keap contact, new role application
3. Applicant with a resume file attached
4. Applicant without a file (some mobile submissions skip the upload)

Before writing a single module, the team pre-configured Keap: custom fields for Role Applied, Availability, and Resume Link were created. A tag taxonomy was agreed on — source tags (Applied — Web Form), role tags (Role — Warehouse Associate, Role — Forklift Operator, etc.), and pipeline-stage tags (Stage — New Application). Without this groundwork, the Make.com™ scenario has nowhere clean to write. For a deeper look at how to structure that groundwork, see the guide to running an OpsMap audit before automating anything.

Step 1: Set Up the Webhook Trigger

A Make.com™ Custom Webhook module generates a unique endpoint URL. That URL gets pasted into the form provider’s webhook or integration settings. From that point forward, every form submission sends a structured JSON payload to Make.com™ in real time — no email polling, no scheduled checks. The scenario fires at the moment of submission.

This matters for speed-to-contact. In high-volume light-industrial recruiting, the difference between a two-minute response and a two-hour response is measurable in placement rate. A webhook-triggered scenario makes two-minute responses the default, not the exception.

If your form provider does not natively support webhooks, a Typeform, Jotform, or Gravity Forms integration module inside Make.com™ achieves the same real-time trigger without custom webhook configuration. The principle is identical: submission fires scenario, not a scheduled poll. For technical grounding on how this trigger type works, see what a Make scenario actually does in plain English.

Step 2: Run a Data Structure Test Before Mapping Anything

After connecting the webhook, run a test submission immediately. Make.com™ displays the full data structure — field names, data types, file URL format — before any mapping is attempted. This test-first protocol is not optional. It catches structural mismatches before they corrupt production data.

Common issues the test surfaces:

• Field names differ between what the form says and what the payload delivers (e.g., “phone_number” vs. “applicant_phone”)
• File uploads deliver a temporary URL that expires — requiring a different handling strategy than a permanent link
• Multi-select fields arrive as comma-separated strings rather than arrays, which breaks conditional logic downstream

None of these are blocking issues — but each requires a deliberate mapping decision. Making that decision with real payload data is far faster than debugging it after 50 live submissions have already written bad data into Keap. For a catalog of what goes wrong when this step is skipped, see 7 things a Make scenario gets wrong in production.

Step 3: Build the Duplicate Detection Router

A Keap “Search Contacts” module queries by email address. The router evaluates the result:

• If no match: route to the Create Contact branch
• If match found: route to the Update Contact branch

Skipping this step is the most common production error in intake automations. Without it, a candidate who applies twice — or whose webhook fires twice due to a network retry — generates two Keap contacts with split history. Every recruiter interaction gets recorded on one contact; every automated tag lands on the other. The cleanup burden is significant and entirely avoidable.

Deduplication upstream eliminates the problem entirely. The router adds one module and two branches to the scenario. It is the highest-value single addition to any intake workflow. Teams that build this themselves versus working with a Make partner frequently discover this gap only after corrupted data has already accumulated.

Step 4: Map Fields to Keap on Both Branches

Field mapping connects each webhook payload variable to its Keap counterpart. Both the Create and Update branches require complete mapping — the Update branch in particular is where lazy builds fail, because developers map all fields on Create but only map “new” fields on Update, leaving standard fields stale.

Full mapping for this scenario:

• First Name, Last Name, Email, Phone → standard Keap contact fields
• Role of Interest → Keap custom field “Role Applied”
• Availability → Keap custom field “Availability”
• Application Date → Keap custom field “Last Application Date”

On the Update branch, every field in this list gets remapped — not just the ones that “might have changed.” The scenario cannot know which fields changed. Write all of them on every update. The overhead is negligible; the data quality benefit is not.

For teams building this as their first Make.com™ scenario, building a Make scenario with Claude as a co-builder significantly shortens the mapping configuration step.

Step 5: Capture the Resume File Link

When a resume file is attached, the webhook payload includes a URL pointing to the uploaded file. That URL gets written to the Keap custom field “Resume Link” as part of the contact create or update operation.

Two handling cases apply:

1. Temporary URL (expires after a set period): Add a Make.com™ HTTP module to download the file and re-upload it to a permanent storage location (Google Drive, Dropbox, or S3). Write the permanent URL to Keap. This adds two modules but ensures the link does not break after 24 hours.
2. No file attached (mobile submissions): Use a filter or router branch that checks whether the file field is empty. If empty, skip the file-handling modules entirely and proceed to tagging. Do not let an empty file field cause the scenario to error out and drop the contact.

After implementation, every recruiter in Nick’s team could open a Keap contact, click the Resume Link field, and view the candidate’s resume without touching a shared folder, a file-naming convention, or a download. That single change eliminated a recurring source of friction in candidate review meetings.

Step 6: Apply Tags Automatically

Tag application uses Keap’s “Apply Tag” module, called once per tag. For this scenario, three tags fire on every new application:

• Source tag: Applied — Web Form
• Role tag: Derived from the “Role of Interest” field via a Make.com™ router or text parser that maps form values to tag names
• Pipeline stage tag: Stage — New Application

The role tag mapping step is where many builds get lazy. If the form offers a dropdown with ten role options, the scenario needs a router with ten branches (or a lookup table using a Make.com™ data store) that maps each form value to the correct Keap tag. Building this correctly at implementation takes 30 minutes. Fixing it after 500 contacts are tagged incorrectly takes considerably longer.

For teams managing large tag taxonomies across multiple open roles, the HR and recruiting automation glossary covers tag architecture terminology that helps align the scenario design with Keap’s data model.

Step 7: Trigger the Confirmation Sequence

The final module uses Keap’s “Add to Sequence” action to enroll the new contact in a pre-built confirmation sequence. For Nick’s team, that sequence sent an immediate acknowledgment email, a text message 30 minutes later if no email open was detected, and a recruiter task assignment 24 hours after application.

The sequence trigger fires regardless of which branch the contact routed through — new or returning applicant. Returning applicants receive a different sequence (one that acknowledges their prior application) via a second “Add to Sequence” module on the Update branch.

Before this step was automated, confirmation emails were sent manually — or not at all. In a two-to-four-hour manual intake window, candidates who had already submitted to three other firms were already in conversations elsewhere. The automated confirmation sequence, firing within seconds of submission, made Nick’s firm the first to respond on every application — a measurable competitive advantage in light-industrial recruiting where candidate supply is constrained.

What Nick’s Team Gained

Nick’s three recruiters were each spending 15 hours per week on intake before automation. Across the team, that was 45 hours per week — more than a full-time position — on tasks that required zero judgment. After the Make.com™ scenario went live, intake dropped to near zero recruiter time. The 150+ hours reclaimed per month went to sourcing, relationship-building, and placement activity.

Beyond the time recovery, three operational improvements compounded over the first 90 days:

1. Data quality: Every contact in Keap had complete, correctly formatted fields from submission one. No more transcription errors, no more missing phone numbers, no more role tags applied to the wrong contact.
2. Zero missed applications: The webhook fires on every submission. There is no inbox to miss, no email notification to overlook. If the form receives a submission, Keap receives the contact.
3. Faster first contact: The confirmation sequence firing within seconds of submission compressed the first-contact window from two to four hours to under one minute. In a market where speed-to-contact drives offer acceptance, this was a direct placement-rate lever.

For teams evaluating whether this build is worth the investment of setup time, the full ROI picture of recruiting automation provides context on how intake efficiency compounds across a hiring cycle. And for the broader framework Nick’s scenario fits into, see what OpsMesh™ is and how it structures automation engagements.

Common Mistakes That Break This Scenario in Production

Seven modules. Each one has a failure mode that teams encounter when building this for the first time.

• Skipping the test submission: Mapping without real payload data guarantees field-name mismatches that produce blank Keap contacts.
• Omitting duplicate detection: A single network retry on the form provider’s side creates duplicate contacts that take hours to merge manually.
• Incomplete Update branch mapping: Fields not mapped on Update remain stale on returning applicants — recruiters see outdated availability and phone numbers.
• Using temporary file URLs without re-uploading: Resume links break within 24 hours, leaving recruiters with dead links inside Keap contact records.
• Approximate role tag mapping: Form values that do not exactly match tag names result in untagged contacts that fall out of pipeline searches entirely.
• No error handler on the scenario: If Keap’s API returns a timeout, the scenario fails silently and the application is dropped. Add a Make.com™ error handler route that alerts the team and retries. See how to set up routed error handling in Make.
• Building before configuring Keap: Custom fields and tag taxonomy created mid-build result in inconsistent field IDs and tag names that require scenario rebuilds to fix.

Is This Build Right for Your Team?

This scenario fits teams with three characteristics: a consistent, structured application form; Keap as their CRM; and a volume of applications high enough that manual intake consumes measurable recruiter time. If your application form changes frequently, add a data structure test step that runs before each production deployment. If you are not yet on Keap, the webhook and router logic is platform-agnostic — the Keap modules swap out for whatever CRM your team uses.

If your intake volume is lower — under ten applications per week — the time investment in building this scenario likely returns value within the first month regardless. At 30–50 applications per week, it returns value in the first week. The question is not whether to automate intake. The question is whether to build this yourself or work with someone who has already solved the edge cases. See DIY automation vs. hiring a Make partner in 2026 for a clear decision framework.

For teams earlier in their automation journey who want to understand what Make.com™ can and cannot do before committing to a build, the Make.com FAQ for teams coming from Zapier answers the most common pre-build questions without the sales pitch.

Frequently Asked Questions

Does this scenario work with any form provider?

Make.com™ supports direct webhook integration with most major form providers — Typeform, Jotform, Gravity Forms, and others. If your form provider supports outgoing webhooks, the Custom Webhook module receives the payload directly. If it does not, Make.com™ has native integration modules for the most common platforms that achieve the same real-time trigger.

What happens if Keap’s API is down when a submission fires?

Without an error handler, the scenario fails and the application is dropped. The correct fix is a Make.com™ error route on the Keap modules that catches API failures, stores the payload in a data store or sends a Slack alert, and retries when the API recovers. This is a non-optional addition for any production intake scenario.

How does the scenario handle applicants who submit to multiple open roles?

The duplicate detection router finds the existing contact by email. The Update branch appends the new role tag without removing existing tags — Keap’s “Apply Tag” action adds without overwriting. The “Last Application Date” custom field updates to the most recent submission. The recruiter sees the full tag history on a single contact record.

Can Make.com™ handle PDF resume parsing, not just file link capture?

Make.com™ captures and stores the file link. Parsing the PDF content — extracting skills, experience, and education into structured Keap fields — requires an additional step: an HTTP module that sends the file to a document parsing API (such as Affinda or Sovren) and maps the returned structured data back into Keap. This is a separate scenario or an extended module sequence, not part of the baseline intake build described here.

How long does it take to build this scenario from scratch?

A Make.com™ practitioner with Keap familiarity builds this scenario in three to four hours, including the Keap pre-configuration step. Teams building for the first time, without prior Make.com™ experience, typically take eight to twelve hours across two or three sessions. Using AI assistance — such as building the scenario with Claude — compresses the first-build timeline significantly by generating module configurations from a plain-English brief.

Additional Reading

• What Is OpsMap? The Discovery Step That Prevents Automation Mistakes
• How to Run an OpsMap Audit Before Automating Anything
• What Is a Make Scenario? The Plain-English Guide for Zapier Users
• How to Build a Make Scenario With Claude: A Step-by-Step Walkthrough
• How to Set Up Routed Error Handling in Make With AI Assistance
• 7 Things an AI-Built Make Scenario Gets Wrong (And How to Catch Them)
• DIY Automation vs. Hiring a Make Partner in 2026: When to Do Each
• Make.com FAQ: Everything Zapier Users Ask Before Switching
• Recruiting Automation: Transforming Hidden Costs into Measurable ROI
• How a Non-Technical HR Team Started Building Their Own Automations With Make + AI
• What Is OpsMesh? The Framework That Structures Every 4Spot Engagement
• A Glossary of Key Terms for HR & Recruiting Automation
• 7 Questions to Ask Before You Automate Anything (The OpsMap Checklist)
• AI Recruitment Automation: TalentBridge Saves 150+ Hours Monthly
• How Nick Cut 6 Manual Handoffs From Proposal Generation With One Make Workflow