Duplicate applications exist in a lot of different forms in Greenhouse, but they can all cause confusion and significantly more work for your users. Auto-merging will allow Greenhouse to programmatically look at new candidates and prospects who are entering the system and merge the profiles, which should drastically cut down on the amount of merging your Site Admins need to do on a daily basis. This feature does not work retroactively, so any duplicates currently in your account will still need to be merged manually.
To enable auto-merging, a Site Admin can navigate to the Configure > Organization page and toggle the feature on. Only candidates and prospects with identical email addresses will be merged. If an email matches two different unmerged profiles, we will assess the names of each one to see if there is an identical match with the new applicant's name and merge with this one. If both the old profiles have identical email addresses and identical names (or identical emails and names that don't match the new applicant at all), the profile that has the most recent activity (emailed, moved stages, rejected, etc.) will be chosen.
When deciding which criteria to use when combining profiles, we identified a number of ambiguous cases where merging seemed like it would cause more pain and frustration than it saved, so we opted not to automatically merge in these situations.
Cases Where We Do Not Merge
- A candidate or prospect is created by a third-party integration (like Entelo, Hired, or Connectifier).
- Since we don't know how each and every third-party integration might be adding candidates and prospects to your account, any profiles created via the Candidate Ingestion API will not be evaluated by Auto-Merge. Please Note: If you've given a Job Board API key to an integration partner, candidates they import could be merged automatically. This API works just like your job board, so we don't make a distinction between candidates they add and candidates who apply directly. This is an uncommon setup, but one we see every once in a while. You can see which API keys you've given out on the Configure > Dev Center > API Credential Management page.
- A candidate or prospect matches a candidate who is only on one or more confidential jobs.
- Because many users might not know that a confidential job even exists, we don't want to risk merging the profiles automatically and giving users insights that they shouldn't have about the candidate or the others jobs he or she might be on.
- A Candidate is Hired on a job, then applies again for the same job.
- This could potentially happen for contract or seasonal employees who work for a short period and then apply again for the same role. Since both cases seem detrimental - unhiring them and moving to Application Review vs. having the new application absorbed into the hired profile so that no one ever sees it - we've decided to keep them separate.
- An agency recruiter submits a candidate
- Since there could be questions about whether the agency should get credit for a duplicate candidate, we've decided not to merge in this case. Furthermore, some agency recruiters prefer to list their own email addresses instead of the addresses of their candidates, and it would be chaotic if every candidate from a particular agency was inadvertently merged into one giant, messy profile.
- A user submits a referral to Job A and they match someone else on Job A.
- Much like with the agency recruiter situation above, there could be implications - (financial or otherwise) for one of your users losing credit for a referral. If two users submit the same referral, we've decided it's safer for one of your users to manually decide which one should get credit rather than simply picking one.
- A user submits a referral to Job A and they match someone else on Job B
- When a user submits a referral, they normally receive an email notification informing them of the successful submission. As a safeguard against the referrer being notified of the candidate applying to another job, we've decided that this should be a decision by one of your users to merge the profiles.
Understanding the Greenhouse Data Model
Before we get into the different auto-merge cases, it might be helpful to identify which information is candidate-specific and which information is application-specific to better explain how we decide what to keep during a merge.
Candidate-specific information includes fields that can only have one value, no matter how many jobs a single candidate might be on:
- Previous Company
- Previous Title
- Candidate Custom Fields
Application-specific information includes fields that can be different for each job a candidate is on:
- Application Questions
Bear in mind, information is never deleted in an auto-merge, so any deprecated fields will always be listed on the Activity Feed after a merge. Furthermore, a separate Activity Feed entry will let you know that a candidate or prospect was auto-merged in the first place.
Let's say James Bond applies online and matches the email of a candidate named Harry Potter. Greenhouse can only choose one name to display, so the other one will be removed and added to the Activity Feed for posterity. If they applied to different jobs, though, each one could have a separate source associated with each job. For fields that support many entries, like phone number or address, we will simply save everything in a big list and let you decide which one to use later.
Different-Job Merge Cases
The easiest and most straightforward merge is done by combining candidates on two different jobs. While we still have to choose Candidate-specific information that will apply to both profiles after the merge, all of the application-specific data will be preserved on each profile separately.
- A candidate is Active on Job A, then applies online for Job B.
- The two applications will be merged, with the Candidate-specific information from Job A listed on the merged profile. This ensures that the hiring team from the older profile won't lose track of a candidate that they might already be working with.
- A candidate is Rejected on Job A, then applies online for Job B.
- The two applications will be merged, with the Candidate-specific information from Job B listed on the merged profile. Since the old hiring team won't be dealing with this candidate anymore, the new team is assigned and will see that the candidate was previously rejected while in Application Review.
- A candidate is Hired on Job A, then applies online for Job B.
- The two applications will be merged, with the Candidate-specific information from Job B listed on the merged profile. This might be common for internal applicants who are transferring to a different team or department. Rather than assign the team who initially hired them, the information from the new position will take precedence.
Same-Job Merge Cases
When a duplicate is flagged for the same job, candidate- and application-specific information is merged into one profile, meaning a candidate applying to the same job 10 times from 10 sources will only end up with one listed on their source tab while the rest will be deprecated on the Activity Feed.
- A candidate is Active on Job A, then applies online for Job A. (Note: This will also apply to a Prospect who matches an active Prospect or any Candidate)
- The two applications will be merged, with the Candidate-specific information from the older one listed on the merged profile. Any new information will be absorbed into the older profile and they will continue to be managed like they never applied a second time.
- A candidate is Rejected on Job A, then applies online for Job A. (Note: This will also apply to a Prospect who matches a rejected prospect)
- In this case, the two people will be merged, with the Name and Source coming from the older, rejected application. The candidate will be transitioned from Rejected to Active and will be placed in the first stage of the job's pipeline so they can be evaluated again. Any scorecards you've filled out on their rejected profile will be retained on the Scorecards tab, but the rest of the Stage tab will reset and be completely fresh so they can be moved through the pipeline again. If a candidate applies a year after being rejected, they will be given a fresh opportunity to be evaluated again, and if they abuse this ability and apply right after being rejected, you can Mark them as Spam to stop this bad behavior.
- A candidate applies and matches any prospect.
- The Name and Source will be taken from the older, prospect profile, but the rest of the information will be absorbed into the single candidate profile. Because a candidate is typically more valuable than a prospect who has not committed to applying to your company, we prioritize more of the candidate information than the prospect's status (even if the prospect was rejected).
There's one more case we haven't talked about quite yet. If a candidate or prospect is created via the prospecting plugin or the 'Add a Candidate' page, we handle things a little differently. For Basic Users, Interviewers, and Job Admins, the new person will be added normally, then the appropriate auto-merge rule will be applied behind the scenes.
For Site Admins, they will see the same merge warning that appears now. If they choose not to merge the profiles, the profiles will not be merged at all.