Duplicate applications can cause confusion and significantly more work for your users. Auto-Merging allows Greenhouse to programmatically look at new candidates and prospects who are entering the system and merge profiles, which should drastically cut down on the amount of merging your Site Admins need to do on a daily basis. In this article we will cover:

Note: This feature does not work retroactively, so any duplicates currently in your account will still need to be merged manually.


Enable Auto-Merge

To enable the Auto-Merge feature, click the Configure icon Configure.png in the upper right-hand corner and navigate to Organization on the left-hand panel. 

From the Organization page, toggle the button next to Auto-Merge Candidates ON.


Only candidates and prospects with identical email addresses will be merged. If an email matches two different un-merged profiles in the system, Greenhouse will assess the names of each existing profile to see if there is an identical match with the new applicant's name and merge any exact match. If both preexisting 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 and merged with the new applicant.

When deciding which criteria to use when combining profiles, Greenhouse has identified a number of ambiguous cases where merging profiles seemed like it would cause more pain and frustration than it saved, so we opted not to automatically merge in these situations. For more information on cases where we do not Auto-Merge, please click here.


Understanding the Greenhouse Data Model

Before we explore different Auto-Merge cases, it is 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 associated with. These include:

  • Name
  • Previous Company
  • Previous Title
  • Recruiter
  • Coordinator
  • Candidate Custom Fields

Application-specific information includes fields that can be different for each job a candidate is associated with. These include:

  • Stage
  • Source
  • Status
  • Application Questions
  • Attachments

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 inform you that a candidate or prospect was Auto-Merged in the first place. 

Example: If James Bond applies online and matches the email of a candidate named Harry Potter, Greenhouse can only choose one name to display, so the name belonging to the older profile 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.


Cases Where Greenhouse Will Not Auto-Merge

  • A candidate or prospect is created by a third-party integration (like Entelo, Hired, or Connectifier).
    • Since we do not 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 or Harvest API will not be evaluated by Auto-Merge. 
    • Note: If you have 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 do not 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 have given out on the Configure > Dev Center > API Credential Management page.
  • A candidate or prospect matches a candidate or prospect who is on one or more confidential jobs. 
    • Because many users might not know that a confidential job even exists, we do not 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.
  • An agency recruiter submits a candidate
    • Since there could be questions about whether the agency should get credit for a duplicate candidate, we have 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 have decided it is safer for one of your users to manually decide which user should get credit rather than choosing for you. 
  • A user submits a referral to Job A and they match someone else on Job B
    • 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. 
  • A candidate applies or is added manually and matches a private candidate or prospect
    • Because the concept of a private candidate applies to every job they're on, we want to protect against a case where a new candidate applies and is only accessible by a few select people. In this case we'll leave the two profiles separate so an Admin can determine whether they should have the same privacy settings or not.
  • A candidate profile has had any data anonymized via candidate privacy tools. 


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. Note: If the Hired candidate on Job A is private, the two profiles will be kept separate.


Same-Job Merge Cases

When a duplicate is flagged for the same job, candidate- and application-specific information is sometimes merged into one profile, meaning a candidate applying to the same job 10 times from 10 sources could 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 or Hired on Job A, then applies online for Job A. 
    • In this case, the two profiles will be merged, but every application will be preserved for your records. 
  • A candidate applies and matches any non-confidential prospect.
    • The Name and Source will be taken from the older, prospect profile, but the rest of the information will be added to a secondary prospect application on the same person


Manually Created Candidates/Prospects

There is one more case we have not discussed yet. If a duplicate candidate or prospect is created via the prospecting plugin or the Add a Candidate page, we handle things a little differently. For users without permissions on the job, the new candidate or prospect will be added normally, with no information regarding a potential duplicate profile or a merge option presented to the user. Once the duplicate candidate or prospect is added, the appropriate Auto-Merge rule will be applied. The user who submitted the candidate or prospect will not see a notification regarding the Auto-Merge. 

For Site Admins and users with Job Admin permissions on the job where they are adding the candidate/prospect, they will see the merge warning shown below. If the user chooses not to merge the profiles, no Auto-Merge rule will be applied, and the profiles will not be merged.