Most recruiters using Bullhorn have tried to automate candidate follow-up at some point. They build a sequence in Herefish, map out a few triggers, and watch the emails go out — only to hear back from candidates who felt like they were talking to a system rather than a person. The problem is not that Bullhorn email automation is broken. The problem is that bulk send logic and genuine personalisation are not the same thing, and the gap between them shows up in every reply rate worth measuring.

Bullhorn’s native automation handles volume well. What it does not handle well is context — the difference between a candidate who just had a second interview and one who went quiet after a voicemail three weeks ago. Those two people should not receive the same message on the same cadence, and no amount of mail-merge tokens fixes that without the right conditional logic sitting underneath.

This post covers how to build a recruitment email automation workflow that uses Bullhorn as the data layer, and Make.com or n8n as the middleware, to create follow-up sequences that branch by candidate stage, inject the right dynamic fields, and still pass through a human eye before anything sends.

Why Bullhorn’s Native Automation Alone Isn’t Enough for Personal Follow-Up

Bullhorn’s automation layer, built on Herefish, is genuinely useful for high-volume, low-context tasks: sending a confirmation when a candidate applies, triggering a survey after placement, nudging inactive records back into a workflow. The three pillars Bullhorn builds its automation case around — productivity, experience, and data health — are real, and the platform delivers on all three at a surface level.

The gap appears when you need context-awareness. Herefish operates on list logic: if a record matches a condition, it enters a sequence. What it cannot do cleanly is distinguish why a candidate is at a given stage, or adjust tone based on the last meaningful interaction. A candidate who just completed a second interview and a candidate who missed two calls occupy the same “active” status bucket in many Bullhorn setups. Send them the same templated follow-up and you have not improved the experience — you have automated a bad one.

The productivity gains are real. The experience gains require a layer of conditional logic that native Bullhorn automation does not provide out of the box.

The Follow-Up Automation Stack That Actually Works: Bullhorn + Make.com or n8n

The architecture is straightforward. Bullhorn acts as the data source and record-of-truth. Make.com or n8n sits in the middle as the workflow engine, handling branching logic, field mapping, and approval routing. Gmail, Outlook, or SendGrid handles the actual send.

How the layers connect

Make.com vs n8n: when to choose which

Use Make.com if your team has no developer resource and wants a visual, low-code build. The Bullhorn modules are pre-built and the scenario editor handles branching without writing expressions.

Use n8n if you want self-hosted infrastructure, lower per-operation cost at scale, or need custom JavaScript logic inside nodes. n8n requires slightly more technical comfort but gives you more control over data transformation.

Both tools support Bullhorn’s REST API and can handle the full workflow described in this guide.

Step-by-Step: Building the Trigger and Candidate Stage Branching Logic

Step 1: Set up the trigger

In Make.com, use the Bullhorn CRM — Watch Records module set to monitor the Candidate entity. Poll every 15 minutes for status field changes. In n8n, use the HTTP Request node on a scheduled trigger to query the Bullhorn REST API endpoint /query/Candidate with a filter on status and dateLastModified.

If your Bullhorn instance supports outbound webhooks, configure them under Admin > API to push status changes in real time rather than polling.

Step 2: Build the conditional branches

Route each record through a condition check based on candidate.status:

In Make.com, use the Router module with a filter on each branch. In n8n, use the Switch node with rules mapped to the same status values.

Step 3: Map Bullhorn custom fields to personalisation tokens

Pull these fields from the Bullhorn API response and store them as variables for use in your email template:

In Make.com, map these inside the Set Variable or Set Multiple Variables module before the email step. In n8n, use the Set node.

Writing Follow-Up Email Templates That Scale Without Sounding Robotic

The goal is not to hide the fact that an automation sent this message. The goal is to make the content accurate and relevant enough that the candidate does not care.

Template 1: Post-interview check-in

Subject: Quick update, {{firstName}}

Hi {{firstName}}, just wanted to check in after your interview for the {{jobTitle}} role. {{consultantFirstName}} is expecting feedback from the client by {{expectedFeedbackDate}} — we will be in touch the moment we hear anything. In the meantime, let us know if you have any questions.

Template 2: Post-voicemail follow-up

Subject: Tried to reach you, {{firstName}}

Hi {{firstName}}, {{consultantFirstName}} tried calling earlier and left a voicemail. We have a role that looks like a strong fit based on your background in {{candidateSpecialty}}. Reply here or call us back when convenient.

Template 3: Placement anniversary re-engagement

Subject: One year in — how are things going, {{firstName}}?

Hi {{firstName}}, it has been 12 months since you started at {{placementCompany}}. We would love to hear how things are going and make sure you are still in a good place. If anything has changed, {{consultantFirstName}} is available for a call this week.

The one subject line rule

Include the candidate’s first name or the specific job title — not both, not neither. Subject lines that reference one concrete, accurate detail consistently outperform generic ones. Generic subject lines signal automation immediately; a specific detail signals attention.

Adding a Human-Review Checkpoint So Nothing Embarrassing Gets Sent

Automation without oversight creates risk. A status field that was updated incorrectly, a consultant name that did not resolve, a placement anniversary for a candidate who left under difficult circumstances — any of these can produce an email that damages the relationship rather than maintaining it.

Building the approval step in Make.com

Insert a Webhooks — Wait for a Webhook Response module after the email is built but before it sends. This module pauses the scenario and posts the draft email content to a Slack channel using the Slack — Create a Message module. The Slack message includes the candidate name, the template used, the resolved subject line, and two buttons: Approve and Reject, each pointing to a unique webhook URL.

If the recruiter approves, the scenario resumes and the email sends. If they reject, log the decision as a Bullhorn note and close the scenario branch.

Building the approval step in n8n

Use the Wait node set to pause execution, then send the draft to Slack or Microsoft Teams using the relevant node. Wire the resume webhook URL into the notification message.

The 24-hour auto-approve fallback

Set the Wait module or Wait node timeout to 24 hours. If no response is received within that window, the workflow proceeds automatically. This keeps throughput high for recruiters who are travelling or in back-to-back calls, while still giving the team a meaningful window to catch errors. Flag auto-approved sends in the Bullhorn note so you can audit them separately.

Measuring Whether Your Automated Follow-Up Is Actually Working

Building the workflow is the easy part. Knowing whether it is working requires four specific metrics tracked consistently.

The four metrics

Logging outcomes back into Bullhorn

After every email send — whether approved manually or auto-approved — use the Add Note step in Bullhorn Automation, or a Bullhorn API POST request via Make.com or n8n, to write a note to the candidate record. Include the template name, send timestamp, and approval method. This keeps the ATS accurate and gives consultants full visibility when they open a record.

If you are thinking about how this kind of structured data logging fits into a broader automation strategy, the same principles apply across other candidate-facing workflows — including how CV parsing and candidate matching can feed cleaner data into the very fields your follow-up templates depend on.

Set a review cadence of 30 days for the first three months. Adjust one variable at a time — subject line, send delay, or template copy — and measure the effect before changing anything else.

Conclusion

Automating candidate follow-up in Bullhorn is not about removing the recruiter from the process — it is about making sure the right message reaches the right candidate at the right stage, without relying on memory or spare capacity. The stack described here is straightforward to build and maintainable without a dedicated developer. If you want to understand how this fits your current Bullhorn setup, our audit is a reasonable place to start.