The gap nobody has time to close
Every database has them. A strong candidate with good notes and no mobile. A client contact with a name, a job title and no email. Each is a record you paid to create and cannot use, and nobody fixes them, because it is one lookup at a time and there is always a live role that matters more.
The usual workaround is an export, an enrichment tool and a re-import. That round trip is where duplicate records and overwritten fields come from. This play works on the record where it lives. It reads what is empty, looks up only that, and writes only into empty fields, after you have seen the list of changes.
What you get back
The records in your segment, updated in place, plus a change log as a file: record id, field, the value written, the provider it came from, whether it was verified, and what it cost.
Two shorter lists come with it. Records where nothing was found, so you know the gap was tried and is real. And records where the found value differs from the one you hold, left untouched for you to decide.
Variations worth knowing
Client contacts instead of candidates. The same play on the other channel. Hiring managers get work email, and each address is checked against the employer on the record before it is accepted.
A file instead of write-back. If you would rather nothing wrote to your CRM, stop at the proposed changes and take them as a CSV keyed on your record id.
Add the LinkedIn URL. A record with an email, or a name and an employer, can often be resolved to a profile. Do it early, because a LinkedIn URL is the strongest key for every later lookup.
Refresh before you fill. If the segment is old, run clean and refresh your database first, so lookups run against where people work today.
Where this goes wrong
A stale employer on the record. Work-email lookups lean on the current employer, and a found address is checked against it. If the record still shows a company the person left, good answers are rejected.
Thin records. A name with no employer and no LinkedIn URL cannot be matched. Those are listed as unmatchable, not guessed at.
API access on your CRM plan. Some systems open their API only on higher plans. Recruit CRM is one: on a lower plan every call is refused even with a valid key. The play says so and falls back to a file.
Rate limits. Your CRM caps API calls per minute and the agent stays under that cap, so a large write-back is slow by design.
Custom fields that fail silently. JobAdder can accept a custom-field write and not save it. The agent reads the record back to confirm, which is one more reason to check the first record yourself.
