Applications from the website to Bullhorn

Forum for users and developers of Bullhorn's API service.

Moderators: StaffingSupport, s.emmons, BullhornSupport

Post Reply
scdk
User
Posts: 6
Joined: Wed Dec 12, 2012 6:39 am

Applications from the website to Bullhorn

Post by scdk » Tue Jul 01, 2014 5:47 pm

I am successfully showing our jobs list on the website but we also wish to send job applications via the website back into Bullhorn.

Looking through the developer docs for the rest api, it seems I need to use JobSubmission that accepts the following:

id
appointments
billRate
candidate
dateAdded
dateWebResponse
isDeleted
isHidden
jobOrder
payRate
Salary
sendingUser
source
status

but it doesn't state exactly what these are or what should be entered here.

I also note that there is a function for resume parsing but I can;t find any further info on this.

Could someone help or point me in the right direction of where to find docs for this?

Thanks

srg.bdavis
User
Posts: 67
Joined: Thu Feb 20, 2014 4:52 pm

Re: Applications from the website to Bullhorn

Post by srg.bdavis » Thu Jul 03, 2014 10:26 am

This article on the dev site gives you a pretty good idea of the submission process: http://developer.bullhorn.com/articles/ ... candidates

You do not have to use all of the fields on the JobSubmission entity when you send the PUT /entity/JobSubmission request.

Here are the fields we use:

Candidate (just the candidate id)
JobOrder (just the job id)
Status (e.g. "New Lead")
Source (e.g. "Website")
DateWebResponse (the date the application was created)

The JobOrder id you probably already have since you are currently listing the jobs on your website. The tricky part is the candidate. If you require your candidates to pre-register or log in before submitting an application you can get the candidate id pretty easily during whatever authentication / registration process you use. If you want to allow candidates to apply and register at the same time, you must create the candidate entity first, get the id, then create your job submission.

For the resume parsing the method you want to use is POST /resume/parseToCandidate. This article walks you through those steps: http://developer.bullhorn.com/articles/ ... fromresume

Regards,
Brent

scdk
User
Posts: 6
Joined: Wed Dec 12, 2012 6:39 am

Re: Applications from the website to Bullhorn

Post by scdk » Fri Jul 04, 2014 7:27 am

Thanks for the reply Brent, I'm still getting a little confused with this part of the api though.

As far as I can see it means that all clients have to be created.
  • What should be their unique identifier?
    Their email?
    Should we just give them a random password?
    What userType should they get?
    What category should they get?
    What would happen if the client was already created?
It seems that regular job orders would be
  • Client submits an application
    We get the job from the DB
    We get the Candidate from bullhorn (to not create the same candidate a billion times) using eg., their email as unique identifier
    We update/insert the candidate
    We call /resume/parseToCandidate and get (something) back
    We call /entity/JobSubmission with the data we get back from step 5.
    We add it to our own database
I cannot find any documentation in /resume/parseToCandidate. What data should be there? What does it return? JSON? XML? How do we send the resume? A raw bytestream in the body?

What would happen if one of these calls fail/time out?

Sorry for all of the questions, thanks for any help :)

srg.bdavis
User
Posts: 67
Joined: Thu Feb 20, 2014 4:52 pm

Re: Applications from the website to Bullhorn

Post by srg.bdavis » Sat Jul 05, 2014 6:14 pm

What should be their unique identifier?
We use the email address.
Should we just give them a random password?
If the user is applying for a position, we generate a random password as part of the application process. If they are just registering with us and not applying for a particular position, we allow them to choose their password.
What userType should they get?
I'm not familiar with this field. What are the options?
What category should they get?
If a user is applying for a position, we set the category to match the category on the job order. If they are just registering on the site, we give them an "Area of Interest" dropdown that corresponds to the categories.
What would happen if the client was already created?
During the application process we check to see if the email address already exists in the system. If the address does not exist a new candidate record is created. If the address does exist, the creation process is skipped and we grab the existing candidate id to create the job submission.

Your workflow is close, but the /resume/parseToCandidate step happens sooner:

1. The candidate clicks Apply after viewing the details of an order posted on the site.
2. They are taken to the application page which asks for their name, email address, phone number and optional resume. They also have the option to add any additional comments.
3. The candidate clicks "Submit Application"
4. The website then checks to see if the candidate already exists in the system based on their email address. If the candidate already exists, the id is used in the call to /entity/JobSubmission. If the candidate does not exist, a check is made to see if a resume was included in the application. If a resume was included, a call is made to /resume/parseToCandidate. The result of that call is used to create the candidate record (with the resume attached). If a resume was not included, the name, email address, and phone number is used to create a candidate record. The id of the new candidate record is then used in the call to /entity/JobSubmission.

For information on resume/parseToCandidate, check out the "Rest API Reference" on this page http://developer.bullhorn.com/documentation. It is on page 63.

Post Reply