A contact pipeline often starts with two useful outputs: fields observed in an authorized browser session and an email address returned by a separate provider. Combining them into one email column is convenient until someone asks where the address came from or why it belongs to that person.
Our agent skills versus dedicated email tools comparison explores the choice between buying a workflow and maintaining an integration. This post focuses on one implementation detail: preserving the evidence when browser extraction and enrichment disagree. It is a design example, not a report of a live contact-extraction run.
A blank observation is still data
Suppose the browser reached the intended profile, but the account could not see an email address. That observation does not prove that the person has no email. It also does not authorize the pipeline to invent one.
Record the access outcome and the field outcome separately. An unavailable page, a failed extraction, and an accessible page with no visible address require different follow-up. If all three become an empty string, a later operator cannot tell whether another extraction attempt is useful.
Keep the original observation after a provider lookup. A provider result may add useful evidence, but it should not rewrite what was visible in the browser at the time.
Keep two records before making one decision
Here is an illustrative application-side shape. The address uses the reserved .test domain and is fictional; none of these fields is presented as a vendor's API schema.
{
"record_ref": "example-contact-001",
"browser_observation": {
"page_access": "confirmed",
"email_visibility": "not_visible",
"visible_email": null
},
"provider_result": {
"address": "person@example.test",
"identity_match": "unresolved",
"verification_label": "deliverable"
},
"decision": {
"status": "review_identity",
"accepted_email": null
}
}
The record deliberately has a provider address and no accepted address. A deliverability label describes one property of an address; it does not resolve whether the provider matched the correct person or employer. The identity decision still needs evidence.
The reverse case is also useful: an address may be visible on the page while an external lookup returns nothing. Preserve the observed address and its source. Whether it should enter a downstream system depends on your team's acceptance rule, not on the availability of another provider result.
Separate observation, verification and acceptance
Use different fields for what the browser observed, what the provider returned, what verification reported, and what a reviewer or policy accepted. Store the relevant source reference and observation time with each piece of evidence.
Avoid a rule such as accepted_email = visible_email or provider_email when it discards identity checks or source requirements. A nonempty string is not enough to express why a value was accepted.
Define explicit outcomes for unresolved identity, provider failure, rejected address and accepted address. A failed provider request should remain a technical failure, rather than being converted into evidence that no address exists.
Make retries add evidence
Give the contact a stable internal reference so a later lookup can attach a new result without replacing the earlier observation. Keep request time, provider reference and relevant status. Avoid logging session cookies, access tokens or unnecessary personal fields.
If a profile becomes unavailable, retain the earlier observation with its timestamp rather than pretending it was freshly observed. If the employer changes or two people have similar names, keep the conflict visible until the identity mapping is resolved.
Retries should follow the unresolved step. An extraction failure may justify another page observation. A provider timeout may justify another provider request. An identity conflict requires review; repeatedly running the same lookup does not resolve it automatically.
Choose the workflow after defining the handoff
A dedicated tool can be the clearer route when its standard inputs and reviewed export match the job. A browser skill plus an enrichment integration earns its maintenance cost when source preservation, custom decisions or exception handling matter to the receiving team.
BrowserAct can supply a browser execution step, but that does not make it an email database or prove the quality of a separate provider's result. The integration should make the boundary visible. Before writing a value into a CRM, a reviewer should be able to explain which source supplied it, what checks passed and what remains unresolved.
Top comments (0)