Feed Ashby from a sourcing layer instead of retyping profiles

Teams that adopt Ashby usually do so partly for its reporting. That means the hiring funnel data in Ashby is not just an operational record, it is the number the leadership team looks at. Splitting that reporting across two systems would be a bad outcome, and a sourcing tool that quietly becomes a second funnel of record creates exactly that problem.

So the integration is designed to feed Ashby rather than to shadow it. Once a candidate is formally in process, Ashby is where the stages, the interviews and the conversion metrics live. Surhires keeps the part that happens earlier and lasts longer: the prospect who is not looking yet, the pool you rebuild a shortlist from, the nurture sequence that runs for two quarters, and the person who was a strong runner-up on a role that closed.

For an RPO or an agency working into a client on Ashby, the same rule applies from the other side. The client will not swap their system of record for a supplier's preference, and the supplier still needs its own commercial pipeline. One clean submission path solves both.

The handoff is a single write with everything attached, rather than a candidate record now and a resume upload later. The aim is that the recruiter who picks the candidate up in Ashby sees a complete profile with an accurate source and knows what has already been discussed.

Data moves from Surhires into Ashby. The single planned return is status and stage for the candidates Surhires introduced, so a sourcer can see progress without a seat in the hiring system.

Interview feedback, structured scorecards, offer details, approval chains, hiring team notes, demographic and EEO responses, and any candidate the sourcing layer did not introduce are not synced back. That is a deliberate limit. The employer collected that data under its own notices and controls, and duplicating it into a sourcing CRM would change who can see it without anybody having agreed to that.

It also keeps the analytics honest. If the funnel numbers only exist in one place, there is no argument about which system is right.

Most hiring systems are organised around live jobs. A candidate exists because a requisition exists, and when the requisition closes the record stops earning. That is fine for tracking a process and poor for building a talent function.

A sourcing layer is organised around people. The same person can sit in three pools, receive a nurture sequence, decline twice and accept on the third approach two years later, and the whole history stays on one record. When a new requisition opens, the first search is your own database rather than a fresh sourcing spend, and the candidates who come back are the ones you already have a relationship with.

The commercial version of that argument is straightforward. The cheapest hire is one already in your own database, and rediscovery only works if the database was built to be searched later rather than filled in as a by-product of a live process. That is a different data model, a different set of fields and a different retention posture from a hiring system, which is why the two tools coexist rather than compete.

Run the outbound work in Surhires. When a prospect agrees to be considered, create them in Ashby against the job, upload the resume, set the source field accurately rather than accepting a default, and paste a short summary of the conversation so far into the candidate note.

Agree with the hiring team which stage sourced candidates enter at, and apply it consistently, because inconsistent entry stages are what make funnel conversion reporting unusable. Then store the Ashby job and candidate references back on the Surhires record so the two systems can be reconciled without guessing.