Solutions / Recruiting and staffing / Collapsing one person into a single candidate record

Collapsing one person into a single candidate record

The same person arrives as a board application, then as a referral, then again when a second recruiter uploads a document that came in by email. Bullhorn checks for duplicates on the email address, which is the field most likely to differ between a personal account and a work account. The REST API offers no merge operation at all, so an equivalent has to be assembled out of reads and writes across every submission, note, attachment and interview record. Deciding which record survives matters more than spotting the pair, since activity history is what settles ownership later.


Context / recruiting and staffing Why this one is worth doing here

The parser reads the resume, then somebody corrects the employment dates it merged, which is most of the time it was supposed to save.

Resumes arrive in every format that has ever existed, including scans with no text layer and designed templates in two columns that get read in the wrong order. Parsing is nearly always a third-party component, and its characteristic failure is employment history: dates written as ranges with words in them produce merged employers and wrong tenure.

Systems this usually touches

  • Bullhorn
  • JobDiva
  • Textkernel

When this is the wrong thing to build

Pick something else if the database is small enough to eyeball, or if recruiters work exclusive desks and never touch the same person. Merging is destructive. A bad merge that moves submittals onto the wrong record costs more than the duplicate ever did, and reversing one is manual.

The constraint that shapes it

This is the sector where the boundary is sharpest, and it is worth stating plainly: rejection is the regulated act, not enrichment. More on how this sector works.

The same shape elsewhere / Reconciliation 12 sectors run it

Two sources of truth. One queue of the rows that do not line up. Read what this shape is, or start from one of these.

Real estate
Rebuilding an annual operating expense reconciliation from the lease
Real estate
Reconciling a broker trust account three ways every month
Real estate
Matching a closed transaction back to the lead that produced it
Real estate
Collapsing two overlapping MLS feeds into one property list
Law firms
Widening a conflicts search past exact spelling
Law firms
Rebuilding a billable day from the trail the systems already keep
What people ask about this 5 of them
  • How do I merge two candidate records in Bullhorn without losing notes?
  • Does the Bullhorn API have a merge operation for candidates?
  • Why do the same people keep arriving as brand new applications?
  • How do I match a candidate on phone number and resume text?
  • Which record should survive when two recruiters own the same person?

Back to recruiting and staffing, or see how this is priced and scoped.