Bullhorn Workflow Automation Setup: A Practical Guide

Most Bullhorn workflow automation setup problems are not caused by Bullhorn being difficult to use. They are caused by configuration decisions made in the wrong order. Someone builds a five-step email sequence before they have checked whether the list it runs on is actually populated. Someone picks the wrong automation type because the distinction between the two looks minor in the UI. Someone accepts the default re-entry settings and spends three weeks wondering why candidates are receiving duplicate emails. The decisions compound. Get the early ones wrong and the later ones do not matter. This guide works through the setup sequence in the order the decisions actually need to be made.

Standard vs Centre on Date Field: Choosing the Right Automation Type

This is the first decision in any bullhorn workflow automation setup and the one most often made by instinct rather than logic. Standard automations trigger when a record joins a list - the sequence fires from that moment and steps run forward in time from entry. Centre on Date Field automations anchor to a date value stored on the record and calculate step timing relative to that date, so you can send an email 30 days before a specific date or on the day itself.

A candidate re-engagement sequence is the right place for Standard automation. The trigger is list membership - the candidate has been inactive for 180 days and joins the list. From that point, steps run on day 4, day 10, day 17, day 25. The timing is relative to when the record entered, not to any date on the record.

A compliance renewal reminder is the right place for Centre on Date Field. You have a right-to-work document expiry date on the candidate record. You want reminders at 30 days before, 7 days before, and on the day. Centre on Date Field recalculates continuously relative to that date field - the timing stays accurate even if the record was loaded into the system late.

The failure mode I see repeatedly: someone builds a compliance reminder using Standard automation, sets the list entry criteria to fire when the document expiry date is within 30 days, and then finds that reminders arrive late or not at all. The problem is that Standard automation evaluates list membership at the point of entry. If the list is not refreshing frequently enough, or the record meets the criteria only briefly before the expiry window passes, the timing slips. Centre on Date Field does not have this problem because it recalculates against the date itself.

The secondary failure mode with Centre on Date Field: if the date field is sparsely populated, a large proportion of your intended audience silently never enters the automation. If 40% of your candidate records have a blank availability date, 40% of your intended audience will not receive a single step. No error is thrown.

Record Types and Why Getting This Wrong Breaks Everything

Bullhorn's automation builder asks you to select a record type before you build anything else. The main options are Candidate, Contact, Lead, Placement, and Submission. The record type you choose determines which fields are available for list logic, which merge fields you can use in email copy, and what exit criteria you can set. Change it later and you rebuild from scratch.

The most common mistake I come across is building candidate re-engagement automations on the Contact record type. Candidates and Contacts are separate objects in Bullhorn. A Contact-based automation cannot reliably pull candidate-specific merge fields - availability date, skills, last placed date - without those fields being explicitly mapped across. In practice, the email either sends with blank gaps where the merge fields should be, or it fails to send at all. The list logic also silently pulls from Contact data rather than Candidate data, which means the audience you intended and the audience you are actually reaching are different.

Before building any automation, run the field you intend to use in your list logic as a manual list filter on that record type. If the field does not appear in the filter options, or appears but returns no data, the record type is wrong. That check takes two minutes and saves you from diagnosing a broken campaign after it has already sent.

Placement record type is the right choice for onboarding sequences that fire when a placement is created. The timing logic - start date, end date, pay rate - lives on the Placement object, not the Candidate object. Build it on Candidate and you cannot reliably reference start date without custom field mapping, which most instances do not have set up.

The Submission record type is worth flagging separately because it sits between Candidate and Placement in the workflow and is frequently ignored. Automations built on Submission can target candidates at a specific point in the recruitment process - after an application, before an interview, after a rejection - rather than operating on the full candidate pool. If your current setup has nothing running on Submission records, there is probably an opportunity being missed.

List Management Before You Build Anything

Treat list logic as a data audit, not a configuration task. The automation is only as useful as the list it runs on, and in most Bullhorn databases I have worked with, the fields most commonly used in list logic are the most inconsistently populated ones.

Dynamic lists update automatically based on whether records meet the criteria at the point of evaluation. A record joins when the criteria become true and leaves when they no longer are. Static lists are manually curated and do not change unless edited. For most automations, dynamic lists are correct - but the re-entry behaviour of the automation determines what happens when a record leaves and rejoins, which I will cover in the next section.

Before building, run the list manually and check two things: the record count, and the field population rate for every field in your entry criteria. If you are building entry criteria on availability date and 60% of your candidate records have that field blank, your automation will reach at most 40% of the intended audience. That is not a configuration problem you can solve inside the automation builder - it is a data problem that has to be fixed first.

The specific fields in most Bullhorn databases that are worth auditing before you build:

• Availability date - frequently blank or set to a date that has long passed and was never updated after a placement ended.

• Candidate status - often still set to Active for candidates who placed two years ago, left the industry, or have been completely unresponsive for an extended period.

• Last activity date - depends heavily on whether the Bullhorn instance has consistent user behaviour around logging activity. If consultants are not logging calls and emails in Bullhorn, this field is meaningless as a list criterion.

Two specific failure modes to watch for. The first is phantom entry: a record joins the list because a field was set correctly at import, the automation fires, but the value was a data entry error. The candidate receives a "we haven't heard from you in a while" email the week after they started a placement. The second is silent under-reach: list criteria reference a field that is sparsely populated, the automation runs, reporting shows sends, but the actual audience is a fraction of what was intended. No error is thrown. You have to cross-reference list size against your expected audience size manually to catch it.

Re-entry Settings: The One Configuration Most People Get Wrong

Re-entry determines what happens when a record leaves the entry list and later rejoins. If re-entry is enabled, the record starts the sequence again from step one. If it is disabled, the record is excluded from subsequent passes regardless of how many times it meets the entry criteria in the future.

There is a separate toggle for duplicate prevention, and these two settings are not the same thing. Re-entry controls whether a record can run through the sequence a second time after completing or exiting the first pass. Duplicate prevention controls whether a record can be in the same sequence on two simultaneous passes. Both need to be configured deliberately, because the defaults in Bullhorn Automation lean permissive - do not accept them without reviewing the specific use case.

Here is the scenario I have seen cause the most confusion. A candidate reactivation sequence has re-entry enabled, which is correct - a candidate who goes cold again after six months should re-enter the sequence. But duplicate prevention is off. A candidate's availability date gets updated and then reverted within the same list refresh cycle. They drop off the list and rejoin before completing the first sequence. Now the same candidate is receiving the same five-step email sequence simultaneously on two passes. Every email arrives twice, staggered by however many days separated the two entry points.

The way to audit for this after the fact: pull the send report for the automation and filter by individual contact. If any contact has received the same email more than once and the gap between sends is shorter than the full sequence duration, you have a duplicate pass problem. There is a secondary reporting consequence as well - open rates and click rates look inflated because the same person appears as two contacts in the denominator.

For a reactivation sequence: re-entry enabled, duplicates disabled. A candidate must complete or exit the current pass before starting again.

Building a Candidate Reactivation Sequence: End-to-End Example

This is a complete worked example of a bullhorn workflow automation setup for candidate reactivation. The decisions at each step follow from the sections above.

Record type: Candidate.

Automation type: Standard. The trigger is list membership at a point in time, not a specific date on the record.

List entry criteria: last activity date greater than 180 days AND candidate status = Active. Last activity date alone will catch candidates who have been in the system a long time but were placed recently - the status filter removes candidates who have already been closed out. Worth auditing both fields for population before activating, for the reasons covered above.

The five steps:

• Day 0 - Initial re-engagement email. Short, personal tone. Asks whether the candidate is still open to opportunities. No hard sell.

• Day 4 - Follow-up if no open on step one, or a value-add email (market update, salary guide) regardless of open status. The value-add route avoids the sequence feeling like a chase.

• Day 10 - Specific opportunity prompt. Worth noting a real limitation here: Bullhorn Automation cannot dynamically reference live job inventory in email copy. You cannot pull in live vacancy titles or locations from the jobs database. This step is typically a prompt to visit the candidate portal or call in, rather than a genuine personalised job match. If you need live job matching in automated email copy, that requires external tooling.

• Day 17 - Soft opt-down. "If you would rather not hear from us for a while, let us know." Reduces unsubscribe risk and serves a compliance function if you are operating under an opt-in model.

• Day 25 - Final touchpoint. If there has been no engagement across the full sequence, an exit action updates the candidate status to a dormant or equivalent value. That removes them from the Active pool and prevents them re-entering indefinitely.

Exit criteria: candidate submits to a job, candidate status changes to Placed, or candidate replies to any email. The reply trigger requires monitoring outside the automation unless you have a two-way email integration in place - native Bullhorn Automation does not close the loop on replies automatically.

Re-entry: enabled. Duplicates: disabled.

Send time rules: business hours only, Monday to Friday, 8am to 6pm. The time zone setting matters here - more on that in the next section.

Staggered Starts and Send Time Rules: What the Docs Do Not Tell You

For lists above 500 records, sending the first step of a sequence in a single burst creates a deliverability spike. If your sending domain has a low send volume baseline - which is common for agencies that have only recently started using Bullhorn Automation - a sudden burst of 1,000 sends in a few minutes is enough to trigger spam filters and damage deliverability for subsequent campaigns.

Staggered start spreads the batch across a time window. If you have a list of 1,200 candidates and you want to spread the first step across an 8-hour working day, you are targeting roughly 150 sends per hour or about 2.5 per minute. Configure the stagger in blocks of minutes per batch size rather than trying to hit an hourly rate exactly - Bullhorn's stagger setting works in intervals, not hourly buckets.

Send time rules and stagger interact in a way the documentation does not make obvious. If your stagger calculation pushes the final batch past the end of your configured send window - say sends are allowed 9am to 5pm and your stagger runs for 10 hours - the remaining sends queue for the next available send window. Most people assume the queue carries over cleanly to 9am the following morning. Whether it does depends on how the automation was configured, and I would not assume it without testing.

The 3am send problem is worth naming specifically. UK-based agencies on US-provisioned Bullhorn instances - Eastern or Central time zone, both common - frequently encounter this. The send time rule is set to business hours, but the time zone on the automation is defaulting to the instance time zone rather than UK local time. "9am EST" is correct from the system's perspective. From the candidate's perspective, the email arrives at 2am or 3am UK time. The fix is to check the time zone setting on the automation explicitly before activating. It is not a difficult fix, but it is not flagged during setup and it catches people out regularly.

What I would do before any activation on a list above 200 records: run a test activation on a list of 5 to 10 internal test records first. Check send times, check merge fields, check that exit criteria fire correctly. It takes 20 minutes and it is worth it every time.

Where Bullhorn Automation Ends and External Tools Begin

For most recruitment agencies running standard candidate and client comms, Bullhorn Automation is sufficient if configured correctly. The capability gap only becomes meaningful in specific situations.

Conditional branching on field values: Bullhorn Automation supports yes/no branching on email opens and clicks. It does not support branching on field values - you cannot say "if candidate status changed to X during the sequence, take path A; if it changed to Y, take path B." If your use case requires that kind of logic, Bullhorn Automation cannot deliver it natively.

Multi-system triggers: Bullhorn Automation operates entirely within Bullhorn's data. If you need a placement creation to simultaneously create an onboarding record in a project management tool, update a contact in HubSpot, or send a Slack notification to the compliance team, that is not something Bullhorn Automation can handle. It requires a middleware layer.

Field visibility limitations: not all field types on all record types are available as list criteria or automation triggers. Custom fields and some system fields do not appear in the list builder. If the field you need for your use case is not available in the automation interface, you have hit a capability wall that cannot be worked around inside Bullhorn.

Where n8n fits into this is as a workflow layer that operates outside Bullhorn's automation engine. The architecture is straightforward: a Bullhorn event triggers an n8n workflow via API or webhook, n8n evaluates field values and conditions in the workflow layer, and n8n executes actions across whatever systems are connected. That might be HubSpot, a compliance tool, a Slack channel, or a document generation system. It is not a replacement for Bullhorn Automation for straightforward email sequences - it is the layer that handles logic Bullhorn Automation cannot.

If you are unsure which of these issues are already live in your current setup - whether that is a re-entry configuration problem, a record type mismatch, or a list population issue quietly limiting your reach - the Revenue Audit at stacklogic.co.uk/services is the right starting point. It looks at what is actually configured, what the data looks like in practice, and where the gaps are before any further build work starts.