Possible candidate handoff methods
With any ATSes, we have 4 ways of loading applicants to the partner system:
Where we just send a candidate to a provided inbox with a specified subject line. Based on that candidate gets uploaded to a correct vacancy in partners system under correct source.
In this instance, we can either use global CC feature or traffic light system in V2 (V3 can also be set to forward the email to global CC based on status using V2 account connected to that V3 one).
- lots of systems use it and it simply works
- no development usually needed from either site
- partner is fully responsible for uploading the candidates to the ATS. This might cause us to look bad if something doesn't work on partner's end.
- rather troublesome debug on our part if someone claims emails are missing. They are always sent, but in really rare occasions destination folder rejects them. Logs can be obtained from idibu's FTP in /var/log/mail.log.gz This file has logs for emails sent in the present day. When the days end, the file gets renamed to mail.log.1.gz. We store a month of email logs. Log only contains time, the email destination and sent status. It is impossible to link it with a specific subject or email id. Thus, its usability is rather limited.
2. API interaction
[ DOCS], where we contact your APIs and upload the candidates based on the provided API tools to a correct vacancy in partners system under correct source.
- rather straight forward to code for the external party
- detailed docs based on mechanisms we used for ages and they are well tested - RDB integration is heavily based on this
- it's not one but several different APIs that give similar info in different ways. Thus, partner can choose what works best for him
- easy de bug: all API calls are logged and can be accessed for the USS tool.
- some partners can be reckless with API and hammer it causing issues for all idibu - while we have faced and prevented similar issues in the past, one never knows
- medium amount of support for the partner is usually necessary
- data is provided on demand, which may lead to having unhealthy crons that query idibu far too often.
[ DOCS], where we provide candidates structured XML and listener on partner's part load the candidates to a correct vacancy in partners system under correct source.
- current worldwide standard
- no possibility of affecting idibu's performance
- partner receives data in real time, as they appear on idibu
- re-queue system if a call fails
- fail messages for calls are recorded on V3's end
- V3 only
- no live usage yet - possible bug-fixes and further development required
- possible need of docs improvement
4. Using partner generated landing pages
[ DOCS], where idibu provides instructions on how to update those so that landing page uploads the candidate to a correct vacancy in partners system under correct source.
- a well-tested procedure that is utilized by i.e. transline and pertemps.
- no additional development work on idibu's end
- partners do have issues grasping the overall concept of this flow. This procedure had to have a 2nd, dedicated.
- possible high amounts of support necessary
- this setup has a lot of chain elements when things can go wrong. and if they do, candidates might go to a black hole if partner's developement isn't spot on.