To build conditional logic in Make.com for Keap recruitment campaigns: map every funnel decision point in writing, verify Keap field data quality, add a Router module after your trigger, configure Filter conditions per branch, wire fallback routes, and test with live candidate bundles before activating the scenario.

What This Guide Covers — and What You Need Before You Start

Every recruiting funnel has decision points — moments where the right next step depends entirely on who the candidate is, what they submitted, and where they stand in the pipeline. Manual triage at those decision points inflates time-to-hire and degrades candidate experience. Conditional logic in Make.com™ eliminates manual triage by wiring those decisions into deterministic automated workflows connected directly to Keap.

This guide is one focused chapter inside a broader recruiting automation strategy. If you haven’t yet mapped your full automation approach, start with our guide on automating HR and recruiting to end manual data drain before building anything here.

Before you start, confirm the following prerequisites:

• Tools required: Make.com™ account (any paid plan), Keap account with API access enabled, a text editor or whiteboard for funnel mapping.
• Time required: 2–4 hours to map, build, and test a three-branch Router for a single trigger. More complex funnels require proportionally more time.
• Data prerequisites: The candidate fields you want to branch on — years of experience, certifications, job category, source tag — must already exist as Keap custom fields or tags. Conditional logic cannot branch on data that does not exist in the record.
• Risk: Misconfigured Filters silently drop candidate bundles. Every scenario built in this guide requires a fallback branch before it goes live.
• Skill prerequisite: You should be comfortable creating a basic Make.com scenario with a trigger and at least one action module. If you are not, review our walkthrough on how to build a Make scenario with Claude first.

For a broader view of what Make.com scenarios are and how they work, see our plain-English guide to Make scenarios.

Step 1 — Map Every Decision Point in Your Recruiting Funnel

Build your conditional logic on paper before you touch Make.com. Open a blank document and list every stage in your recruiting funnel from application receipt to offer. At each stage, identify every binary or multi-option decision a recruiter currently makes manually.

A decision point looks like this: “If the candidate has a PMP certification, move to the Senior Track sequence. If not, move to the Junior Track sequence.” Each “if / then” statement becomes one Router branch.

Common recruiting decision points that map cleanly to conditional logic:

• Qualified vs. unqualified based on required credentials or experience threshold
• Job category routing (technical vs. non-technical, exempt vs. non-exempt)
• Source channel (job board vs. referral vs. direct application) — different nurture tone required
• Pipeline stage transitions (phone screen passed vs. failed)
• Offer stage (accepted vs. declined vs. negotiating)

Circle every decision point where a human is reading data and choosing between two or three consistent outcomes. Those circles are your Routers. Mark any decision that requires reading tone, culture fit, or nuanced judgment — those stay human. According to Asana’s Anatomy of Work research, knowledge workers spend 60% of their time on work coordination rather than skilled work. Conditional logic reclaims that coordination time for the decisions only humans can make.

Output of Step 1: A written list of every Router you need, with the condition logic for each branch written in plain English before you open Make.com.

Step 2 — Structure Your Keap Data Signals

Make.com conditional logic branches on data. The quality of your branching is entirely determined by the quality and consistency of your Keap data. Before building any scenario, confirm that the fields you plan to branch on are populated reliably.

Tags are the strongest signal. A Keap tag is binary — present or absent — and Make.com can filter on tag presence with a single condition. Build your conditional logic on tags wherever possible.

To verify your data signals:

1. Open a sample of 20 recent Keap contact records for candidates at the stage you are automating.
2. Check that the field you plan to branch on (tag, custom field, pipeline stage) is populated on at least 90% of records. If it is missing on more than 10%, fix the data entry process before building automation — garbage in produces silent drops out.
3. Confirm the exact field name and data format Make.com will receive. A custom field named “Years of Experience” in Keap arrives in Make.com as a string, not a number. Plan your Filter operators accordingly (text “contains” vs. numeric “greater than”).

Parseur’s Manual Data Entry Report estimates that manual data entry errors cost organizations an average of $28,500 per employee per year in correction overhead. Conditional logic built on unreliable Keap data does not eliminate that cost — it automates the errors at scale. Fix the data first.

For a deeper look at what happens when automation runs on dirty data, see our breakdown of HRIS required fields vs. manual data validation and our guide on 7 questions to ask before you automate anything.

Output of Step 2: A confirmed list of Keap fields and tags your Filters will evaluate, with data format verified.

Step 3 — Build the Router in Make.com

With your funnel map and data signals confirmed, open Make.com and navigate to the scenario where you want to add conditional branching.

Add a Router Module

1. Click the + button after your trigger module (or after any module where you want branching to begin).
2. Search for Router and select it. The Router is a flow control tool built into Make.com — it is not an app integration.
3. The Router appears with one default branch. Each branch is a separate path the candidate bundle travels.

Add and Name Branches

1. Click the Router to open it. Click Add route for each additional branch you need.
2. Name each branch clearly inside the scenario notes panel. “Branch 1” communicates nothing six months from now. “Senior Track — PMP Certified” communicates everything.
3. Add the modules for each branch path — Keap update contact, send sequence, apply tag — according to your funnel map from Step 1.

Add Filters to Each Branch

A Router without Filters sends every candidate bundle down every branch simultaneously. Filters are the conditions that control which branch a bundle enters.

1. Click the small circle on the line connecting the Router to the first module in a branch. This opens the Filter configuration panel.
2. Set Condition 1 using the field from your Step 2 verification. Example: Keap Tag > Contains > “PMP-Certified”.
3. Use AND to stack additional required conditions on the same branch. Use OR to allow multiple conditions to qualify a bundle for the same branch.
4. Click OK to save the Filter. Repeat for every branch except the fallback (see Step 4).

Output of Step 3: A Router with named branches, each branch containing its downstream Keap action modules and a configured Filter.

Step 4 — Build a Fallback Branch for Every Router

This step is not optional. A candidate bundle that matches no Filter condition on any branch exits the Router and is silently discarded. In a live recruiting funnel, that means a real candidate receives no response and no follow-up, with no error logged anywhere in the scenario.

Every Router requires one branch with no Filter — the fallback route. Configure it as follows:

1. Add one final route to the Router. Do not add a Filter to this branch.
2. Add a Make.com Email module or a Slack/Teams notification module as the first action on this branch. Configure it to alert a recruiter: “Candidate [Name] did not match any routing condition. Manual review required.”
3. Optionally, add a Keap Apply Tag module to mark the contact as “Needs-Manual-Review” so it surfaces in your Keap pipeline view.
4. Do not add any sequence enrollment or pipeline advancement on the fallback branch. The fallback is a safety net — not a workflow path.

Output of Step 4: A fallback branch on every Router that alerts a human when no condition matches, and tags the contact for manual review in Keap.

Step 5 — Nest Routers for Multi-Level Decisions

Some funnel decisions are not flat — they are sequential. A candidate first routes by job category, then within that category routes by experience level. Flat Router configurations cannot handle this. Nested Routers can.

To nest a Router:

1. On the output of one Router branch — after its Filter passes — add a second Router module as the next step.
2. Configure the second Router’s branches and Filters for the second-level decision.
3. Add a fallback branch to the second Router as well. Every Router at every nesting level requires its own fallback.
4. Keep nesting depth to two levels maximum for scenarios you will maintain yourself. Three or more levels of nesting become difficult to read, debug, and document.

If your funnel logic requires three or more levels of nesting, that is a signal to restructure: break the scenario into two separate scenarios connected by a Keap tag trigger, rather than adding a third nesting level to a single scenario.

Output of Step 5: Nested Routers that handle multi-level candidate routing decisions, each with its own fallback branch.

Step 6 — Test With Real Candidate Bundles Before Activating

Never activate a scenario with conditional logic without testing every branch individually. Make.com’s test execution tools allow you to run a scenario with a specific input bundle and observe exactly which branches fire and which are skipped.

Test Protocol

1. Create a test contact in Keap with the exact field values and tags that should trigger Branch 1. Run the scenario manually. Confirm the test contact lands in Branch 1 and receives the correct Keap actions.
2. Modify the test contact to match Branch 2 conditions. Re-run. Confirm Branch 2 fires and Branch 1 does not.
3. Create a contact that matches no condition. Run the scenario. Confirm the fallback branch fires and the recruiter notification is sent.
4. Check the scenario execution history after each test run. Make.com logs every bundle’s path through the Router. Confirm the logged path matches the expected path for each test contact.
5. Test edge cases: a contact with multiple tags that match multiple branches simultaneously, a contact with an empty custom field, a contact whose field value is in an unexpected format (uppercase vs. lowercase).

For guidance on evaluating automation quality before production, see our checklist on how to evaluate a Make scenario before it goes to production.

Output of Step 6: A documented test log showing each branch fired correctly for its intended input condition, including fallback confirmation.

How to Know It Worked

After activating the scenario, monitor the following signals over the first 72 hours of live operation:

• Fallback branch volume: If more than 5% of candidate bundles are hitting the fallback, your Keap data quality is lower than your Step 2 verification indicated. Pause the scenario and investigate the data gap before continuing.
• Keap pipeline accuracy: Spot-check 10 candidate records per day. Confirm each record carries the tag and pipeline stage that corresponds to the branch it should have entered.
• Sequence enrollment confirmation: In Keap’s campaign reporting, confirm that only candidates matching the branch condition are enrolled in that branch’s sequence. No cross-contamination between tracks.
• Make.com execution history: Review the scenario execution log daily for the first week. Look for any incomplete runs, skipped modules, or unexpected errors. Make.com logs these at the bundle level, so you can trace exactly where a given candidate’s bundle stopped.
• Recruiter time audit: After two weeks of live operation, ask the recruiter who previously handled manual triage how many triage decisions they are still making manually. The target is fewer than 10% of the volume they handled before the scenario was activated.

Common Mistakes That Break Conditional Logic

• No fallback branch. The single most dangerous omission. Every Router, at every nesting level, requires a fallback. No exceptions.
• Branching on unverified data. If the field you are branching on is not reliably populated in Keap, the scenario silently drops candidates whose records are missing that field. Verify data completeness in Step 2 before building anything.
• Case-sensitive Filter mismatches. Make.com text conditions are case-sensitive by default. A tag of “PMP-Certified” does not match a Filter set to “pmp-certified”. Standardize your Keap tags in lowercase or uppercase, then match your Filters to that standard.
• Overlapping Filter conditions. If two branches have filters that can both be true for the same bundle simultaneously, Make.com sends the bundle down the first matching branch it evaluates and ignores the second. Design your conditions to be mutually exclusive.
• Activating without testing the fallback. Teams test the happy path branches and skip testing the fallback. The fallback is the first thing to test, not the last.
• Three-plus nesting levels in a single scenario. Deep nesting makes maintenance impossible for anyone who didn’t build the original scenario. Break complex logic into linked scenarios instead.
• Skipping the post-activation audit. Conditional logic that works correctly in testing can produce drift in production as Keap data quality changes over time. Schedule a monthly review of the execution history and fallback volume.

Frequently Asked Questions

What is the difference between a Router and a Filter in Make.com?

A Router splits one incoming bundle into multiple parallel paths. A Filter is a condition placed on one of those paths that determines whether the bundle is allowed to travel down it. Routers create branches; Filters control which branch a bundle enters. You need both to build conditional logic.

Can a candidate bundle travel down more than one Router branch at the same time?

Yes, if you configure it that way — and this is often unintentional. Make.com evaluates each branch’s Filter in order. If you want a bundle to match only one branch, design your Filter conditions to be mutually exclusive. If two Filter conditions can both be true for the same bundle, the bundle enters the first branch that matches.

What happens if a candidate’s Keap tag changes after the scenario runs?

Nothing, automatically. Make.com evaluates the Keap data at the moment the scenario triggers. A tag change after execution does not re-trigger the scenario. If you need to re-route a candidate after a tag update, build a separate scenario triggered by the “Tag Applied” event in Keap.

How many branches can one Router handle?

Make.com does not publish a hard limit on Router branches, but scenarios with more than six to eight branches on a single Router become difficult to read, document, and debug. If you need more than eight branches at one level, restructure using nested Routers or linked scenarios.

Is Make.com the right tool for this, or should I use a different platform?

Make.com is the right platform for this use case. Its Router and Filter architecture handles multi-branch conditional logic natively, its Keap integration is direct, and its execution history provides the visibility you need to audit candidate flow after activation. For a direct comparison, see Make vs. Zapier: A Straight Pricing and Feature Breakdown for 2026.

Do I need a developer to build these scenarios?

No. Routers and Filters are visual, no-code tools inside Make.com’s scenario builder. If you can follow the steps in this guide and have verified your Keap data, you can build and activate a conditional routing scenario without developer assistance. See our guide on how a non-technical HR team started building automations with Make and AI for a real-world example.

Additional Reading

• 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 Evaluate a Make Scenario Built by AI Before It Goes to Production
• How to Set Up Routed Error Handling in Make With AI Assistance
• 7 Questions to Ask Before You Automate Anything (The OpsMap Checklist)
• How a Non-Technical HR Team Started Building Their Own Automations With Make + AI
• HRIS Required Fields vs Manual Data Validation: Which Is Safer for Small HR Teams?
• Make vs Zapier: A Straight Pricing and Feature Breakdown for 2026
• 7 Things an AI-Built Make Scenario Gets Wrong (And How to Catch Them)
• Make.com FAQ: Everything Zapier Users Ask Before Switching
• How to Run an OpsMap Audit Before Automating Anything
• AI-Assisted Make Builds vs. Manual Builds (2026): Which Is Better for Your Automation?
• Automate HR & Recruiting: End the Manual Data Drain, Unlock Growth
• How HR Can Fix Broken Hiring Processes: Reducing Candidate Frustration Without Slowing Down the Business
• 5 Automation Tasks AI Handles Well — and 5 It Still Gets Wrong