How to Automate Employee Referrals with Make.com™: Step-by-Step HR Blueprint

Employee referral programs deliver higher-quality candidates, faster time-to-hire, and lower cost-per-hire than most other sourcing channels — but only when the process behind them is fast, transparent, and consistent. Manual referral programs fail on all three counts. Cumbersome forms, delayed acknowledgments, and opaque bonus timelines kill employee participation long before the program reaches scale.

This guide shows you exactly how to build a fully automated referral system using Make.com™ — from the moment an employee submits a name to the moment a bonus trigger fires in payroll. It’s one of the ten recruiting automation campaigns covered in the Recruiting Automation with Make: 10 Campaigns for Strategic Talent Acquisition pillar, and it’s the one that pays the fastest dividend when built correctly.

Before You Start

Before building any scenario, confirm you have the following in place. Missing even one item will cause the workflow to stall during testing.

• Make.com™ account with at minimum a Core plan (required for multi-step scenarios with filters and routers). A free trial covers initial build and testing.
• ATS API access — confirm your Applicant Tracking System exposes a REST API or webhook endpoint for creating and updating candidate records. Most enterprise and mid-market ATS platforms do.
• HRIS API or directory access — you need a way to query active employee status by email address. An HRIS API endpoint, an Okta/Azure AD directory, or even a maintained Google Sheet of active employees will work for this check.
• Form tool — Typeform, Jotform, Google Forms, or any form platform that supports webhook notifications on submission. This is your referral intake surface.
• Communication platform access — Slack, Microsoft Teams, or email (via Gmail or Outlook) for sending automated notifications to referrers and recruiters.
• Google Sheets or data warehouse — for logging every referral event so you have a clean analytics record at the end of each quarter.
• Time budget — plan two to three focused days for build, test, and deploy. The build itself is fast; most time goes to field mapping and test data validation.

Risk to know before you start: If your ATS does not support duplicate candidate detection via API, you will need to build that logic inside Make.com™ using a search-before-create pattern. Skip this and you will generate duplicate candidate records within two weeks of launch.

Step 1 — Build the Referral Intake Form and Capture the Webhook

The referral intake form is the only thing employees interact with. Keep it short: referrer name, referrer email, candidate name, candidate email, candidate phone, open role (dropdown tied to your active requisitions), and a brief relationship context field. Every additional field reduces completion rates.

Once your form is live, create a new scenario in Make.com™ and add a Webhooks > Custom Webhook trigger as the first module. Copy the generated webhook URL and paste it into your form tool’s webhook notification settings. Submit a test response and confirm Make.com™ receives the payload with all expected field values mapped correctly.

What to verify: Run three test submissions with different email addresses. Confirm that every field value appears in the Make.com™ trigger output exactly as expected — no missing fields, no encoding errors on special characters. This is your data foundation; errors here propagate through every downstream step.

Log each submission immediately by adding a Google Sheets > Add a Row module after the webhook trigger. Columns: timestamp, referrer name, referrer email, candidate name, candidate email, role applied for, status (default: “Received”). This log is your audit trail and analytics source for the entire program.

Step 2 — Verify the Referrer Is an Active Employee

This step stops ineligible submissions before they reach a recruiter. Without it, former employees, contractors, and external contacts can submit referrals that consume recruiter time before anyone flags the problem.

After the webhook trigger and log step, add an HTTP > Make a Request module (or your HRIS’s native Make.com™ module if available) that queries your HRIS using the referrer’s email address from the form. The query should return a status field indicating whether the employee record is active.

Add a Router module after the HRIS lookup with two paths:

• Path A — Active Employee: Filter condition: HRIS status equals “Active.” Proceed to Step 3.
• Path B — Ineligible Referrer: Filter condition: status is anything else or record not found. Send the referrer an automated email or Slack message explaining they are not currently eligible, update the Google Sheet row status to “Ineligible,” and stop the scenario.

Based on our testing: The HRIS lookup adds roughly five minutes to the build. It saves hours of recruiter cleanup every quarter and protects the integrity of your referral sourcing data.

Step 3 — Check for Duplicate Candidates and Route to ATS

Before creating a new candidate record, check whether the referred candidate already exists in your ATS. This prevents duplicate profiles and the data quality problems that follow. To automate talent acquisition data entry cleanly, a search-before-create pattern is non-negotiable.

Add an ATS search module (or HTTP > Make a Request to your ATS search API endpoint) using the candidate’s email address as the query parameter. Add a second Router with two paths:

• Path A — Candidate Not Found: Create a new candidate record in the ATS. Required fields: candidate name, email, phone, source (“Employee Referral”), referring employee name and email, and the target role. Map these directly from the webhook trigger output.
• Path B — Candidate Already Exists: Update the existing candidate record to log the referral (append referral source and referrer details to the notes field), and flag for recruiter review. Do not create a duplicate record.

In both paths, update the Google Sheet row with the ATS candidate ID and a status of “ATS Logged” so your analytics record stays synchronized.

After ATS routing, send the referrer an immediate confirmation via email or Slack. The message should confirm receipt, name the role, and give a realistic timeline for next steps. This single message significantly reduces the “did my referral go through?” follow-up emails that consume recruiter time in manual programs.

Step 4 — Automate Stage-Based Notifications to the Referrer

The referrer’s engagement drops sharply after submission if they hear nothing. Stage-based notifications solve this — and they drive higher repeat referral rates by making employees feel like participants in the process rather than one-time form submitters.

This step requires a trigger from your ATS when a referred candidate changes pipeline stages. Most ATS platforms support outbound webhooks on candidate stage changes. Configure your ATS to send a webhook to a new Make.com™ scenario (or a new route in the existing scenario) whenever a candidate with source “Employee Referral” moves to a new stage.

Build a Router with notification paths for each key stage:

• Under Review: “Your referral [Candidate Name] is being reviewed by our team.”
• Interview Scheduled: “Great news — [Candidate Name] has been invited to interview for [Role].”
• Offer Extended: “An offer has been extended to [Candidate Name]. Stay tuned for the next update.”
• Hired: “Congratulations — [Candidate Name] has joined the team. Your referral bonus will be processed shortly.” (This also triggers Step 5.)
• Not Moving Forward: “We’ve decided not to move forward with [Candidate Name] at this time. Thank you for the referral — keep them coming.”

Personalize each message with the candidate’s first name, the role, and the referrer’s first name pulled from your ATS or the original log entry. Generic notifications get ignored. This connects directly to automating recruiter follow-ups — the same principles that improve candidate experience apply to your internal referrers.

Update the Google Sheet status column at each stage change. By the end of the program’s first quarter, this log gives you a full referral-to-hire funnel with timestamps on every transition.

Step 5 — Trigger the Referral Bonus Workflow on Hire

The bonus trigger is the step most teams either skip or bury in a manual process — and it’s the one that determines whether employees refer again. Research from SHRM consistently identifies delayed or opaque bonus payouts as the primary reason employees disengage from referral programs after their first submission.

When the ATS fires a “Hired” stage-change webhook, your Make.com™ scenario should execute the following automatically:

1. Retrieve referrer details from the Google Sheet log using the ATS candidate ID as the lookup key.
2. Verify bonus eligibility — confirm the referrer is still an active employee via a second HRIS lookup. Employees who have since left the company are typically ineligible under most referral bonus policies.
3. Create a bonus request record in your HR or payroll system using an HTTP module or native integration. Include: referrer name, referrer employee ID, candidate name, hire date, and role. Flag it for the next payroll cycle.
4. Notify the referrer immediately — send a Slack message or email confirming the hire and the bonus submission. Even if payment clears in the next payroll cycle, the immediate notification closes the loop and builds trust in the program.
5. Notify HR or payroll team — send an internal Slack message or email to the responsible team with a summary of the bonus request for their records.
6. Update the Google Sheet — log hire date, bonus submitted status, and date of notification. This row is now your complete audit trail for one referral from submission to payout.

If your payroll system does not support API-based bonus request creation, the scenario can instead generate a pre-filled Google Form or email notification that your payroll team processes manually — still eliminating the lag of identifying the referrer and compiling the details from scratch.

How to Know It Worked

A functioning automated referral system produces three observable signals within the first two weeks of operation:

• Zero orphaned referrals in your spreadsheet log. Every submitted referral has an ATS candidate ID, a referrer verification status, and at least one notification timestamp. If any row is missing these, a scenario branch is broken.
• Referrers confirm receipt without prompting. When employees mention receiving an instant confirmation after submitting a referral, the intake and notification paths are working. When you still receive “did my referral go through?” emails, the confirmation step has a bug.
• Stage notifications fire within five minutes of ATS stage changes. Test this manually by moving a test candidate through stages in your ATS and checking that Slack or email notifications arrive promptly and contain correct personalization fields.

At the 90-day mark, pull your Google Sheet log and calculate: total referrals submitted, referrals that passed HRIS verification, referrals that reached interview stage, referrals that resulted in hires, and average days from submission to hire-stage notification. These are your baseline metrics. Compare them quarter over quarter to measure program health. This connects to the broader practice of exporting recruiting insights for data-driven decisions.

Common Mistakes and How to Fix Them

Mistake 1 — Skipping the HRIS Verification Step

Teams that skip Step 2 because it “adds complexity” spend hours every quarter auditing ineligible referrals that made it into the ATS. Build the HRIS lookup from day one. The five-minute build investment returns itself within the first week of program operation.

Mistake 2 — Using a Generic Confirmation Message

An automated confirmation that reads like a system-generated receipt (“Your referral has been received”) signals to employees that their submission entered a black hole. Use the candidate’s name, the role, and the referrer’s first name in every message. Make.com™ has all three values from the webhook trigger — use them.

Mistake 3 — Building Notifications Without an ATS Stage-Change Webhook

If your ATS does not support outbound webhooks natively, you cannot trigger real-time stage notifications without polling — which means scheduled scenario runs every 15-60 minutes that query the ATS for stage changes. This works but introduces lag. Check your ATS webhook support before committing to a real-time notification architecture. If polling is your only option, set the schedule interval as short as your plan allows and communicate that to stakeholders so expectations are accurate.

Mistake 4 — Letting the Bonus Workflow Become a Manual Exception

The most common reason bonus automation fails is incomplete payroll API access — teams discover their payroll system doesn’t expose a bonus-request endpoint and shelve the automation entirely. The fix is a fallback: even if the payroll API isn’t available, automate the internal notification to the payroll team with all required data pre-populated. Remove the research burden from payroll even if you can’t remove the human action.

Mistake 5 — No Deduplication Logic

Without a search-before-create check in Step 3, you will generate duplicate ATS records. Duplicate records corrupt your source-of-hire reporting and create compliance risk in jurisdictions with data minimization requirements. This check is not optional — build it in Step 3 exactly as described.

Scale This System Further

Once the five core workflows are stable, three extensions add meaningful value without significant build time:

• Referral leaderboard: A Google Sheet summary that calculates each employee’s referral count, interview rate, and hire rate, shared monthly via Slack to the whole team. Visibility drives participation.
• Role-specific referral campaigns: When a hard-to-fill role opens, trigger an automated Slack or Teams message to relevant department channels with a direct referral form link pre-populated with that role. This connects to automating your recruitment CRM integration so campaign performance flows back into your sourcing data.
• Referral quality scoring: After 60 days, add a step that calculates each referral’s quality score (reached interview = 1 point, received offer = 2 points, hired = 3 points) and updates the referrer’s running total in a Sheets dashboard. Use this to identify your best talent scouts for recognition or higher bonus tiers.

For teams ready to apply the same automation discipline to candidate evaluation, pre-screening automation to filter candidates fast is the natural next workflow to build alongside referral intake. And when referred candidates reach the offer stage, automating offer letters for faster hiring closes the loop on the full referral-to-hire journey.

The goal throughout is the same one that anchors the parent pillar: treat hiring speed as a process problem, not a technology problem. The five workflows in this guide solve the process. Make.com™ executes it. And your workforce — already your most credible talent scouts — finally has a referral experience that deserves their continued participation. To cut time-to-hire with Make.com™ workflows across every sourcing channel, the referral program is the highest-leverage place to start.