Bullhorn Onboarding Automation, from Offer to Day One
TL;DR: Bullhorn onboarding automation spans two distinct products - Bullhorn Automation handles the workflow and communication logic, while Onboarding365 handles document collection and e-signature. Most configuration mistakes come from conflating the two, building triggers on placement creation rather than approval, or assuming that completion events from Onboarding365 propagate to the placement record instantly - they do not. Get the trigger sequencing right first, then build the branching logic around it.
What does Bullhorn onboarding automation actually cover?
Bullhorn onboarding automation covers two distinct products that work together but are not the same thing: Bullhorn Automation, which is the workflow and communication engine, and Onboarding365, which is the document collection and e-signature portal. Bullhorn Automation sends emails, creates tasks, and responds to record changes. Onboarding365 presents the candidate with a form pack, collects signatures, and stores completed documents against the placement. Treating them as a single unified system - which most product marketing implies - is where most configuration mistakes begin.
Bullhorn Automation is the workflow engine. Triggers fire on record events, conditions are evaluated, and actions execute: emails, tasks, field updates. It has no native document collection interface. Onboarding365 is the compliance and document portal. It generates form packs, routes them for e-signature, and marks tasks complete when documents are submitted. It does not send workflow emails independently.
The handoff point between them is where the complexity lives. Onboarding365 writes completion status back to the placement record, and Bullhorn Automation can respond to that status change - but this handoff is not instantaneous, and it is not described clearly in any Bullhorn knowledge base article. The practical consequence of conflating the two is that agencies build a single onboarding workflow expecting it to handle both communications and document collection, then discover that document reminders are firing without any link to whether the candidate has actually received or opened the Onboarding365 pack.
What trigger events drive onboarding workflows?
Bullhorn Automation offers several trigger types relevant to onboarding, and choosing the wrong one means your sequences fire at the wrong time - or for the wrong candidates entirely. The relevant triggers are placement record creation, placement status field changes, candidate or contact field updates, and form completion events written back from Onboarding365. Each has a different firing condition and a different risk profile.
Record creation triggers fire the moment a placement record exists. This is the wrong trigger for onboarding. Placements are sometimes created speculatively, before a contract is confirmed, and firing document requests at that stage sends candidates paperwork for roles they may never start. Every agency that has built on creation rather than approval has had at least one candidate receive a right-to-work request for a role that subsequently fell through. The candidate experience is poor, and the compliance exposure is real - you have initiated a data collection process for a placement that does not exist.
Status-change triggers are the correct approach. Filter on the placement status field moving to 'Approved' - or whatever your agency uses to indicate a confirmed placement - so the sequence only starts once the commercial decision is made. This single change removes the speculative-placement problem entirely.
Candidate field update triggers are useful for re-engagement steps further down the line. If a candidate's right-to-work expiry date is updated, for example, that field change can trigger a review task for the compliance team without any manual intervention.
Onboarding365 form completion events are the fourth category. When a candidate submits their document pack, Onboarding365 writes a status back to the placement, and Bullhorn Automation can respond to that change to trigger a post-submission confirmation or create a compliance task. The latency characteristic of this specific event is covered in the next section - it is the most consequential technical detail in the whole setup.
One practical note on filter conditions: always add a placement type filter to any onboarding enrolment trigger. Without it, temporary and permanent placements enrol into the same sequence, which breaks immediately because their document requirements differ. Temporary workers receive permanent employee paperwork, and vice versa. Adding the filter takes two minutes; unpicking the consequences of not adding it takes considerably longer.
Building a multi-step onboarding sequence with conditional branching
A practical onboarding sequence in Bullhorn Automation is not a linear chain of emails. It needs conditional branches to handle the cases where documents are incomplete, right-to-work checks flag an issue, or a candidate simply does not respond. Building it linearly means any exception either stalls the whole flow or, worse, sends the wrong communication to a candidate in a different compliance state.
The step structure I use as a starting point is this: initial document request email at day zero, triggered by the placement status moving to 'Approved'. A timed follow-up fires if no Onboarding365 submission is recorded after 48 hours. A second follow-up with a different subject line fires at 96 hours. If there is still no submission at 120 hours, an escalation task goes to the compliance coordinator rather than another automated email to the candidate. Do not send three emails in 24 hours - that is the fastest way to get onboarding emails filtered as spam and candidates opting out before they have even started.
The conditional branch on document receipt is where most configurations fall down. Once Onboarding365 marks the submission complete, the sequence must exit the reminder branch and move to a compliance review branch. At that point, a task is created for the compliance team. No further automated emails go to the candidate until the compliance review is done.
If the right-to-work check fails or documents are flagged as expired, route to a compliance coordinator task rather than an automated candidate email. The reasons for this are covered in the next section on emails versus tasks, but the short version is that automated emails on RTW failures create audit exposure that no agency wants to defend.
On timing: 48 hours between the first and second reminder is a reasonable floor. Going shorter damages both deliverability and candidate experience. Going longer than 96 hours before escalating creates start-date risk on short-lead placements, particularly in temporary staffing where a placement might be approved four days before day one.
Every follow-up branch needs an exit condition - a check that evaluates whether the Onboarding365 submission status is complete before the action executes. If the candidate submits documents after the first reminder but before the second is scheduled to fire, the second must not send. This is the most common misconfiguration I see in the field, and it is entirely preventable.
Where Onboarding365 ends and Bullhorn Automation begins
Onboarding365 and Bullhorn Automation are separate products with a defined handoff point, and the integration between them has a latency characteristic that is not documented in Bullhorn's public knowledge base. Understanding it is the difference between a sequence that fires correctly and one that sends a 'documents received' confirmation email before the compliance check has actually run.
Onboarding365's scope covers generating and presenting the form pack to the candidate, collecting e-signatures, storing completed documents against the placement, and marking individual tasks as complete within its own interface. It does not send workflow emails - that is Bullhorn Automation's job.
Bullhorn Automation's scope covers all candidate-facing communication, internal task creation, and record updates triggered by status changes. It reads from the placement record to determine whether Onboarding365 tasks are complete.
Here is the specific problem. When a candidate submits their Onboarding365 pack, the completion status is written back to the placement record - but this write is not instantaneous. In testing, delays of several minutes between submission and the placement record reflecting the updated status are observable. If a Bullhorn Automation trigger is set to fire on that status field change, it may read the field before the update has propagated and execute as if the submission has not happened.
What this looks like in practice: a 'thank you for submitting your documents' confirmation email fires before the compliance check within Onboarding365 has run, because the trigger evaluated the field mid-write. Candidates receive confirmation of receipt for documents that are still being processed. In some configurations, this produces duplicate confirmation emails on a single submission - one firing when the trigger first evaluates, and a second when the field state eventually stabilises.
The fix is to add a deliberate delay - a minimum of 5 to 10 minutes - between the Onboarding365 status change trigger firing and any action that depends on the completion state being accurate. This is not a workaround. It is the correct sequencing pattern for any integration that depends on a status field propagating from one system to another. If you skip it, your confirmation emails will occasionally arrive before the compliance check has run, and you will have no reliable way of knowing when it is happening.
When should an onboarding step trigger an email versus a task?
Automated emails are appropriate for standard, predictable steps where the correct action is the same for every candidate: the initial document request, timed reminders, submission confirmations, and start date reminders once compliance is cleared. Task creation is the right call for any step that requires human judgement, including expired documents, missing NI numbers, right-to-work edge cases, and anything where the wrong automated action creates compliance or legal exposure. Automating a judgement call does not make it faster - it makes it auditable in the wrong direction.
The decision test is straightforward. Could the wrong automated action cause a compliance, legal, or candidate experience problem? If yes, create a task and put a person in the loop before anything else happens.
Specific cases where a task is the right output rather than an email: right-to-work documents flagged as expired or approaching expiry, missing mandatory fields such as NI number or bank details, document types that require manual review (a BRP card with conditions attached, for example), and any situation where the compliance coordinator needs to make a call before the process continues.
The audit exposure issue is worth naming directly. If an agency's compliance audit shows that an automated email told a candidate their right-to-work was accepted before a human had reviewed it, that is a regulatory problem. Bullhorn Automation will do exactly what you configure it to do. If you configure it to confirm acceptance without a review step, it will confirm acceptance without a review step. The system is not going to second-guess you.
There is also a GDPR angle here. Automated emails that reference specific document types or flag missing documents should be reviewed against your data processing records. Sending a candidate an email naming a specific missing document - 'we have not received your passport', for example - is processing that information in the communication channel. It needs to be covered in your privacy notice, and if it is not, that is a gap worth closing before you go live.
The pre-placement versus post-placement logic problem
Most Bullhorn onboarding automation is built entirely in the post-placement phase, starting when a placement is approved and ending around the start date. The more effective approach starts earlier - at offer stage - collecting right-to-work documents before the start date creates any time pressure. This is a process design decision that the automation reflects, not a configuration complexity issue.
When a candidate moves to an 'Offer Made' or equivalent stage in the application or opportunity workflow, a preliminary right-to-work document request can be triggered. Onboarding365 can be used here to send a reduced form pack covering only the documents needed for RTW verification, without the full onboarding pack. The candidate receives a shorter, clearer ask, and the compliance team gets more time to review it.
If the right-to-work documents are collected pre-placement, the compliance coordinator can review them before the placement is formally approved. The post-placement onboarding sequence then starts from a position where the most time-sensitive compliance requirement is already satisfied. The document reminders and escalation steps in the post-placement sequence can focus on employment paperwork, bank details, and start logistics rather than chasing the one document type that has the most regulatory weight.
The most common cause of a delayed or failed start date is right-to-work documents being chased in the final 48 hours before day one. Moving that collection two weeks earlier, to offer stage, removes the time pressure from the most consequential step in the process.
The honest caveat here: this approach requires consultants to move candidate records through pipeline stages accurately and on time. If offers are routinely logged late, or if 'Offer Made' is used inconsistently across the team, the pre-placement trigger fires at the wrong time or not at all. The automation reflects the process discipline of the people using it - it does not correct for poor data hygiene.
One structural note: pre-placement and post-placement sequences need clearly separated, non-overlapping enrolment conditions. Candidates who submit RTW documents at offer stage should not receive another RTW request when the placement is approved. Setting that exit condition at offer stage, before the post-placement sequence begins, is what prevents the overlap.
Common configuration mistakes and how to avoid them
Most Bullhorn onboarding automation problems are not conceptual - they are configuration errors that were obvious in hindsight. The four below are the ones I see most often when auditing existing setups, and each has a specific symptom that makes it identifiable without pulling apart the entire workflow.
Building on placement creation rather than approval. The symptom is candidates receiving document requests for placements that subsequently fell through, or receiving requests before the consultant has finished building the placement record. The fix is moving the enrolment trigger to a status-change filter on 'Approved' rather than on record creation. This is the single most common mistake I find in agency setups that have been self-configured without external support.
No exit condition on follow-up sequences. The symptom is candidates who have already submitted documents continuing to receive reminder emails. In the worst cases, a candidate submits on day one, the second reminder fires on day three, and they call the agency to ask why they are still being chased. The fix is an exit condition on every timed follow-up step that checks whether the Onboarding365 submission status is complete before the action executes. If the status is complete, the step skips. Without this, the reminder chain runs to completion regardless of what the candidate has done.
Enrolling all placement types into the same sequence. Temporary and permanent placements have materially different document requirements. Enrolling both into a single onboarding sequence means temporary workers receive permanent employee paperwork and vice versa. The fix is a placement type filter on every onboarding enrolment trigger, and separate sequences per placement type. It is more maintenance to manage two sequences, but the alternative is a sequence that is technically wrong for every candidate it touches.
Misconfigured email templates sending compliance content to the wrong recipient. This is the most damaging one. In misconfigured setups where internal task notification templates share a recipient token with candidate-facing templates, compliance emails have gone to clients rather than candidates. The symptom is usually discovered by the client, not the agency. The fix is strict template separation between internal and external communications, and testing every template with a live enrolment in a sandbox environment before going live. Skipping the sandbox test to save time is a false economy.
How to audit an existing Bullhorn onboarding setup
If onboarding automation is already running and you are not certain it is working correctly, there are four specific things worth checking before assuming it is fine. Start with active enrolment numbers compared against expected placement volume. If you processed 40 placements last month and the onboarding sequence shows 12 active enrolments, something is filtering incorrectly or the trigger is not firing as expected. That gap is the first thing to explain.
Check exit rates at each step. A high exit rate at step one, before any follow-up fires, usually means candidates are completing submission quickly after the initial email - which is fine. A zero exit rate at any step usually means the exit condition is missing or broken, and every candidate is running the full sequence regardless of their compliance status.
Check unsubscribe rates on onboarding emails. Onboarding emails should have near-zero unsubscribe rates because candidates are expecting contact from the agency. Anything consistently above 1 to 2% usually means over-messaging - too many emails too close together - or emails arriving at the wrong time because the trigger is firing on placement creation rather than approval.
Check whether compliance tasks are actually being created. Pull the task list for your compliance coordinator and verify that tasks generated by the automation are present and correctly attributed. In setups where the task creation action is misconfigured, tasks silently fail to create - the automation log shows the action as executed, but no task appears in the CRM. This is a particularly difficult failure mode to catch because the automation appears to be working until someone checks the task list and finds it empty.
Finally, check for duplicate enrolments. Candidates appearing in multiple sequences simultaneously are a sign of overlapping trigger conditions, most commonly between a pre-placement and post-placement sequence that share enrolment criteria without a proper exit condition separating them.
If you want a structured review of your current setup, I offer a Bullhorn automation audit that covers trigger logic, enrolment conditions, exit rules, and the Onboarding365 handoff sequence. It is the starting point for every onboarding automation engagement I take on, because fixing a broken sequence without understanding why it broke tends to move the problem rather than solve it. You can book directly at stacklogic.co.uk/services/bullhorn.
