A researcher exports a list, a colleague removes unsuitable people, and an automation later looks up emails. If the automation reads the original export or a live spreadsheet that keeps changing, the review may have no effect on what gets submitted.
Treat the reviewed shortlist as a distinct input artifact. Preserve the original export, record the decisions and make the downstream job consume a named snapshot. This guide proposes an application-side handoff design with fictional records. It does not report a new vendor test, contact lookup or production deployment.
Decide what the first delivery contains
Start with the handoff requirement rather than the export button. Does the reviewer need identity fields to choose a shortlist, or does the first delivery already need email research for everyone?
That sequencing decision belongs in tool selection. Inspect the specific export route and its settings before assuming contact lookup can be deferred. A product's standalone upload route may differ from its search-export route. This article makes no claim that a named vendor implements the approval flow below.
For a review-first workflow, define the required identity evidence and the decision owner. A role or employer field can help the reviewer decide, but its presence does not establish that the person still meets the requirement. Keep uncertain rows pending instead of filling gaps with guesses.
Preserve the original and record decisions separately
Give the export a batch identifier and retain its original record keys. Do not overwrite that file while cleaning names or excluding records. A separate decision table can link each input identity to an outcome and a reason.
Use an explicit state such as approved, rejected or needs_review. An empty decision should mean pending, not implicit inclusion. Preserve the reviewer and decision time so a later question about a submitted person has a concrete answer.
A fictional decision record could be:
{
"input_batch": "fictional-export-12",
"input_record_id": "row-27",
"identity_key": "reviewed-identity-27",
"decision": "approved",
"decision_reason": "meets-current-role-and-employer-criteria",
"reviewer_ref": "assigned-reviewer",
"decision_at": "2026-11-01T09:00:00Z",
"criteria_version": "shortlist-v2"
}
The identifiers, reason and timestamp are examples, not collected personal data. Keep the underlying employer evidence available through the team's approved record references. A decision label alone is not a substitute for that evidence.
Create a snapshot for the next job
When review is ready for handoff, produce a separate file containing only the approved identities and the minimum fields needed for the permitted lookup. Give it a version and a creation time. Record how many approved distinct identities it contains.
The lookup job should reference that artifact rather than a mutable “latest” sheet. If a reviewer later changes a decision, create a new snapshot and decide what to do with already submitted work. Editing the sheet cannot retroactively change a request that another service has accepted.
Useful handoff checks include:
| Check | Why it matters |
|---|---|
| Each output identity maps to an original input | Prevents unexplained additions |
| Every submitted identity has an explicit approval | Keeps pending rows out |
| The approved decision uses the intended criteria version | Avoids mixing review rules |
| Duplicate input rows resolve to documented identity keys | Prevents repeated lookups |
| Snapshot count matches the approved distinct set | Makes the handoff reconcilable |
These are proposed acceptance conditions. Validate them against the actual files and service interface before relying on the process.
Bind retries to the same submitted input
Record the snapshot reference with the provider job identifier. If the connection drops, inspect that job and its existing results before sending another batch. A missing response does not prove the lookup never happened.
Track unresolved identities separately from the original snapshot. A retry should explain whether it resubmits the same approved input, uses a reviewed correction or starts a new version. Preserve any provider request reference that helps investigate repeated charges or duplicate results.
Do not change an identity's employer context silently during recovery. A corrected employer may be a legitimate improvement, but it changes the lookup input and should be traceable to a new decision or documented correction.
Reconcile delivery against the snapshot
Join returned candidates back to the submitted identities using stable keys. Keep identities with no match in the result ledger rather than dropping them. Also separate failed requests, unresolved verification statuses and records that need identity review.
Preserve provider labels alongside your local acceptance decision. A returned address is not automatically an accepted contact, and an accepted research record is not evidence of email delivery. The lookup stage does not authorize sending a message.
For cost review, compare what was actually submitted and accepted, using the same scope and criteria. Keep export, lookup and verification charges distinct where the route bills them separately. Avoid reusing assumptions from another endpoint merely because it belongs to the same provider.
BrowserAct's export-and-lookup comparison supplies the sequencing question behind this design. The snapshot makes the answer enforceable in the handoff: the next job receives the reviewed set, and the team can explain every inclusion, omission and retry.
Top comments (0)