Documentation
Choosing which jobs appear
Not every role in Bullhorn belongs on a public website. This is where you decide which ones do, and it is deliberately a decision you have to make rather than a default that publishes everything.
The default
Nothing publishes itself
After the connection is made, no roles are on your site yet. The plugin does not assume that everything open in Bullhorn should be public, because in most agencies it should not: confidential searches, roles for a client who has not approved advertising, and internal requisitions all live alongside the ones you want advertised.
So you tell it what qualifies. Once that is set, the sync keeps the board in step with it, and a role that stops qualifying leaves the listing.
Controls
How to keep a role off the public board
Several ways, and they combine.
- Selection rules. Which roles qualify at all, read from your own Bullhorn data — the status, the type of role, and whatever your agency uses to mark a vacancy as advertisable.
- A field you already use. Most agencies already have a flag or a status meaning "may be advertised". That is usually the right control, because consultants are already maintaining it.
- Confidential fields. A role can appear while specific details stay off the page. The client’s name is the common one: the vacancy is advertised, the client is not named.
- Closed roles. A role closed in Bullhorn leaves the listing and the job sitemap on the next run. Its page stays at the same address, states that the role is closed, and is marked as expired for search engines — it is never deleted, and reopening the role in Bullhorn reuses the same page.
Check this on staging before you point it at a live site
The one mistake worth avoiding is publishing a confidential search. Set the selection up on a staging install, look at what the board actually contains, and only then repeat it on the live site. The Preview screen shows a job page before anyone else can see it.
Afterwards
What happens when the rules change
Changing which roles qualify is a normal thing to do, and the plugin treats it as an event rather than a silent adjustment: the change is recorded, and the next run brings the board into line with the new rules.
Removals are deliberately cautious. A run only closes roles after it has gathered and verified a complete picture of the catalogue, and a run that wants to remove more than a threshold you set stops and reports instead of proceeding. A single bad answer from the API therefore cannot empty your board. Closure is also reversible rather than a deletion.
If you want to see what a change would do before it does it, run a reconciliation as a dry run from the command line. It reports exactly the decisions the real run would make and writes nothing.
wp w3rp sync reconcile --dry-run