Most Bullhorn agencies already pay for more automation than they use. Recruiters still copy placement end dates into reminders by hand, chase interview feedback from memory and let the database go stale between roles. At the same time, every vendor pitch now says AI agent. This guide sorts out what Bullhorn can automate out of the box, where its own AI fits, and what you need to check before you plug a custom agent into your ATS.
Three layers of automation in a Bullhorn shop
It helps to separate three things that often get mixed up in sales calls.
| Layer | What it is | Good for |
|---|---|---|
| Bullhorn Automation | Rule-based workflows built in a visual builder. A list or date decides who enters, steps decide what happens. | Follow-ups, reminders, nurture, surveys, field updates, data hygiene |
| Amplify | Bullhorn's AI layer. Amplify Chat is a recruitment LLM that reads your Bullhorn data. Amplify Digital Workers run tasks like enrich, match, screen, outreach and verify. | Summaries, drafting emails and job descriptions, resume extraction, matching |
| REST API and custom code | Your own integrations reading and writing Bullhorn entities, often triggered by event subscriptions. | Cross-system workflows, client portals, reporting, custom agents (with permission) |
Start at the top layer. Most agencies get the fastest results from the rules they can build themselves, and the data cleanup those rules force on them makes every later AI project work better.
How Bullhorn Automation decides who enters
Every automation is built around one record type. Bullhorn supports Candidates, Sales Contacts, Placements, Submissions, Jobs and Leads, with Leads limited to Enterprise. Lists, engagements and merge tags only work inside automations of the same record type. So a survey sent after a placement starts needs a Placement based automation, not a Candidate one.
There are two automation types.
- Standard. The list alone controls entry. If a candidate matches the list criteria, they enter.
- Center on Date Field. The list still applies, but entry and timing are tied to a relative date on the record. Wait steps can fire before, on or after that date.
Lists come in two kinds. Always Updated lists keep syncing with the ATS, and Bullhorn says a sync averages about 6 minutes. One-Time lists are frozen at the moment you create them and suit audits and snapshots. You cannot switch a list from one type to the other after saving, and editing the criteria of a list inside an active automation pauses that automation. Plan your lists before you switch anything on.
Automations worth building first
These use only features Bullhorn documents for Bullhorn Automation, so most agencies can build them without new tools.
- Placement ending. A Placement automation centered on End Date that alerts the recruiter, creates a follow-up task and emails the contractor about their next role before the assignment finishes.
- Back on the market. When a placement ends, update the candidate status to Active and copy the placement end date and job title into the candidate's available date and job title fields. Bullhorn lists both of these as built-in data actions.
- Interview prep and feedback. A Submission automation centered on Interview Date. A prep email to the candidate before the interview, then a task for the recruiter to collect feedback after it.
- Stale candidate nurture. An Always Updated list of candidates with no contact in a set number of days, entered into a light email or SMS check-in that asks for current availability.
- Survey to field update. A short survey or chatbot that asks candidates for availability, location and pay expectations, with answers written back to Bullhorn fields.
- Clean outreach lists. Use the Is Valid email operator on Candidate, Sales Contact and Lead lists so campaigns skip addresses that will bounce.
Where Amplify fits
Bullhorn draws a clear line here. Automation is rule based: a trigger leads to a fixed action. Amplify Chat is described as the recruitment LLM inside Bullhorn. It reads your Bullhorn data to summarise records, draft personalised emails and write job descriptions, so recruiters do not copy candidate data into an outside chatbot. Amplify Digital Workers go further and execute tasks such as enriching records from resumes, matching, screening, outreach, transcribing calls and verifying data. Bullhorn says Amplify data stays within Bullhorn and is not used to train public models.
The practical question is not whether to use Amplify. It is which steps need judgment and which need rules. Rules are cheap, predictable and easy to audit. Use AI for the steps where a recruiter would otherwise read and write free text, and keep a human approving anything that goes to a client or changes a candidate's status in a hiring decision.
Building custom agents on the Bullhorn API
Some workflows cross systems. A client portal, a payroll tool, a sourcing agent that writes into Bullhorn, or reporting in a warehouse. That is REST API work, and two parts of Bullhorn's documentation matter most.
Event subscriptions
Instead of polling every record, you subscribe to entity events. A subscription can cover several entities, such as Candidate and Placement, and the event types INSERTED, UPDATED and DELETED. A few rules to design around:
- Events are purged once you consume them, and expire after 7 days if nobody does.
- A database can have at most 15 event subscriptions, so share them across integrations.
- Bullhorn suggests consuming events on a regular cadence, such as every 30 minutes or hourly.
- An UPDATED event lists the changed field names, not the new values. Your code must fetch the record to read them.
The fair use policy
This is the part most AI agent pitches skip. Bullhorn's API fair use policy says the API must not be used to connect third-party AI or LLM tools for viewing or updating data without Bullhorn's explicit written permission. It names Model Context Protocol servers as an example of an unauthorized solution without that permission. It also requires any third-party service provider to register with Bullhorn, and access to a customer's database must follow the customer's written instruction naming that provider and the data in scope. Bulk transfer beyond the minimum needed is not allowed.
So before anyone connects an outside model to your Bullhorn instance, get the permission question answered in writing. Then scope the agent to the fields it needs and log what it reads and writes.
Mistakes we see
- Building automations on dirty status fields, so placed candidates get nurture emails asking if they are looking.
- Using a One-Time list for enrollment and wondering why new records never enter.
- Editing a live list during the week and not noticing the automation paused.
- Several integrations each grabbing their own event subscription until the limit of 15 is hit.
- Pasting candidate data into an outside chatbot because the approved tools were never set up.
- Wiring a custom AI agent to the API without checking the fair use policy or getting written permission.
How Remqa helps Bullhorn agencies
Our forward deployed engineers start inside your Bullhorn instance. We audit the fields and statuses automations depend on, build the first rule-based workflows with your team and add AI only where it saves recruiter time on reading and writing. When a workflow needs custom code, we design it around Bullhorn's API rules from day one. See how we build AI recruiting agents, how our recruiting hours model works, or read our guide on connecting your recruiting tool stack.