Make automation for recruiting: 3 branching scenarios (enrichment, dedupe, refresh) with retries + suppression

Last updated: August 31, 2026

Ben Argeband, Founder & CEO of Heartbeat.ai — simple, stepwise, no jargon.

Who this is for

You’re running recruiting ops, or you’re the recruiter who also owns ops. You want automations that branch, retry, and keep your ATS/CRM clean without babysitting every run. This is written for ops-minded recruiters who’ve outgrown basic linear automations and need real conditional logic.

Scope: three Make scenarios built around Heartbeat.ai’s API for enrichment, dedupe, and scheduled refresh, with explicit consent and opt-out gates at every step.

Quick Answer

Core Answer

Build three Make scenarios: enrich via API, dedupe using NPI/license matching, and schedule refresh runs with retries and suppression gates.

Key Insight

Make earns its complexity when you need conditional routing, error handling, and scheduled refresh so recruiters stop working stale or duplicated records.

Best For

Ops-minded recruiters who want more control than basic linear automations provide.

Compliance & Safety

This method is for legitimate recruiting outreach only. Always respect candidate privacy, opt-out requests, and local data laws. Heartbeat does not provide medical advice or legal counsel.

Framework: branching workflows without code

Recruiting automation tends to fail for the same handful of reasons: duplicate records, stale contact fields, and one-size-fits-all write-backs that overwrite good data with weak matches. The fix is routing — different actions for different confidence levels, with suppression checked before anything downstream fires.

The core loop looks like this:

• Access: pull the minimum identifiers needed to match the right person.
• Refresh: re-check on a schedule so contactability doesn’t decay.
• Verify: only overwrite fields when the match is strong (NPI/license).
• Suppress: enforce consent/opt-out before any downstream action.

The trade-off: you spend more time up front designing match rules and branches, but you stop paying the ongoing tax of recruiter cleanup and duplicate outreach.

Step-by-step method

Below are three Make scenarios covering the workflows most recruiting teams actually need — enrichment, dedupe, and refresh — each with branch conditions, retry logic, and suppression checkpoints.

Step 0: Decide your identifiers and your “golden record” rules

• Primary match keys: NPI and license matching (state + license number) when available.
• Fallback match keys: normalized full name + specialty + city/state, used only when NPI/license is missing.
• Golden record: define which system wins on conflicts — ATS, CRM, or upload — and write it down.
• Suppression source of truth: decide where consent and opt-out status live, and which field(s) Make checks on every run.

Field mapping (minimum viable)

This is the simplest mapping that keeps your workflow debuggable and safe.

• Inputs to the API lookup: send what you have, preferring stable identifiers — NPI, license state + number, full name, specialty, city/state.
• Outputs to store in ATS/CRM: match method (NPI, license, name-only), match timestamp, last checked, last verified, and automation outcome (enriched_high_confidence, enriched_review, suppressed, refresh_updated, refresh_no_change, refresh_failed).
• Write-back rule: overwrite contact fields only on NPI/license match; otherwise append and create a review task.
• Suppression fields: opt-out boolean and consent status must be readable by Make before any write-back or outreach action.

Scenario 1: Enrichment + routing + suppression gate

Goal: when a recruiter creates or updates a lead, enrich it via API, then route based on match confidence and compliance status.

Trigger: ATS/CRM “new lead” or “updated lead” event, or a Make webhook.

Modules and logic

1. Normalize input: standardize state abbreviations, trim whitespace, split full name if needed.
2. Suppression gate (hard stop): if opt-out is true or consent is missing per your policy, route to “Suppressed” and stop.
3. Heartbeat.ai API lookup: search using the best available identifiers, preferring NPI/license and falling back to name + location.
4. Router: match confidence — Branch A (high confidence): NPI or license match with name alignment writes enriched fields back. Branch B (medium confidence): strong name + specialty + geography alignment without NPI/license writes limited fields and creates a review task. Branch C (low confidence): multiple possible matches or missing key fields creates a review task only, with no overwrite.
5. Audit log: store match method, timestamp, and which fields were updated.

Example router condition: if NPI is present and the match method equals NPI, route to Branch A. If match method equals name-only, route to B or C depending on how many candidates were returned.

Retry logic: on transient API failures (timeouts, 5xx errors), retry with increasing backoff, then route to an ops queue after the final attempt. On “no match,” don’t loop retries immediately — let Scenario 3 re-check once you’ve collected better identifiers.

Scenario 2: Dedupe workflow using NPI/license matching

Goal: prevent duplicate records across ATS/CRM/uploads so recruiters don’t double-contact the same clinician and opt-out rules don’t get missed.

Trigger: scheduled nightly run and/or a “new record created” event.

Modules and logic

1. Pull candidate set: fetch records created or updated within your chosen window.
2. Compute dedupe keys: NPI (key 1), license state + number (key 2), normalized full name + city/state + specialty as fallback (key 3).
3. Router: dedupe decision — Branch A: matching NPI across records merges/links, keeping the most recently verified contact fields. Branch B: matching license merges/links, treating license fields as authoritative. Branch C: name-only collisions do not auto-merge; a review task links both records.
4. Write back + audit: update a “dedupe status” field and attach a note describing what matched, what changed, and when.
5. Suppression propagation: if any merged record is opt-out, propagate that status to the surviving record.

Retry logic: if a merge fails due to permissions, locked records, or API error, route to a manual merge queue with the dedupe keys and record URLs. Don’t repeatedly retry locked records — tag them and notify ops instead.

Scenario 3: Scheduled refresh workflow

Goal: refresh key fields on a schedule so recruiters aren’t calling dead numbers or emailing stale addresses.

Trigger: scheduled daily or weekly run, segmented by priority (hot pipeline vs long-term nurture).

Modules and logic

1. Select refresh cohort: records where “last verified” exceeds your threshold, excluding opt-outs.
2. Heartbeat.ai API refresh: request updated contact fields and verification metadata.
3. Router: change detection — Branch A: contact fields changed, so update ATS/CRM and log “refreshed.” Branch B: no change, so update “last checked” only. Branch C: conflicting identity signals create a review task without overwriting.
4. Suppression enforcement: re-check consent/opt-out before any downstream action that could trigger outreach.

Retry logic: retry transient failures with backoff; after the final failure, tag the record “refresh_failed” and re-queue for the next run. Rate-limit the scenario to avoid bursts that trip vendor limits.

Implementation notes

This section exists so ops can build and maintain these scenarios without guessing.

• Use a router for branching: route by match confidence (NPI/license/name-only) and by suppression status.
• Use an error handler for retries: catch API timeouts and 5xx errors, apply increasing delays, then route to an ops queue with the record URL and error summary.
• Use scheduling for refresh: run refresh by cohort — hot vs nurture — instead of refreshing everything at once.
• Set up monitoring and alerts: define what “failure” means (refresh_failed, merge_failed, API_error) and route those items to wherever ops actually works. Keep the payload minimal: record URL, error code, scenario step, timestamp.
• Keep an audit field: store match method, timestamps, and which fields were updated. Avoid copying sensitive payloads into free-text notes.
• Reference: Make’s official docs cover scheduling and error handling patterns in the Make help center.

Diagnostic table

Weighted checklist

Score each item 0–2. A high score usually means Make is worth the setup time.

• (2) You need branching based on match confidence (NPI/license vs name-only).
• (2) You need scheduled refresh runs, not just event triggers.
• (2) You need retries and error routing with audit notes.
• (2) You must enforce consent and opt-out before any downstream action.
• (1) You need to write back to multiple systems (ATS + CRM + upload).
• (1) You need dedupe logic that treats NPI/license as authoritative.
• (1) You can define a golden record rule for conflicts.
• (1) You have an ops owner who will maintain fields and mappings.

Interpretation

• 0–5: Start with Scenario 1 only — enrichment, suppression, audit.
• 6–10: Add Scenario 2 (dedupe) once your identifiers are consistently captured.
• 11–14: Add Scenario 3 (refresh) and formalize monitoring and alerts.

Outreach templates

These templates cover the handoff points your automation creates: review tasks, suppression stops, and recruiter-ready summaries. Keep them short so they actually get used.

Template 1: Review task (medium/low confidence match)

Title: Verify identity before outreach (missing or conflicting identifiers)

Body: Automation found possible matches but did not overwrite fields. Verify using NPI or license matching if available. If confirmed, mark “Verified” and re-run enrichment.

• Record link: [ATS/CRM URL]
• Match method attempted: [NPI | license | name-only]
• Next identifier to collect: [NPI | license state/number]
• Compliance: confirm consent and check opt-out before outreach

Template 2: Suppression stop notice

Title: Outreach blocked (suppression rule)

Body: This record is suppressed due to opt-out or missing consent per our policy. Do not contact. If you believe this is incorrect, escalate to ops with documentation.

Template 3: Recruiter-ready enrichment summary (high confidence)

Title: Enrichment complete (verified identifiers)

Body: Record updated using NPI/license match. Changes logged. Proceed only if not suppressed.

• Verified by: [NPI | license]
• Last checked: [timestamp]
• Audit note field: [field name]

Common pitfalls

• Overwriting on weak matches: without confidence branching, you’ll corrupt your ATS. Only overwrite on NPI/license matches; otherwise append and review.
• Suppression checked too late: put opt-out/consent checks at the top of the scenario and again before any downstream action that could trigger outreach.
• No audit trail: if you can’t answer “what changed and why,” ops will lose trust and shut the scenario off.
• Retry storms: blind retries can create duplicate updates. Use backoff and route to an ops queue after the final attempt.
• One scenario doing everything: separate enrichment, dedupe, and refresh so you can debug and ship changes without breaking the whole pipeline.

How to improve results

Automation only matters if it improves contactability and reduces wasted recruiter time. Measure it by tracking outcomes at each branch and tying them to outreach results.

Measurement instructions

1. Instrument every branch: write a field like “automation_outcome” with values such as enriched_high_confidence, enriched_review, suppressed, refresh_updated, refresh_no_change, refresh_failed.
2. Track outreach performance separately from automation health: Deliverability Rate (delivered/sent emails), Bounce Rate (bounced/sent emails), Connect Rate (connected calls/total dials), Answer Rate (human answers/connected calls), Reply Rate (replies/delivered emails).
3. Definition — automation branching: routing a workflow into different paths based on conditions (for example, NPI match vs license match vs name-only), with different actions per path.
4. Run a controlled comparison: have one team run refresh + dedupe for a set period while another stays manual. Compare bounce/connect/reply rates and recruiter time spent on cleanup.
5. Review the review queue weekly: if too many records land there, tighten match rules or collect NPI/license earlier in intake.

Workflow upgrades that usually pay off

• Identifier-first intake: add NPI/license fields to intake and make them required when possible.
• Segment refresh cadence: hot pipeline refreshes more often than long-term nurture.
• Centralize suppression: keep opt-out in one source of truth and have every scenario check it.

Legal and ethical use

Build compliance into the workflow so it doesn’t depend on memory. For jurisdiction-specific requirements, consult your counsel.

• Consent and opt-out: store them in explicit fields and check them before write-back and before any outreach action.
• Data minimization: store only what you need for the recruiting workflow; avoid copying sensitive data into free-text notes.
• Auditability: log match method, timestamps, and what fields changed.
• Human review for ambiguity: route low-confidence matches to a task instead of forcing an automated merge.

Evidence and trust notes

For how we think about data quality, verification, and responsible outreach, see our trust methodology for recruiting data.

Make implementation behavior — scheduling, error handling, modules — is documented in the Make help center.

If you’re implementing via Heartbeat.ai, start with the Heartbeat.ai API documentation. Keep suppression rules explicit in your system of record and enforce them in every scenario.

FAQs

What should I automate first in Make for recruiting ops?

Start with enrichment + suppression + audit logging (Scenario 1). It gives recruiters cleaner records without risking duplicate merges or noisy refresh runs.

What identifiers work best for dedupe in clinician recruiting?

Use NPI first, then license matching (state + license number). Use name-only matching only as a fallback and route collisions to review.

How do I prevent enrichment from overwriting good ATS data?

Branch by confidence and only overwrite on NPI/license matches. For medium confidence, append fields and create a review task. Always log what changed.

How do I handle API failures and rate limits in Make?

Use an error handler with backoff retries for transient failures, then route to an ops queue after the final attempt. Rate-limit scheduled refresh runs by cohort instead of refreshing everything at once.

Where should consent and opt-out checks live in the scenario?

At the top of the scenario (hard stop) and again before any downstream action that could trigger outreach. Treat suppression as a shared service so every workflow enforces the same rules.

Next steps

• If you’re starting from a spreadsheet, use upload a file to structure inputs before you automate.
• For ATS-specific patterns, see ATS enrichment workflows.
• When you’re ready to wire this into your stack, start free search & preview data and connect it to your Make scenarios.

About the Author

Ben Argeband is the Founder and CEO of Swordfish.ai and Heartbeat.ai. With deep expertise in data and SaaS, he has built two successful platforms trusted by over 50,000 sales and recruitment professionals. Ben’s mission is to help teams find direct contact information for hard-to-reach professionals and decision-makers, providing the shortest route to their next win. Connect with Ben on LinkedIn.