Bullhorn End Date Automation That Actually Fires
TL;DR: Bullhorn's date-based automation can trigger actions before, on, or after a placement end date - but the default setup breaks more often than most people realise. The most common failure modes are records entering the automation after the target date has already passed, bulk date updates that skip the trigger entirely, and no routing logic for what happens to the candidate record once the placement closes. Getting this right means designing the entry criteria and wait steps carefully before you build anything, and having a clear answer for where the record goes after the automation ends.
How does Bullhorn end date automation actually work?
Bullhorn end date automation works by evaluating a date field on a record at the point of entry into the automation, then using a wait step to hold the record until a set interval before, on, or after that date. The automation does not re-evaluate the date field after entry, so a placement end date pushed back after enrolment will still fire against the original value. The root cause of most end date automation failures is the difference between the entry snapshot and later field changes.
Entry is a snapshot, not a live check
A record enters when the entry criteria match. For a placement workflow, that might be Placement status is Live, the end date is populated, and the record has not already completed the workflow. The date value used by the wait step is the value present at entry. If the placement end date is 30 June when the record enters, the automation schedules from 30 June. If the end date later becomes 31 August, the existing enrolled record does not automatically recalculate its schedule.
Wait step options
The wait step can run before, on, or after the selected date. A placement workflow might create a renewal task 60 days before the end date, create an offboarding note on the end date, or mark a candidate available one day after the end date. The practical warning is that a past date at entry can behave differently depending on the configuration. Some steps may fire immediately because the target date has already passed. Others may never enter because the entry criteria require a future date.
Date trigger compared with record-change trigger
A date-based trigger is not the same as a record-change trigger. A record-change trigger responds to an edit, such as the end date being changed, but it does not automatically recalculate an already enrolled wait step. The automation clock is tied to enrolment and the stored date value, not to the date the field was last edited or the date a consultant confirmed the placement. That distinction matters because users often assume the workflow is watching the field continuously. It is not.
Why does Bullhorn end date automation misfire?
Bullhorn end date automation misfires most often because Bullhorn evaluates entry criteria once at the point a record enters the automation. Any subsequent change to the date field is ignored unless the record exits and re-enters. Bulk date updates made directly in the database or through an integration bypass the automation trigger entirely, so records with shifted placement end dates never re-enrol.
Records entering after the date has passed
Late entry is the first common failure mode. A placement only enters the automation after the end date has passed because the status changed late, an import corrected old records, or a consultant filled the date retrospectively. Depending on the wait step, Bullhorn may fire immediately or skip the step entirely. The result is a task created after it is useful, or no task at all.
Bulk date changes that never re-trigger
Bulk date changes are the second failure mode. A data loader update, integration write, or bulk edit changes the placement end date, but existing enrolled records remain on the old schedule. The automation does not treat the new date as a fresh enrolment unless the record is deliberately exited and re-entered. I think of this as stale enrolment: the record is still in the workflow, but the workflow is now acting on a date that no longer reflects the placement.
Wrong date field selected
Many agencies have several dates on or around a placement: placement end date, actual end date, confirmed end date, extension date, or a custom field used by operations. The automation fails when it points at the field consultants do not treat as authoritative. Do not build a trigger from a field called expected end date if the desk actually manages confirmed end date in a custom object or external system. The workflow will look active in configuration and still miss the operational truth.
Midnight UTC firing and business day assumptions
Timing assumptions create another class of misfire. An on-date step can fire at midnight UTC rather than at end of business in the UK. That can create renewal tasks too early, mark a placement complete before the contractor's final day has finished, or surprise users who expect end-of-day behaviour. If the business assumes the automation will wait until 5pm, it needs to be tested against that assumption rather than treated as a default.
When should you use automation versus a webhook for end date triggers?
Native Bullhorn end date automation is the right tool when the placement end date is set once, unlikely to change, and all required actions happen inside Bullhorn. A webhook-driven approach through n8n or a similar tool is more reliable when an external system owns the date, the date shifts frequently, or post-expiry actions need to reach another platform such as HubSpot, payroll software, or an MSP portal.
Where native automation works
Native automation suits simple, linear sequences: 30-day reminder, 7-day reminder, on-date task creation, placement status update, and candidate task creation. The key condition is that the date is stable after entry. A placement with a signed contract end date and no expected extension is a reasonable candidate. A placement where payroll or vendor management can change the end date every week is not.
Where a webhook workflow is safer
Use a webhook or n8n pattern when the date is owned outside Bullhorn, for example by an MSP portal, payroll system, timesheet tool, or contract management platform. External ownership increases the chance of asynchronous writes and silent date changes. Use it when extensions are common. Contractor end dates in contract recruitment often move, and native automation is weak at re-evaluating an enrolled record against a changed date. Use external orchestration when post-expiry actions cross systems: create or update a CRM record, notify a Slack channel, add a candidate to a nurture sequence, or route a renewal opportunity to another team.
The decision rule
If the date is stable and all actions are inside Bullhorn, use native automation. If the date is volatile, externally owned, or needs cross-platform routing, use a webhook-driven workflow. If you are unsure, I would default to external reconciliation for contract desks. The operational cost of a missed renewal is usually higher than the cost of maintaining a small nightly check.
Native automation only. Best for stable dates, but it cannot re-evaluate an enrolled record when the date changes.
Webhook-driven or n8n scheduling. Best for volatile or externally owned dates, but it needs logging, error handling, and a named owner.
Hybrid reconciliation. Keep Bullhorn tasks native and run a nightly external check, but expect more moving parts and duplicate prevention work.
I would choose option 2 when dates change often. I would choose option 3 only when consultants live inside Bullhorn and the external workflow can write tasks back cleanly. Do not use option 1 if an integration updates the end date after the placement has already enrolled.
Building a placement expiry workflow that holds up
A reliable placement expiry workflow starts with narrow entry criteria and a clear post-expiry action. The automation should only enrol active placements with a populated end date that is still in the future at the moment of entry.
Entry criteria
Use explicit conditions: active or live placement status only, end date not null, end date in the future at entry, candidate not archived, and owner or desk consultant populated. If the placement record uses an API field such as dateEnd, name that field in the design and test against the real field. Do not assume every Bullhorn instance uses the same label, and do not rely on a helper field unless it is the one consultants treat as authoritative.
Timed steps
60 days before end date: create a task or note for the consultant to confirm whether the placement is ending, extending, or moving to a new role. For high-value contractors, add a manager notification or a follow-up call task.
7 days before end date: create a renewal or offboarding task, notify the manager or desk lead, and check for operational blockers such as timesheet issues, missing notice, or a pending change order.
On end date: update the placement status to completed or closed, update the candidate record only according to the agreed routing rule, and create the correct next task. Avoid generic candidate status changes unless the routing logic has been defined.
Suppression and re-enrolment
If the placement is extended or the end date changes, exit the automation and allow re-entry only when the new end date is in the future. That suppression rule is necessary, but it is not perfect. If the exit logic runs close to a scheduled reminder, the old task can still appear before the record leaves the workflow. The design therefore needs duplicate prevention or a reconciliation step, especially on high-volume contract desks.
What happens to the candidate record after the automation ends?
Once a Bullhorn end date automation completes, the candidate record sits unchanged unless a specific routing step has been built. Consultants may receive reminder tasks, but the candidate record can keep the old placement status, receive no re-engagement activity, and effectively go dark. The routing decision, covering re-engagement, available status, or suppression, needs to be defined before the automation is built because retrofitting routing can force manual re-enrolment of affected records.
Three routing options
Re-engagement is the right route for candidates who performed well, have valid right to work, and are likely to want another role. The automation should create a candidate task, add a note, or push the candidate into an available pipeline. Mark available is the right route when the candidate is not immediately re-engaged but should remain active in the database. Update the candidate status and create a task for the owning consultant to make contact within a set number of working days. Suppress or archive is the right route when the candidate is out of scope, has expired right to work, has asked not to be contacted, or is unsuitable for future placements. The automation should prevent further marketing or re-engagement activity.
Design the route before building the trigger
If routing is undefined, candidate records remain tied to old placements, availability reports become unreliable, and consultants assume someone else is following up. Agree the routing logic with desk leads before the automation is built. The decision should be based on candidate performance, right to work, client feedback, and future availability, not left as an afterthought.
Handling date changes after a record has enrolled
The safest way to handle changed end dates is to treat the original automation enrolment as invalid as soon as the date changes. Bullhorn can exit the record through a suppression rule, then re-enrol it against the new date, but the gap between change and exit needs to be acknowledged.
Exit and re-enrol on the new date
Build a suppression rule that exits the record when the placement end date changes or the placement status changes to extended. Then use a separate entry rule to re-enrol the placement if the new end date is in the future and the placement remains live. The pattern is the simplest native option, but it depends on the exit rule catching the change before the next scheduled step runs.
Nightly reconciliation for high volume teams
For high-volume agencies or environments with frequent extensions, use a nightly script or n8n workflow that compares enrolled records against current placement end dates. The workflow should identify mismatches, exit stale records, flag duplicates, or trigger corrected actions. What I would do for a contract desk with frequent extensions is run this check every night and create only one corrected task per placement per date change.
Known gaps
Native suppression rules do not guarantee immediate exit in every operational scenario. If an end date changes close to a scheduled reminder, the workflow can still create the old task before the exit logic catches up. Define behaviour for the edge cases: end date moved earlier, end date moved later, placement extended multiple times, placement reopened after completion, and candidate already marked available. Native automation can handle simple date changes only if exit and re-entry are designed deliberately. If the business cannot accept a gap, use external reconciliation.
What to sort out before you build anything
The pre-build audit matters more than the automation builder settings. Most failed end date automations are caused by unclear field ownership, inconsistent placement statuses, and no decision about what should happen after expiry.
Field and status audit
Confirm the authoritative date field. Check which field consultants actually use, whether it is consistently populated, and whether existing live placements contain null values, past dates, or dates that conflict with the placement status. Define what a live placement looks like in field terms. Entry criteria should use explicit status values, worker type, date conditions, and owner conditions. Exclude records that should never enter, such as perm placements, draft placements, or test records.
Post-expiry routing decision
Map the post-expiry routing before touching the automation builder. Decide who owns the candidate after the placement ends, which status should be applied, what task is created, and when a candidate should be suppressed instead of re-engaged. If these questions are unresolved, the automation will create tasks but will not fix the underlying process.
Integration and suppression checks
Check whether any integration writes to the placement end date asynchronously. Payroll, MSP, timesheet, or middleware updates can change the date without triggering the expected Bullhorn automation behaviour. Document the suppression rule for extensions, cancellations, and reopened placements. Include test cases: date moved forward, date moved backward, status changed to extended, placement completed early, and placement reopened after completion.
If your placement end dates change often, come from external systems, or have already produced duplicate tasks and missed renewals, get the data model checked before you add more workflow steps. I can audit the fields, entry criteria, suppression rules, and integration writes through the Bullhorn automation service page.
