Keep sourcing in Surhires and hand off to Lever cleanly

An integration page is not the place to argue that you should switch systems. If your team runs Lever, your interview process, your feedback, your offer flow and your hiring reporting live there, and moving them would cost far more than any sourcing tool saves.

What Lever is not built to be is a long-horizon relationship database for people who are not currently candidates. That is the gap teams fill with spreadsheets, saved LinkedIn projects and a folder of resumes, and it is the gap Surhires is built for: talent pools that stay warm, nurture sequences that run for months, rediscovery of people already in your database, and a full activity history on the person rather than on the application.

For an agency or RPO delivering into a client running Lever, the constraint is firmer still. The client owns the system of record and will not change it for a supplier. The supplier needs its own desk, its own pipeline and its own commercial data, and a delivery path into the client environment that does not involve typing the same profile twice.

The planned push creates or matches the candidate in Lever, attaches them to a specific posting, and sets the stage that was agreed with the hiring team rather than dropping everyone at the top of the funnel. Sourced candidates who have already had two conversations should not arrive as new applicants.

Data flows out of Surhires into Lever. The only thing planned to come back is the status and stage of the candidates you introduced, so a sourcer can see movement without holding a seat in the client or employer system.

Nothing else returns. Interview feedback, scorecards, offer terms, approval chains, internal notes written by the hiring team, EEO and demographic responses, and every candidate you did not introduce all stay in Lever. A sourcing layer that pulls a full candidate mirror out of an employer system is creating a second copy of somebody else's personal data with no lawful purpose of its own.

This is a design choice rather than a technical limitation, and it is the answer to the security review question that always comes: what does the supplier tool end up holding? The answer should be the candidates it introduced and the conversations it had.

Source attribution is the first casualty of manual entry. When a sourcer retypes a profile, the source field gets whatever the dropdown defaults to, and three months later the report says a third of hires came from an unhelpfully generic bucket. Attribution that survives the handoff is what makes internal sourcing measurable against agency spend.

The second casualty is context. Somebody spent six weeks warming this person up, and the ATS record starts with a resume and a name. A summarised outreach history means the recruiter who runs the screen knows what was already discussed, including the compensation conversation that has probably already happened.

The third is consent. Where a candidate was contacted under a recorded basis and agreed to be put forward for a specific role, that agreement is part of the record. Retyping a profile leaves it behind, and the question of why you hold somebody who never applied becomes harder to answer six months later than it was on the day.

Work the candidate to agreement in Surhires, then create them in Lever against the posting, upload the resume, set the source deliberately, and paste a short outreach summary into the note field. Ask the hiring team where sourced candidates should enter the pipeline and use that stage consistently.

Store the Lever posting and candidate reference back on the Surhires record in a custom field. It costs a few seconds, it lets you reconcile the two systems for reporting, and it means that when the connector arrives your historical records already carry the identifiers it needs.