Implementing ChartHop
...
Workflows
HiBob + Lever (Outbound)
hibob + lever in charthop integration guide how the two systems interact, where they hand off data, and how to avoid conflicts hibob and lever sync into charthop independently, but their data intersects at two critical moments when a new hire is made, and when a contractor fills (or shouldn't fill) an open headcount slot understanding these handoff points is the core of running both integrations correctly how the two systems connect hibob and lever don't communicate with each other directly charthop is the connective tissue each system writes data into charthop on its own schedule, and charthop's matching logic determines how records from both systems relate to each other there are two join points that matter join point hibob side lever side how charthop links them person matching employee record, identified by hibobid candidate record, identified by email charthop matches the lever candidate to the hibob created person by email address (home email first, then work email) job matching hire change synced from hibob lifecycle history open requisition, identified by leverreqid stored on the charthop job when lever fires a hire webhook, charthop looks for an open job with a matching leverreqid and links the hire to it everything else each system does (hibob building the org chart, lever managing candidate stages) is independent conflicts only arise at these two join points the new hire workflow when a new hire is confirmed, both hibob and lever will create data in charthop independently charthop has multi step matching logic designed to prevent duplicates regardless of which system syncs first how charthop matches people when the hibob sync brings in an employee, charthop uses the following matching process hibob id match looks for an existing person with a matching hibobid contact this is the primary and most reliable match contact match (unassigned people only) if no hibobid match is found, it searches people who don't yet have a hibobid contact and compares their existing contacts (email, phone) against the incoming person's contacts both fallback steps only search unassigned people — people who don't have a hibobid contact yet if a person was already created by another system (e g , lever) and is assigned to a job, they will still be found by the contact fallback as long as the email address matches when lever fires a hire webhook, it matches candidates by email address (home email, then work email) before creating a new person in most cases, this means the order doesn't matter — whichever system syncs second will find the person created by the first system via email matching when duplicates can still occur duplicates are rare but can happen when all of the following are true the person created by the first system is already assigned to a job (which removes them from the unassigned matching pool) the email addresses differ between lever and hibob (e g , personal email in lever vs work email in hibob) the most common scenario lever hires a candidate using their personal email, assigns them to a job immediately, and then hibob syncs with their work email the hibobid match fails (doesn't exist yet), the contact fallback fails (emails don't match), and a duplicate is created how to prevent duplicates use consistent email addresses across systems if lever and hibob both have the same email for the candidate, matching will succeed regardless of sync order if duplicates occur monitor for duplicate person records after hiring events a duplicate will typically appear as two people with the same name or email — one with a hibobid contact and one with a lever contact merge the duplicate promptly the merged record must retain both contacts — the hibobid contact and the lever contact — so future syncs from both systems match correctly do not delete either record before merging deleting removes the associated contact, which can break future sync matching a note on "hired" vs "employed" status in hibob hibob distinguishes between two pre start statuses "hired" (offer accepted, not yet started) and "employed" (active in hibob) charthop intentionally does not sync workers with a "hired" status — only "employed " this is by design, since a pending hire in hibob is not yet a charthop employee record the consequence charthop won't create a person record from hibob until the employee's status is "employed " employees with a future start date will appear in charthop as "starting" and may be excluded from default org chart views until their start date arrives contractor headcount conflicts when hibob syncs a new hire, charthop tries to place that person into an existing open job by matching on job title and reporting manager this matching does not currently filter by employment type a contractor synced from hibob can inadvertently fill an open permanent headcount slot if the titles match why this happens lever manages open requisitions hibob manages all workers, including contractors if a contractor is hired with the title "software engineer" and there's an open req for "software engineer" under the same manager, charthop's job matching may link them — removing the req from the open headcount pool mitigations option how it works tradeoff distinct contractor titles use a consistent suffix in hibob for contractors (e g , "software engineer contract") this prevents title matching against permanent reqs requires discipline in hibob data entry title mismatch is permanent unless you rename the contractor record exclude contractors from hibob sync use the excludeemployment option on the hibob integration to skip contractor employment types entirely manage contractor records manually in charthop contractors won't appear in org charts or headcount data unless entered manually higher maintenance overhead post sync review after each hibob sync, review contractor placements and manually correct any that filled the wrong slot reactive, not preventive works for low contractor volumes but doesn't scale what happens when a lever hire webhook fails if the lever hire webhook fires but charthop can't complete the hire, check the charthop process log for details the most common causes specific to the hibob/lever interaction person not found by email the candidate's email in lever doesn't match any person's home or work email in charthop usually means hibob hasn't synced the employee yet (see sequencing above), or the emails differ between systems candidate has no email address a lever candidate must have an email address for charthop to attempt a match at all candidates without an email will always fail no matching open job the leverreqid on the lever req doesn't match any open job in charthop, or the job already has recruit status "pending " verify the req id is correctly set on both sides no signed offer in lever the hire webhook requires a signed offer a verbal accept or offer in progress won't trigger it setup checklist running both integrations together before going live with both integrations simultaneously \[ ] confirm the candidate email used in lever matches the work email entered in hibob for all current employees consistent emails across both systems are the most reliable way to prevent duplicate person records \[ ] verify that leverreqid values are correctly populated on all open charthop jobs before enabling the lever sync \[ ] confirm your hibob contractor employment types (e g , "contract," "fixed term") are standardized non standard values (e g , "consultant," "external") won't be classified correctly by charthop and may cause contractors to be treated as standard employees in headcount calculations \[ ] after the first hiring event under the combined integration, verify the resulting charthop record has both a hibobid contact and a lever contact attached
