Solutions
What people actually build with it
The same plugin, pointed at different problems. Start from the one that sounds like yours rather than from a feature list, because the decisions that matter are different in each case.
Audience
By who you are
Two audiences, and the trade-offs are not the same for both.
Agencies
Recruitment and staffing agencies
Every role on your own site, every application in Bullhorn, and a board that is an asset you keep rather than a portal you rent. PartnersWordPress and web agencies
Building and maintaining job boards for clients who run Bullhorn, including what it takes to look after several of them.Task
By what you are trying to do
Three jobs the plugin is bought for.
Job board
Put Bullhorn jobs on WordPress
The starting point: roles as real pages on your own domain, each with its own address, in your own theme. PortalBuild a candidate portal
Let candidates sign in and see what they have applied for, without a second password to remember or a second database to hold. ScaleHandle high-volume jobs
Thousands of roles kept current without hammering an API allowance that is shared with everything else you have connected.Start here
Not sure which applies?
Two questions sort most of it out, and you can answer both yourself.
- <strong>Do candidates need to come back?</strong> If they only ever apply once, a job board is enough. If they return to check on an application, that is a candidate portal.
- <strong>How many roles are open at once?</strong> Under a few hundred and sync is a non-issue. Into the thousands and how an integration talks to the API becomes the thing that decides whether it works.
Compare
Deciding between approaches
Compare