Bullhorn ATS Automation in the UK: A Practitioner’s Guide
TL;DR: Bullhorn's native automation engine handles single-step rules well: a field update, a task, or one email triggered by a status or date change. Anything with branching logic, multi-step sequences, time delays, SMS or frequency capping needs Bullhorn Automation (formerly Herefish), a tool like Sense, or a custom API layer, all of which cost extra. The rules worth building first in a UK agency are Right to Work expiry alerts, an AWR week-10 review flag, an IR35 determination check, umbrella document chasing, and a 24-month GDPR archive rule. Almost every stalled Bullhorn automation project stalls on data rather than on the rule builder, so if the trigger field is populated on fewer than 80% of records, fix that before you build anything.
It covers the native automation engine, UK compliance workflows, candidate re-engagement sequences, industrial staffing communications, job board and payroll integrations, GDPR obligations, and when to bring in outside help. Where relevant, I'll call out the specific failure modes I see repeatedly - because the most expensive Bullhorn automation mistakes are the ones nobody warned you about.
What does Bullhorn ATS automation actually do, and where does it stop?
Bullhorn's native automation is a single-step rule engine: one trigger, one action. It will update a field, create a task, or send an email when a record is created or a field value changes on a Candidate, Contact, Job Order or Placement. It will not do branching logic, multi-step sequences with delays between them, SMS, or frequency capping, and for any of those you need Bullhorn Automation (Herefish), a third-party tool, or a custom API layer.
Bullhorn's native automation engine is rule-based. You define a trigger - a field value change, a record creation, a date condition - and attach an action: send an email, create a task, update a field. The entity types that support automation rules natively include Candidate, Contact, Job Order, and Placement. Tearsheets and submissions have more limited support. The Appointment and Task entities don't expose triggers in the same way.
What works well natively: automated task creation when a placement record is created and assigned to the compliance team, field updates when a workflow status changes, and single email sends triggered by a compliance field being updated - for example, a Right to Work document being marked as received. These are straightforward and reliable when the underlying data is clean.
The ceiling arrives quickly. There is no native branching logic - you cannot build a rule that fires when field A equals X and field B equals Y but not when field C is populated. There are no multi-step sequences with time delays between steps. There is no conditional email pathing based on engagement, no SMS capability, and no frequency capping to prevent a candidate receiving the same automated email five times in a month.
If you need any of that, you are looking at Herefish - now marketed as Bullhorn Automation - or a third-party tool like Sense, or a custom API layer. Worth being clear about what Herefish actually is: it's a product Bullhorn acquired that sits on top of the ATS and provides the sequencing, branching, and engagement tracking the native engine can't deliver. The licensing is separate from your core Bullhorn subscription and the cost is meaningful - factor that into your build decision before you start.
The mistake I see most often is teams trying to approximate branching logic by building multiple overlapping native rules. The result is rule conflicts, duplicate task creation, and triggers firing on candidates who should never have been in scope. Do not do this. The native engine isn't designed for that kind of logic, and adding more rules to compensate for a previous rule's limitations compounds the problem every time.
Which UK compliance workflows are worth automating in Bullhorn?
Four are worth building in most UK agencies: Right to Work expiry alerts at 30 and 7 days out, an AWR review flag at week 10 of a temporary placement, an IR35 determination check on contract placements, and umbrella document chasing when a placement is created. All four sit within the native rule builder, so no additional licensing is required. All four also depend on the relevant fields existing in your instance and being populated consistently, which is where they usually fail.
Right to Work expiry alerts
The trigger logic for Right to Work expiry sits on the Candidate Compliance or Candidate Certification entity - which one depends on how your Bullhorn instance was configured at setup. The field to watch is typically expirationDate on the certification record. Build triggers at T-30 days and T-7 days: the T-30 trigger creates a task assigned to the compliance team, the T-7 trigger sends an automated email to the candidate and escalates the task if it's still open.
The caveat that matters here: if certifications aren't being logged consistently by your consultants or compliance team, the trigger never fires. The automation is only as reliable as the upstream data entry. Before building this, pull a report of all active placements and check what percentage of the associated candidate records have a certification entry with a populated expirationDate. If it's below 80%, fix the data discipline problem before building the automation - otherwise you get a false sense of security.
AWR 12-week tracking
Bullhorn has no native AWR countdown. The most practical implementation is a calculated custom field on the Placement record that derives week count from dateBegin. You can then set a trigger at week 10 that creates a task for the account manager to review the worker's AWR status before the 12-week point.
Here's what almost every automated AWR implementation gets wrong: the week counter runs from dateBegin and does not reset when there's a gap in the placement. If a temporary worker takes a week off and returns, the AWR clock theoretically resets - but the automation treats it as a continuous placement and keeps counting. This is a compliance risk. The correct approach is to flag week 10 for human review rather than treating the automated count as definitive. The automation surfaces the case; a person validates it. Building this as a "set and forget" trigger without that human checkpoint is the wrong design.
IR35 and umbrella compliance triggers
For IR35: build a trigger on the Placement entity that fires when a placement is created with a contract work type but no IR35 determination recorded. The action is a task creation for the consultant to resolve before the placement goes live. The field is typically employmentType or a custom IR35 status field - check your specific instance configuration.
For umbrella company document chasing: trigger on placement creation where paymentType equals umbrella (in most UK Bullhorn instances this is stored as employeeType or a custom field). The action sends a templated email chasing the umbrella confirmation letter, assignment schedule, and opt-out notice, and creates a task with a due date five working days out.
All of these depend on your instance having the right custom fields configured before you build the rules. If the fields don't exist, the triggers have nothing to act on. Map your field requirements first, get them built in Bullhorn, run a data population exercise, then build the automation.
How do you build a 90-day dormant candidate sequence in Bullhorn?
A dormant re-engagement sequence is three touches over 21 days: a personalised check-in from the owning consultant, a market update or job alert, then a last-touch email with a clear opt-out. Define dormancy from the last activity note and the last placement end date rather than dateLastModified, which any bulk import or data clean-up will reset. Exit candidates on a status change or a new activity note, and move anyone who has not responded by day 21 to Dormant.
The filter logic for a dormant re-engagement sequence needs to be precise. Candidates where dateLastModified or the last placement dateEnd is more than 90 days ago, candidate status is Active or Available (explicitly excluding Do Not Contact, Placed, and Archived), and no open tasks or recent activity notes on the record.
The problem with using dateLastModified as a proxy for genuine activity is that a bulk field update or an import will touch that field without any real engagement having happened. I've seen instances where a data clean-up exercise updated 4,000 candidate records and inadvertently reset the dormancy clock on all of them, wiping out months of re-engagement segmentation. Use a combination of last activity note date and last placement end date rather than relying on modified date alone.
The sequence structure I'd recommend is three touches over 21 days:
Day 0: A check-in email from the owning consultant. Personalised, short, references the last role type they were placed in or applied for.
Day 10: A market update or relevant job alert. Something with actual content - a generic "we have great opportunities for you" email will tank your open rates and damage deliverability over time.
Day 21: A last-touch email with a clear opt-out mechanism. Keep this brief and honest - if they haven't responded to the first two, a third email isn't going to convert them, but it does give you a clean data signal.
Keep it to three. Under UK GDPR constraints on frequency of unsolicited marketing contact, more than that on a dormant candidate is difficult to justify under legitimate interests, and it degrades the quality of your contact data over time.
If you're using Herefish for this, configure the minimum time between sequences for the same contact. Without frequency capping, a candidate who doesn't respond and doesn't opt out can be re-enrolled in the same sequence repeatedly. That's a nuisance for them and a compliance exposure for you.
The most reliable exit triggers are a status change on the candidate record - to Placed, In Process, or Do Not Contact - or a new activity note being logged by a consultant. The failure mode to watch for: a consultant picks up the candidate manually, has a phone conversation, but doesn't update the status. The sequence keeps running in parallel with the manual outreach. That's a process problem, not a Bullhorn problem, but you need to design around it - make status updates a required step in your placement workflow, not an optional one.
After Day 21 with no response: update candidate status to Dormant, remove from all active marketing lists, and flag for GDPR review if the last verified interaction is approaching the two-year mark.
Shift and placement confirmation workflows for industrial staffing
Email confirmations: what works natively
Bullhorn's native automation handles placement confirmation emails reasonably well. When a placement moves to Approved or Confirmed status, a trigger can fire an email to the candidate pulling shift details from placement fields - dateBegin, timeBegin, clientCorporation, address fields. For single, clearly defined placements this works without much trouble.
SMS and why you'll need a connector
Native Bullhorn automation has no SMS capability. For industrial staffing, where candidates may not reliably check email between shift confirmation and shift start, SMS is the channel that actually gets read. You have three realistic options:
Sense: integrates with Bullhorn reasonably cleanly and provides SMS alongside email sequences. Adds cost and another system to maintain - expect an implementation period of two to four weeks to get it configured correctly against your specific Bullhorn setup.
Twilio via custom API integration: more flexible and cheaper per message, but requires development work to build the connection and maintain it. If your Bullhorn instance has non-standard field configurations (and most UK instances do), expect edge cases during build.
TextAnywhere or similar UK SMS provider: some have lighter Bullhorn connectors available. Worth checking, but the out-of-the-box integrations are often limited to basic triggered sends without the conditional logic you'd want for a proper shift communication workflow.
My recommendation is Sense if you want something maintainable without ongoing development resource, and a Twilio integration if you have the technical capacity to build and own it. Don't go for option three expecting it to do the same job as option one or two.
Bank Holidays and timesheet prompts
Bullhorn's date-based triggers don't natively recognise UK Bank Holidays. A "send shift reminder 24 hours before start" rule will fire correctly on a Tuesday after a Bank Holiday Monday - the automation isn't wrong - but if your office is closed on the Bank Holiday and a candidate replies with a query, nobody is there to pick it up. Document this behaviour clearly in your setup notes so consultants know what to expect and plan around it.
Timesheet submission prompts are theoretically straightforward - trigger at end of placement week prompting the candidate to submit. The practical problem with weekly temporary placements is that end dates are often rolling and not accurately maintained in Bullhorn. If the dateEnd field isn't being kept current, the trigger fires at the wrong time or not at all. Fix the end date discipline before building the automation, or the prompt will be worse than useless - it'll fire when the worker is still mid-placement and hasn't got a timesheet to submit yet.
Integrating Bullhorn with UK job boards and payroll middleware
Job board integrations: what actually syncs
CV-Library, Totaljobs, and Reed all have Bullhorn integration partnerships. What this means in practice: applications flow into Bullhorn as Candidate records and jobs posted in Bullhorn can be syndicated to the board. What it doesn't mean: the integration is clean out of the box. The three issues I see consistently are duplicate candidate records, application notes not flowing correctly, and source tracking fields being overwritten or left blank on import.
The duplicate problem is worth dwelling on. If an application comes in from CV-Library but the candidate's email already exists in Bullhorn under a slightly different format - a Gmail alias, a previous employer address, a typo at original entry - you get a new record rather than a match to the existing one. Deduplication in Bullhorn is effectively a manual process. There's no smart merge that preserves the best data from both records. Any automation rule targeting "candidates sourced from CV-Library" will miss the merged record if the source field was lost in the clean-up. Check your source field population rate before you build any board-sourced candidate automation - in most instances I've audited it's sitting somewhere between 40% and 65% accuracy, which is too low to act on reliably.
Payroll middleware: where timing and field mapping matter
Payroll middleware - Tempest, People, FastTrack360 - receives placement data from Bullhorn and processes pay and bill. The integration typically moves placement records, rate information, and timesheet approvals. Automation that depends on payroll confirmation flowing back to Bullhorn (for example, triggering an onboarding email once a placement is confirmed in payroll) breaks when the middleware sync has latency or errors.
Check your sync frequency. Some implementations run hourly, some daily. If you're building a time-sensitive trigger that depends on a field being updated by the payroll sync, a daily sync window means the trigger could be 24 hours late. That matters for shift confirmation workflows where the shift starts tomorrow.
The other issue: field mapping decisions made at implementation constrain what you can automate later. If payroll rate type was mapped to a free-text field rather than a picklist at setup, you cannot build a reliable rule that triggers on rate type - because the values in that field are inconsistent. This is the most common reason automation projects stall six months after the initial build. Before building any automation that depends on data from a job board or payroll system, pull the actual records and look at what's in the fields. What the integration documentation says it sends and what actually lands are often different things.
Where does Bullhorn automation break down?
Bullhorn automation breaks down in four predictable places: rules built on the wrong entity, opt-out suppression that does not sync between the native engine and Herefish or Sense, triggers that depend on fields nobody populates, and consultants routing around automation that gets in their way. Only the first of those is a technical problem. The other three are data and process problems, and no amount of rule sophistication fixes them.
Wrong entity type. The most common technical mistake is building a rule on the Candidate entity when it should sit on the Placement entity. A rule designed to fire when a placement is confirmed ends up triggering on every candidate record where any field has been updated, because the trigger was set at the wrong level. Bullhorn's rule builder interface doesn't make entity hierarchy particularly obvious, so this is easier to get wrong than it sounds. Always confirm which entity owns the field you're triggering on before you build.
Opt-out suppression gaps across systems. Bullhorn's native email automation respects global unsubscribes within its own module. But if you're running sequences through Herefish or Sense alongside native rules, opt-out suppression is only as good as the sync between systems. A candidate who unsubscribes via a Herefish email will be suppressed in Herefish - but a native Bullhorn rule pointing at that candidate doesn't automatically inherit the Herefish suppression. You can end up with a candidate receiving automated emails from the native engine after they've unsubscribed from the Herefish sequence. Audit every active automation rule against your suppression status fields, in both systems.
Triggers depending on fields nobody is populating. This is the failure mode that kills more automation projects than any technical issue. Before building a rule, run a report: what percentage of the relevant records have the trigger field populated? If it's below 80%, the automation will have limited reach and will likely fire incorrectly on records where the field contains unexpected values or nulls. The right order is: establish the field, run a data population exercise, then build the rule.
Consultant workarounds. If the automation creates friction - status updates consultants don't understand the purpose of, tasks that appear to duplicate what they're already doing manually - they will route around it. Placements created with placeholder data to avoid a compliance task being assigned. Statuses set to an "inactive" value to skip a trigger. Notes entered in the wrong field. The automation technically runs but the data it's acting on is garbage. No amount of rule sophistication fixes this. Run a process audit before you build. Map the workflow as consultants actually do it today, not as the process document says they should. Then design the automation around the real behaviour, with checks to catch deviation early.
What does UK GDPR require from your Bullhorn automation?
Automated outreach has to stay consistent with the lawful basis the data was collected under, which for most UK recruitment agencies is legitimate interests. In practice that means an archive or review rule at around 24 months of candidate inactivity, suppression that holds across every system you run sequences from, and deletion requests handled by anonymising the Bullhorn record itself rather than only adding the contact to a suppression list. Bullhorn gives you none of this out of the box, so all of it has to be built deliberately.
Lawful basis and the two-year threshold
Most UK recruitment agencies rely on legitimate interests as the lawful basis for contacting candidates. Automated re-engagement sequences need to be consistent with the original basis for data collection. If a candidate submitted a CV three years ago and has had no interaction since - no placements, no email opens, no inbound contact - re-engaging them via an automated sequence is legally questionable, particularly if their preferences haven't been reviewed in that time.
ICO guidance and standard UK recruitment sector practice treats two years of inactivity as a reasonable point at which to review whether data should be retained or deleted. Build an automation rule that identifies candidates with no activity - no notes, no placements, no email engagement if tracked - in 24 months, moves them to an "Archived - GDPR Review" status, and removes them from all active sequences automatically. This is one of the more straightforward compliance wins available in Bullhorn and most agencies haven't built it.
Suppression and the right to be forgotten
If you're using Herefish for sequences, suppression lists need active maintenance. A candidate who submits a deletion request needs to be anonymised at the Bullhorn record level - removing them from a Herefish suppression list alone doesn't satisfy the obligation. The risk is that if the record still exists in Bullhorn (even partially) and the system performs a re-sync, the contact can re-enter sequences. Anonymisation at the Bullhorn record level prevents the re-sync problem. Make this part of your documented deletion workflow, not an afterthought.
Bullhorn has no native preference centre. If you want candidates to manage their own communication preferences - job type, frequency, sector - that capability needs to be built externally and connected via the Bullhorn API. Without it, your only opt-out mechanism is a blanket unsubscribe. That's a poor candidate experience and it degrades the quality of your consent records over time.
At an absolute minimum: build a suppression check into every automation rule and every Herefish sequence that prevents any outreach to candidates with a Do Not Contact, GDPR Archived, or equivalent status. It's surprisingly common for one or two older automation rules to pre-date the suppression status being created and to never have been updated. Audit your full rule list against your current suppression field values before you go live with anything new.
Should you build Bullhorn automation in-house or bring in outside help?
A competent Bullhorn admin can handle simple field-update triggers, task creation rules, single-email notifications on status changes, and basic compliance alerts - Right to Work expiry, placement confirmation emails. These are within the native rule builder when the data is clean and the process is clear. If that's all you need, you don't need a consultant.
Where I'd bring in outside help: anything involving Herefish configuration (the branching logic and frequency capping setup is non-trivial), API integrations with payroll middleware or job boards, custom calculated fields, GDPR automation that touches data deletion or anonymisation, and any build that crosses multiple entity types with conditional logic. These are the areas where a bad implementation creates problems that are expensive and time-consuming to unwind.
Bad Bullhorn ATS automation in a UK recruitment context has two specific failure modes. The first is compliance exposure - a re-engagement sequence contacting candidates it shouldn't, or an IR35 flag that doesn't fire on the right placement type, creates regulatory risk that is difficult to remediate after the fact. The second is consultant behaviour - if automation creates confusion or adds friction, consultants route around it, and you end up with a CRM nobody trusts and manual processes running alongside the automated ones. Rebuilding a poorly designed automation system always costs more than designing it correctly the first time. The correct sequence is: audit the process, fix the data, then automate.
If you're at the point of deciding what to build in Bullhorn - or you've built something that isn't working the way it should - a Bullhorn configuration audit starts with exactly that: mapping the actual workflows, identifying where data quality is breaking down, and establishing which automation would create genuine value versus which would just run a broken process faster.
