Bullhorn CRM Automation in the UK: A Practitioner’s Guide
TL;DR: Bullhorn Automation fires off five record types and runs either event-based or on a schedule. Three things decide whether any sequence works, and none of them are the sequence itself: field completeness on availability date, placement end date and consent flags; suppression logic that excludes active placements and recent consultant activity; and a lawful basis under UK GDPR and PECR hardcoded into the exclusions rather than left to consultants to remember. Get those wrong and automation damages candidate relationships faster than it creates value.
How does Bullhorn CRM automation work?
Bullhorn Automation is the platform Bullhorn built out of Herefish, which it acquired in 2018. Automations fire off five record types (Candidate, Contact, Job, Placement and Lead) and run either event-based, the moment a trigger condition is met, or on a schedule against a filtered list. Condition logic is AND-based by default, and that single constraint shapes most of how you have to build.
If you inherited a Bullhorn instance, it is worth checking whether there are legacy Herefish sequences still active alongside any newer Bullhorn Automation setups. I have seen agencies running both in parallel without realising it, which means candidates can receive duplicate touches from two separate systems. Check the Herefish tab in your admin settings before you build anything new.
Automations in Bullhorn fire off five record types: Candidate, Contact, Job, Placement, and Lead. Each exposes different trigger conditions. A Placement trigger can fire on status change - for example, Active to Completed. A Candidate trigger can fire on field value change, such as availability date being updated. The record type you choose determines what data is available in the action, so picking the wrong object for a sequence is a structural mistake that usually only surfaces during testing.
The more important distinction is between event-based and scheduled automations. Event-based fires the moment a trigger condition is met - record created, field updated, status changed. Scheduled automations run at a fixed interval against a filtered list of records. The practical difference matters enormously: a bulk data import that updates availability dates on 2,000 candidate records will fire an event-based sequence on all 2,000 simultaneously. Scheduled automations only evaluate at their next run window, so the same import has no immediate effect. Most admins do not know which type they have configured until something misfires at scale.
One technical constraint worth understanding up front: condition logic in Bullhorn Automation is AND-based by default. If you need OR logic - for example, fire if status equals Available OR status equals On Assignment - you need either separate automations or a list-based workaround. This is a genuine limitation that affects how you build suppression, and I will come back to it.
What data do you need to fix before automating Bullhorn?
Automation does not fix bad data. It amplifies whatever state the data is already in. The fields that Bullhorn automation logic depends on most heavily are: record status, availability date, placement end date, GDPR consent flags, and record owner. Each of these has a specific failure mode when it is missing or wrong.
A blank availability date means availability-based triggers simply will not fire for that record. The tempting fix is to bulk-set availability date to today on all candidates who are missing it. Do not do this. Bulk-setting availability date to today on a large candidate pool will fire every event-based availability sequence simultaneously, on records that may not be appropriate targets. I have seen this cause hundreds of outbound emails to go out in the space of an hour, including to candidates who were mid-placement.
Placement end date is critical for contract renewal and AWR sequences, and it is frequently wrong or blank on records imported from legacy systems. If the end date was never updated after a contract extension, the sequence fires on the old date. The candidate gets a "your contract is ending" message three months into an extension. That is a consultant relationship problem, not just a data problem.
Consent fields are the most commonly under-populated. If consent fields were never mapped during a data migration, suppression logic based on consent status will silently pass records through as if consent were given. The automation has no knowledge that the field is blank - it just sees a record that does not match the "consent withdrawn" exclusion condition, so it fires.
Before activating any sequence, I would run the following audit. Export 200 records from the segment the automation will target. Check null rates manually on each trigger field. Pull a report on how many records across the full dataset have null values in each critical field. Also check that picklist values on existing records match the values your condition logic is filtering on - picklist drift after Bullhorn upgrades or data migrations is common, and a condition filtering on "Available" will not catch records where the status was historically entered as "Active" or left as a legacy value from an import.
The field completeness benchmarks I would aim for before going live: availability date populated on at least 80% of active candidates, placement end date populated on 100% of live placements, and consent fields populated on 100% of records - even if the value is "unknown." An unknown consent state is at least a known state. A blank field is not.
What suppression rules should you build before going live?
Six exclusions form the baseline: anyone with an active placement, anyone with a logged consultant call, meeting or email in the last 14 to 30 days, anyone with an open submission or interview, anyone with the email opt-out flag set, anyone whose consent is withdrawn or was never given, and anyone placed within the last 60 days. Most Bullhorn setups have none of them.
Most Bullhorn Automation setups have trigger conditions and actions, with no exclusion logic. The sequence fires on everyone who matches the trigger, with no check on whether they should be receiving it at all.
The failure mode I see most often: a contract worker three days from their placement end date receives a generic reactivation email - "We haven't heard from you in a while" - because the sequence triggered off an availability date that was about to update. The consultant then has to explain to a candidate they placed last month why the agency is asking them to get back in touch. That conversation is damaging, and it is entirely avoidable.
The baseline suppression conditions every UK agency should build before going live with any outbound sequence are as follows. Exclude anyone with a current active placement status. Exclude anyone with a logged call, meeting, or email within the last 14 to 30 days - the window depends on how active your consultants are. Exclude candidates with an open submission or interview record. Exclude anyone with the email opt-out flag set. Exclude anyone where the consent field is set to withdrawn or not given. Exclude anyone placed within the last 60 days, even if the placement has technically ended - they should be in a post-placement sequence, not a reactivation one.
In Bullhorn Automation, suppression is implemented either as exclusion filters on the automation's entry criteria or by maintaining a suppression list that the automation checks against. For dynamic suppression - recent touchpoints, current placement status - exclusion filters off live field values are more reliable. The list-based approach has a specific failure mode: suppression lists go stale. A candidate added to a manual suppression list six months ago does not get removed automatically when circumstances change. Build suppression dynamically off record status and field values wherever you can. Reserve manual lists for edge cases, and build a review cadence into whoever owns the CRM.
Because Bullhorn's condition logic is AND-based, building OR suppression conditions - exclude if status is X OR status is Y - requires separate automations that each write to a shared suppression list, or a workaround using a calculated field. It is clunky, but it works if you build it deliberately rather than discovering the limitation mid-project.
Automation sequences UK recruitment agencies actually use
Five sequences cover most of what UK agencies run in practice: post-placement check-in and NPS, contract end and AWR renewal reminders, passive candidate reactivation, BD sequences triggered by new job orders, and PSL or framework contact re-engagement. Each one has a specific failure mode that is worth building against before you switch it on.
Post-placement check-in and NPS (temp and contract)
Trigger: Placement status changes to Active, record type equals temp or contract. Action chain: Day 1 email to candidate with onboarding or welcome information. Day 5 task creation for the consultant to check in, with an optional automated email if no logged activity. Day 10 NPS survey send.
The failure mode here is specific: if the placement is short-term and ends before Day 10, the NPS fires to a candidate who has already finished. Add a condition on the Day 10 action requiring placement end date to be greater than today. Without that condition, a candidate on a 7-day booking gets an NPS survey after they have left.
Contract end and AWR renewal reminders
Trigger: Scheduled automation evaluating placement end date. Timing: 6 weeks before end date, create a consultant task and send an internal notification. 2 weeks before end date, a second consultant alert. On the end date itself, a candidate-facing check-in email if the placement has not been extended.
For agencies placing temp and contract workers, the 12-week AWR threshold is a compliance event. An automation flagging placements approaching 12 weeks gives consultants time to act before the threshold is reached. I would set the trigger at week 10 - 2 weeks before AWR applies - with a consultant task rather than a candidate-facing email, so the consultant owns the conversation.
The failure mode: if placement end date was never updated after a contract extension, the sequence fires on the original end date. Use a "contract extended" status field as a suppression condition to prevent the candidate-facing email from going out mid-placement.
Passive candidate reactivation
Trigger: Scheduled automation, evaluates availability date within the next 30 days AND last activity date more than 90 days ago. Action chain: personalised email from consultant using merge fields (first name, last placed job title). If no response after 7 days, a second email or SMS. If no response after a further 7 days, a consultant task to call.
The specific failure mode to watch for: merge fields pull blank if the underlying data is missing. A reactivation email that opens with "Hi ," reads worse than no email at all. Before activating this sequence, test it against a sample of at least 20 records with varying levels of field completeness. Confirm what the email renders as when first name or job title is null, and either build a fallback value into the merge field syntax or add field-populated conditions to the trigger.
BD sequences triggered by new job orders
Trigger: Job record created, status equals Open. Action chain: notify the consultant owner, create a 48-hour follow-up task, and if no submission is logged after 5 days, escalate via a task to the team lead.
Failure mode: job records created as duplicates or as test records trigger the sequence. Add a condition requiring at least one substantive field - client company, salary, or job title - to be populated before the trigger fires. A record with a status of Open and nothing else should not be launching a BD sequence.
PSL and framework contact re-engagement
Trigger: Contact record (client-side), last activity date more than 60 days ago, associated company tagged as PSL or framework client. Action chain: email to contact from their account manager, consultant notification to follow up if the email is opened.
The failure mode here is that the contact has left the company but the record is still active in Bullhorn. The email reaches a dead address or, in a worse scenario, their replacement who has no existing relationship with the agency. Run a bounce suppression check and link any re-engagement sequence to a regular contact status audit. If a contact's email bounced in the last 90 days, they should not be in this sequence.
Is Bullhorn automation GDPR compliant in the UK?
Bullhorn gives you the tools to be compliant, but compliance is a function of your configuration, not the platform. Most UK agencies rely on legitimate interests under Article 6(1)(f) UK GDPR for candidate outreach, which is defensible for targeted follow-up and much harder to justify for high-volume sequences firing on dormant records. PECR is the stricter test for direct marketing email, and under PECR consent is the safer basis.
The lawful basis question sits underneath every outbound sequence. Most UK recruitment agencies rely on legitimate interests under Article 6(1)(f) UK GDPR for candidate outreach. That is defensible for targeted, relevant communication - a consultant following up near contract end date, a check-in after a recent placement. It becomes harder to justify for high-volume automated sequences firing on thousands of dormant candidates simultaneously. The legitimate interests assessment needs to weigh the agency's interest against the individual's reasonable expectations. A candidate who registered three years ago and has had no contact in that time is unlikely to expect an automated marketing sequence on their availability date.
Bullhorn has a built-in GDPR consent field on candidate records - gdprConsentStatus in most versions. This field needs to be mapped as a suppression condition on every outbound sequence. If it is not populated, the sequence has no visibility of consent state and will fire on records where consent was never collected or has since been withdrawn.
There is an operational risk around right to erasure that most agencies have not thought through. When a candidate exercises their right to erasure, Bullhorn can anonymise or delete the record. However, if the candidate's email address has already been loaded into an active automation queue - the sequence has evaluated them and scheduled an email for the following day - the deletion of the Bullhorn record does not automatically pull them out of the queue. The email can still fire. The mitigation is a manual check of active queues whenever an erasure request is processed. If you are running n8n or have Bullhorn API access, you can build a workflow that removes the address from queued sends on erasure - that is the cleaner solution, but it requires integration work.
There is also a distinction between UK GDPR and PECR that a lot of agencies conflate. The Privacy and Electronic Communications Regulations apply to direct marketing emails to individuals. For candidates as natural persons, consent is the safer basis under PECR - legitimate interests is not a valid basis under PECR for electronic direct marketing in the same way it is under UK GDPR. Many agencies have built their suppression logic to exclude only explicitly withdrawn consent, which leaves a gap for records where consent was never collected. The more conservative configuration is to only send to records where consent status is explicitly positive.
I am not a solicitor and this is not legal advice. But the agency's legal or compliance team needs to sign off on the lawful basis decision before high-volume sequences go live. Once that decision is made, hardcode it into the suppression logic. Do not leave it to individual consultants to manage manually - that approach will fail the first time someone forgets to check a box.
What can Bullhorn Automation not do?
Three limits matter in practice. There is no true if/then/else branching inside a single sequence, so behaviour-based journeys need two automations and a field update to route between them. Multi-object trigger conditions are not supported, and native reporting stops at sends, opens and clicks without connecting any of it to placements or revenue.
Bullhorn Automation does not support true if/then/else branching within a single sequence. If a candidate opens an email, you cannot send a different follow-up than if they do not open it - not natively. You would need two separate automations and a field update to route between them. Compared to HubSpot Workflows or ActiveCampaign, this is a meaningful constraint for anyone trying to build behaviour-based journeys.
Multi-object trigger conditions are not supported in a single condition set. You cannot build a trigger that evaluates conditions across both a Candidate record and their associated Placement record simultaneously. If you want to fire a sequence when a candidate's availability date is within 30 days and their last placement was in a specific sector, the workaround is a scheduled field-copy automation that writes a calculated value to the Candidate record, which a second automation then triggers off. It works, but it adds a dependency that needs maintaining.
Reporting is another real gap. Bullhorn Automation's native reporting shows sends, opens, and clicks. It does not connect those actions to downstream placements or revenue. Attributing a placement to a specific reactivation sequence requires manual logging or a third-party integration. Without that, demonstrating ROI on automation investment is largely qualitative.
For agencies that need conditional branching or cross-object logic, the practical architecture is Bullhorn Automation handling standard linear sequences, with an n8n or Bullhorn API layer sitting alongside it for anything requiring more complex conditional logic. Sense is worth knowing about for staffing-specific use cases - it has stronger engagement analytics and two-way SMS than native Bullhorn Automation, though it adds cost and another integration to maintain.
If the build points toward outside help, see how to choose a Bullhorn implementation partner in the UK for what to look for.
The pre-build configuration checklist
Field completeness audit. Export your target segment. Check null rates on availability date, placement end date, record status, owner, and the GDPR consent flag. If any critical field is below 70% populated, fix the data first. Building on incomplete data does not produce partial results - it produces skewed results that look like they are working.
Consent flag review. Confirm that gdprConsentStatus is present, populated, and using consistent picklist values across the dataset. If records were imported via CSV and the field was left blank, you do not have a usable consent state. You have a gap that your suppression logic will silently pass through.
Suppression conditions. Build the baseline exclusions before writing a single action: active placements, recent consultant activity within 14 to 30 days, withdrawn consent, email opt-out flag, and placed within last 60 days. Test the combined suppression logic against a sample of 50 records and check manually that the right ones are being excluded.
Test record setup. Create two or three test candidate records that fully satisfy your trigger conditions. Run the automation in test mode against those records only. Confirm the emails fire at the right intervals with the right merge fields populated. Specifically check what renders when a merge field is blank - a broken personalisation token is worse than no personalisation.
Sequence logic sign-off. Write the intended behaviour in plain English before checking it against the configuration. Mismatches between intention and configuration are the most common source of misfires, and they are easiest to catch before go-live rather than after.
30-day monitoring plan. Agree in advance what you will check and when. At minimum: email delivery rate, bounce rate, unsubscribe rate, and any consultant reports of unexpected contacts receiving emails. Set a threshold at which you will pause the sequence - more than 5 unsubscribes in the first 48 hours is a signal the targeting is off, not a signal to keep going and see what happens.
If you are starting a Bullhorn CRM automation project and want a second set of eyes on the configuration before anything goes live, a Bullhorn systems audit is a good place to start - it covers data state, suppression logic, and integration architecture as part of the same review.
