The last step is where good lists get lost
A shortlist that lives in a spreadsheet is not in your business. Nobody else on the team can see it, it is not attached to the job, and in three months it is a file called final-v2 on someone's laptop. The question recruiters ask most often after a search is some version of "how do I get this back into my ATS", and the honest manual answer is an afternoon of copying and pasting, or a CSV import that creates a second record for every person you already knew.
This play is that afternoon, done properly. It checks before it writes, it writes one record before it writes the rest, and it tells you exactly what it did.
What you get back
Your CRM, with the list in it. People who were not there are created with the fields you mapped. Candidates are attached to the job. And a log file: one line per row saying created, already existed, linked, or failed, with the record id and, for failures, the reason the CRM gave. People who already existed are untouched.
Variations worth knowing
Prospects, not candidates. For a business development list the company comes first. Existing companies are found and reused, missing ones are created, and each contact lands under the right account and not as an orphan.
Note where they came from. Where the connection can write notes, which covers JobAdder, Recruiterflow and Atlas, each created record can carry a line saying which search produced it.
Straight from another play. The file a search hands you is already in the right shape, whether it came from turning a job spec into a shortlist or from enriching a list you already had.
Where this goes wrong
Rows with no email and no LinkedIn URL. They cannot be checked against your CRM with any confidence. Creating them blind is how duplicates are made, so they go to the pile that needs a look.
Your CRM's own duplicate rule. JobAdder rejects a candidate whose email already exists, and Atlas refuses to create a person whose email, phone or LinkedIn URL matches someone it holds. Both come back as already exists, with the existing id. The agent does not force a duplicate through.
A field that reports success and saves nothing. JobAdder accepts a custom-field value in the wrong shape and answers as if it worked. The first record is read back for exactly this reason.
Loxo and the job link. Loxo needs an email, a name and a phone number to add someone to a job. A row without a phone is created as a person and reported as not linked.
API access is a plan feature. Recruit CRM opens its API on its higher plans only. On a lower plan every request is refused even with a valid key, and the fallback is the CRM's own CSV import.
