A Make.com employee referral automation captures form submissions via webhook, validates the referrer against your active employee directory, creates a candidate record in your ATS, sends instant confirmations to both parties, logs every event to a tracking sheet, and fires the bonus trigger when a hire date is confirmed — without a single manual handoff.

Employee referral programs are the highest-ROI sourcing channel most companies run — and the most chronically undermaintained. Referred candidates convert to hires at two to three times the rate of job board applicants. They ramp faster and stay longer. But the programs that produce those results require a process that is fast, transparent, and consistent from submission to bonus payment.

Manual referral programs fail on all three counts. Slow acknowledgment emails, opaque bonus timelines, and recruiter inboxes that function as a black hole kill employee participation within 60 days of launch. The fix is not better communication — it is removing humans from every step that does not require human judgment.

This build connects your referral intake form, ATS, HRIS, communication platform, and tracking sheet into a single Make.com scenario that runs itself. Here is how to build it correctly.

What You Need Before You Build

Confirm every item below before opening Make.com. Missing one will stall the build during testing and cost more time than the prep would have.

• Make.com account — Core plan or higher. Multi-step scenarios with filters and routers require at minimum Core. A free trial handles the initial build and test cycle.
• ATS with API access. Your Applicant Tracking System needs a REST API or webhook endpoint that supports candidate creation and status updates. Most enterprise and mid-market platforms do. Confirm this before you design field mappings.
• HRIS directory access. You need to query active employee status by email address. An HRIS API, an Okta or Azure AD directory, or a maintained Google Sheet of active employees works for this check.
• Form tool with webhook output. Typeform, Jotform, Google Forms, or any form platform that fires a webhook on submission. This is the only employee-facing surface in the entire system.
• Slack, Teams, Gmail, or Outlook access. For automated notifications to referrers and recruiters.
• Google Sheets or equivalent. Every referral event gets logged here for quarterly analytics and bonus reconciliation.

Critical risk before you start: If your ATS does not support duplicate candidate detection via API, build a search-before-create pattern inside Make.com. Skip it and you generate duplicate candidate records within two weeks of launch.

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

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

Once the form is live, open Make.com and create a new scenario. 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 three test responses with different email addresses and confirm that every field value arrives in the Make.com trigger output exactly as expected — no missing fields, no encoding errors on special characters.

This data foundation drives every downstream step. Do not move to Step 2 until three clean test payloads are confirmed.

Step 2 — Validate the Referrer Against Your Employee Directory

Referral bonuses are for active employees. Before doing anything else with a submission, confirm the referrer email exists in your active directory.

Add an HTTP > Make a Request module and call your HRIS or directory API with the referrer email as the query parameter. If you use a Google Sheet as your directory, use the Google Sheets > Search Rows module instead.

After the lookup, add a Router module with two paths:

• Path A — Employee Confirmed: Referrer email returned a valid active employee record. Continue to Step 3.
• Path B — Not Found: Send the referrer a notification that only active employees qualify. Log the failed submission to a separate sheet tab for HR review. Stop the scenario here.

This filter keeps ineligible submissions from polluting your ATS and protects the integrity of your bonus tracking from day one.

Step 3 — Run a Duplicate Candidate Check in Your ATS

Before creating any new candidate record, search your ATS for the candidate’s email address. If the candidate already exists — from a prior application, a prior referral, or direct sourcing — you need to know before creating a duplicate.

Add an HTTP module that calls your ATS search endpoint with the candidate email. Return the candidate ID if a match exists, null if not. Add another Router with two paths:

• Path A — Candidate Exists: Update the existing record to attach the referral relationship and referrer information. Do not create a new record. Proceed to Step 4.
• Path B — New Candidate: Proceed to Step 4 to create the record fresh.

Step 4 — Create or Update the Candidate Record in Your ATS

On Path B from Step 3, add an HTTP POST module to your ATS candidate creation endpoint. Map the following fields from the webhook payload: candidate first name, last name, email, phone, applied role, referral source (hardcode “Employee Referral”), and the referrer’s employee ID or email.

On Path A, add an HTTP PATCH or PUT module to update the existing candidate record with referral attribution fields.

Capture the returned candidate ID from both paths using a Set Variable module. You need this ID for the logging step and for the bonus trigger in Step 7.

Error handling here is non-negotiable. Wrap both ATS modules in an error handler route. If the ATS call fails, route to a Slack or email alert to the recruiting team with the raw submission data so no referral disappears silently. A lost referral that never gets acknowledged destroys program credibility faster than any other single failure.

Step 5 — Send Confirmation Messages to the Referrer and Recruiter

Two notifications go out immediately after the ATS write confirms success.

Referrer notification: Send a message via Slack or email confirming the referral was received, naming the candidate and role, and stating the expected next touchpoint — for example, “You’ll hear from us within five business days on next steps.” Include the ATS candidate ID so the referrer has a reference number.

Recruiter notification: Send a structured message to the assigned recruiter’s Slack channel or email with the full referral details: candidate name, email, phone, role, referrer name, referrer employee ID, and a direct link to the ATS candidate record.

Both messages fire in parallel. Use two separate communication modules on the same branch — do not chain them sequentially unless the second message depends on confirmation from the first.

Step 6 — Log Every Event to Your Referral Tracking Sheet

Add a Google Sheets > Add a Row module at the end of the confirmed path. Log the following columns per submission: submission timestamp, referrer name, referrer email, referrer employee ID, candidate name, candidate email, role, ATS candidate ID, referral status (set to “Submitted”), and the Make.com execution ID for traceability.

This sheet is your source of truth for quarterly reporting, bonus reconciliation, and program performance analysis. Build it clean from day one. Adding columns retroactively after hundreds of rows exist is painful work.

Build a second row-update step for each downstream status change: candidate interviewed, offer extended, hire date confirmed. Those triggers feed into the bonus scenario in Step 7.

Step 7 — Build the Bonus Trigger Scenario

The referral bonus fires when the referred candidate reaches a confirmed hire date in your ATS. Build this as a separate Make.com scenario, triggered either by a webhook from your ATS on candidate status changes or by a scheduled polling check against your ATS API.

The bonus scenario logic runs in this order:

1. Receive the ATS event or run the scheduled status check.
2. Filter for candidates whose referral source is “Employee Referral” and whose status has moved to “Hired.”
3. Look up the referral record in your Google Sheet using the ATS candidate ID.
4. Confirm the referrer is still an active employee as of the hire date — run the same directory check from Step 2.
5. Update the Google Sheet row to “Bonus Eligible” and log the hire date and tenure check result.
6. Send a notification to the HR or payroll team with every field required for processing: referrer name, employee ID, candidate name, hire date, and applicable bonus amount per your program rules.
7. Send a Slack or email message to the referrer confirming the bonus is in queue.

The confirmation message to the referrer closes the loop. It is the single highest-impact moment in the entire program for sustaining future participation. Referrers who see their bonus acknowledged refer again. Referrers who hear nothing stop submitting.

What Good Looks Like After Launch

A well-built referral automation delivers three operational outcomes within the first 60 days:

• Submission-to-acknowledgment time drops to under two minutes. Referrers get an immediate confirmation. Recruiters get an immediate structured alert. Nobody wonders whether the form worked.
• Referral tracking is real-time. At any point in the quarter, you open the Google Sheet and see every submission, every status update, every bonus trigger. No spreadsheet archaeology before board meetings.
• Bonus timeline complaints disappear. When referrers know the exact trigger condition and receive confirmation that a bonus is in queue, the “where’s my bonus” conversation stops happening.

Map the Process Before You Build It

The most common reason this build stalls is not technical — it is undefined business rules. What happens if a referrer leaves the company between submission and hire date? What if the same candidate is referred by two employees within 30 days? What is the bonus structure for different role tiers?

Every undefined rule becomes a gap in the scenario logic. The OpsMap™ process surfaces those gaps before you write the first module. An OpsMap audit before any automation build is the single most effective way to prevent rework.

For how this referral automation fits into a broader HR operations approach, read 6 Ways the Make MCP Changes Automation Work for HR Teams and How a Non-Technical HR Team Started Building Their Own Automations With Make + AI. The OpsMesh™ framework — which structures automation across intake, routing, action, and follow-through — is what keeps a referral program from becoming a patchwork of disconnected tools with no visibility between them.

For broader context on what breaks upstream and downstream of this scenario, How HR Can Fix Broken Hiring Processes covers where the other manual handoffs live and what it costs when they stay manual.