Documentation
The application form
What a candidate fills in, what they are asked to agree to, and what happens between pressing apply and a consultant seeing it in Bullhorn. This is the part of the plugin that handles personal data, so it is worth reading properly.
Configuration
The Application form screen
W3Bullhorn → Application form.
| Fields | What the candidate is asked for. Keep it short: every extra field costs you applications |
|---|---|
| CV upload | Accepted file types and size. Files are held privately, not in the public media library |
| Consent wording | The text a candidate agrees to. Yours to write, and it must match your privacy policy |
| Spam protection | A CAPTCHA secret is configured here. Without it the form still works, but you will get bot traffic |
| Notifications | Who is emailed when an application arrives, and what that email says |
| Screener questions (Pro) | Questions asked per job, with answers delivered alongside the application |
Your consent wording is yours, and it is load-bearing
The plugin records the exact wording a candidate agreed to, with a timestamp, so you can show later what was asked. That record is only as good as the wording — if it refers to a privacy policy, that policy must exist and must say what the wording claims. Write it with whoever handles data protection for you.
What happens after apply
Stored first, then delivered
The order matters: an application is never acknowledged to a candidate before it is safely stored.
-
Your site
Stored
The answers, the CV and the consent record are written down on your own site first.
-
Outbox
Queued
It joins the delivery queue. The candidate gets their confirmation at this point, because the application is already safe.
-
Site → Bullhorn
Delivered
Into Bullhorn, against the right job, with the CV attached and the consent recorded.
-
Resilience
Retried if needed
A failed delivery is retried on a backoff rather than lost. Bullhorn being briefly unavailable does not cost you a candidate.
Exceptions
When an application needs a human
Four states worth recognising.
| Held for review | Something needs a decision before delivery — most often a candidate who may already exist in Bullhorn. Release it with a replay once you have decided |
|---|---|
| Verification failed | Delivery was attempted but could not be confirmed. Resolve it deliberately rather than leaving it |
| Dead-lettered | Delivery failed repeatedly and has stopped being retried. It is still on your site, waiting for a decision |
| Ambiguous outcome | The result of a delivery could not be established either way. Check Bullhorn before replaying, to avoid a duplicate |
# What is waiting for a decision?
wp w3rp application-outbox list-unresolved
# Deliver what is queued, now.
wp w3rp application-outbox run
# Release one you have reviewed.
wp w3rp application-outbox replay --id=<row>The delivery backlog is also a health check, <code>w3rp_delivery_backlog</code>, so a queue that has stopped moving will tell you rather than waiting to be noticed.
Privacy
Where candidate data lives
The question every data protection officer asks first.
- Bullhorn is the system of record. Applications are delivered into it. Your website is not a second candidate database.
- CVs are held privately. Not in the public media library, and not at a guessable address.
- Consent is recorded with the wording and a timestamp. So you can show what was asked, not just that something was.
- Retention is bounded. Delivered and held rows are kept for a configurable period and then cleared.