One Person, Two Work Emails: Reconcile the Contact Without Restarting Outreach
When the same person has an old and a new work email at the same employer, reconcile the person before selecting the address. Establish that both addresses belong to that individual, preserve the existing conversation and outreach restrictions, and decide which address is appropriate for any already-authorized next action. A new email address does not make an existing prospect new again.
The workflow below is a proposed operating method for that narrow situation. It does not cover a job change, a company rebrand, or a possible match between different people. If the identity or employer relationship remains uncertain, retain separate records with a review flag instead of forcing a merge.
Separate identity, employment, address quality, and outreach eligibility
These questions require different evidence. A deliverable mailbox does not prove who reads it. A matching company domain does not establish that two records represent the same employee. An address discovered recently does not erase an earlier reply or opt-out.
| Question | Evidence to inspect | What it does not establish |
|---|---|---|
| Is this the same person? | A verified existing relationship, attributable address-change information, and corroborating person details. | A similar name or a shared domain alone does not establish identity. |
| Is this the same current employer? | Current employment information associated with that verified person. | Historical account association does not prove current employment. |
| Which address is usable? | Address-specific verification, source, and any explicit address preference. | Mailbox verification does not identify its reader or grant outreach permission. |
| What may happen next? | Prior conversations, preferences, enrollment state, ownership, and applicable restrictions. | A new address or newly created record does not reset these decisions. |
Unify’s B2B company and contact data can supply research and enrichment inputs. Treat those inputs as evidence to evaluate alongside your existing records, rather than as proof of automatic email-alias reconciliation.
Establish the person before changing the primary address
Begin with the record that contains the known relationship. Inspect the original email thread, the associated person and company, and the source of the proposed replacement address. Record whether the change came from the person, a colleague, an enrichment result, an import, or a rep’s edit. Each has a different evidentiary basis.
An explicit address-change message in an established conversation can support the decision, but inspect who actually sent it. A forwarded thread, familiar display name, matching signature, or working redirect can occur without proving that the new mailbox belongs to the original recipient. The guide to verifying a respondent using a different address explains how to inspect that distinction before assigning the message to a person.
Corroborate the current employer and role using available reliable sources. The target-account contact research workflow is useful for collecting relevant person and employment context while keeping unresolved fields visible. Do not turn agreement between two copied data records into independent confirmation.
Give the review a clear outcome: confirmed same person at the same employer, unresolved identity, or outside this workflow. Only the confirmed outcome proceeds to reconciliation. For unresolved identity, preserve the evidence and assign an owner; do not test the match by sending prospecting messages to both addresses.
Preserve the record before stopping or moving work
Capture the source record IDs and the intended surviving record before making changes. The newer record may have a better address while the older record holds the conversation, owner, exclusions, and activity history. Choosing the record with the most recent creation date can discard the very context that makes the reconciliation safe.
Create an internal reconciliation note using this blank checklist. Link to actual system records rather than copying unnecessary message content into a spreadsheet.
- Verified person and current employer: [record references and supporting evidence].
- Address A and address B: [source, observed status, verification scope, and check time].
- Conversation and activity history: [thread references, replies, calls, and relevant outcomes].
- Restrictions and preferences: [original request, scope, source, and current enforcement].
- Active work: [enrollments, scheduled steps, open tasks, list membership, and responsible owner].
- Proposed surviving record and field changes: [IDs, values, reason, and reviewer].
- Unresolved questions and release decision: [owner, evidence needed, and permitted next action].
Review both records for pending execution before editing either. In Unify, sequence enrollment management documents removing a person from a sequence while retaining their history. Choose the appropriate supported control for the affected enrollment and verify its outcome. Do not assume that editing an email field also cancels scheduled work, or that stopping one enrollment stops every task in another application.
The hold is an operational precaution during reconciliation, not a change in the prospect’s expressed interest. Preserve whether a conversation was active, finished, paused, or restricted. Do not replace those states with a generic “new lead” label to simplify the cleanup.
Choose an address without turning verification into permission
Assess the addresses separately. Keep an old address’s bounce or unresolved status attached to that address; do not transfer it blindly to the replacement. Equally, do not label the replacement verified merely because the old mailbox previously accepted mail.
Unify’s sequence rulesets distinguish invalid, catch-all, unverified, and role-based addresses. Invalid addresses are blocked; handling of the other categories depends on the ruleset. A catch-all domain or a technically valid role inbox still does not establish that the intended individual receives the message.
Record what was checked and when. The difference between created, updated, and verified dates matters here: changing the email field updates a record, but that administrative change does not certify the person’s employment or the new mailbox. Keep unresolved address information visible instead of filling the gap with a confidence label that nobody can explain.
If the person has explicitly supplied a preferred work address, preserve the underlying communication and its scope. That preference can help choose the destination for an existing conversation. It does not automatically authorize a new campaign, overturn an earlier restriction, or justify sending to both addresses.
Understand what imports and CRM matching actually do
A file containing both email addresses can create a matching problem even after a human has confirmed one person. Unify’s CSV import documentation says people are matched by email address. Existing matches can be updated with mapped values. That is email-based matching, not a documented guarantee that different addresses are reconciled into one identity.
The same boundary matters when writing to your CRM. The Salesforce bidirectional sync documentation describes email-based contact matching and explicitly states that Unify does not merge existing Salesforce duplicates. The HubSpot bidirectional sync documentation gives the corresponding limitation for HubSpot. When creation is permitted and no match is found, a new record may be created.
Accordingly, decide which existing record should receive the corrected address before running another import or sync. If a CRM merge is required, have the administrator review that CRM’s current merge behavior, related activities, secondary addresses, and rollback options. Do not assume every application preserves every relationship in the same way.
Where a merge cannot preserve the necessary context, retain the original records with explicit reconciliation references and keep the duplicate out of execution until the administrator resolves the mapping. A clean-looking list is not sufficient if the surviving record loses the original conversation or restrictions.
Carry forward history and the actual opt-out request
Preserve replies as evidence, not just as summary tags. Unify’s reply workflow lets the owner inspect messages and enrollment context. Confirm that the relevant conversation remains accessible from the record the team will use, and retain a reference to the original record if the history cannot be moved safely.
Restrictions must follow the verified identity and the actual request’s scope. Do not clear a person-level email opt-out because the address changed. If a request specifically concerned one address, preserve that wording rather than silently expanding or narrowing it. When scope is ambiguous, hold the affected action for review.
The guide to preserving call and email opt-out scope separates the original request from its implementation in individual tools. A restriction recorded in one system does not prove that every connected task, sequence, or duplicate record respects it. A channel-specific restriction also does not establish permission for another channel.
Review person and company exclusions against the final record and its company association. For users assigned an engagement policy, policy exclusions replace the ruleset’s exclusions. Confirm the applicable policy and ownership instead of checking only the visible sequence configuration.
Re-enrollment settings are another control to inspect, not evidence of cross-address identity resolution. Their documented checks operate on the person and enrollment history the system recognizes. Creating a separate record for the replacement address can leave the history fragmented; do not rely on a cooldown alone to prevent a restart.
Prevent the next sync from undoing the reconciliation
Inspect the processes that can write the email back: enrichment, CSV imports, CRM synchronization, plays, and rep edits. Determine which source is allowed to replace the selected value and which should merely provide a candidate for review. The account data maintenance workflow is relevant to finding gaps, but address replacement still needs the identity decision described above.
Review the appropriate Salesforce field mappings or HubSpot field mappings before enabling further writes. Read and write behavior are separate configuration decisions. Confirm the actual supported field mapping rather than assuming that a manual correction makes every subsequent source subordinate to it.
Keep the change narrow: the confirmed address and required record associations should change; historical replies, owners, restrictions, and lifecycle state should retain their intended meaning. For the broader implementation, the CRM data integration guide explains why field authority and creation rules need explicit controls.
Verify the final state without enrolling the person again
Use the following as proposed acceptance checks, not as a claim that a particular workspace has already passed. Inspect the live records after processing completes. Where a workflow must be exercised, use approved test records outside prospect outreach rather than triggering messages to the actual person.
- Identity: the chosen record points to the confirmed person and current employer; both source record references remain traceable.
- History: the original conversation, prior outcomes, owner, and applicable restrictions can still be found and interpreted.
- Address: the selected value has its own evidence and status; unresolved or retired values remain distinguishable.
- Execution: no duplicate active enrollment or unattended task was introduced by the change; any held work has an explicit disposition.
- Synchronization: a controlled subsequent update does not recreate outreach eligibility or restore the retired address without review.
- Release: the owner has recorded whether any next action is permitted and why; “address corrected” is not the reason to restart a sequence.
If these checks reveal missing history, conflicting restrictions, or renewed duplicate creation, keep the affected work on hold and correct the underlying record or writer. Reconciliation is complete when the team can use the right contact details with the original relationship intact, not merely when one email disappears from a list.
Frequently asked questions
Does the same name and company domain prove two emails belong to one person?
No. Treat those details as matching clues. Establish the person and current employer using attributable evidence and relevant existing context before reconciling the records.
Does Unify automatically merge two work emails for the same person?
The inspected import and CRM sync documentation describes email-based matching, not automatic same-person alias reconciliation. Salesforce and HubSpot sync documentation explicitly says existing CRM duplicates are not merged.
Should a new email address restart a completed sequence?
No. A new address alone does not justify fresh enrollment. Preserve the original person’s conversation, restrictions, and enrollment history, then review any proposed next action separately.
Which record should survive when one has history and the other has the newer email?
Choose through an administrator-reviewed reconciliation plan that preserves identity, history, ownership, and restrictions. Do not choose solely by record age or field completeness, and verify the CRM’s merge behavior before changing records.
What should happen if the replacement address or identity remains uncertain?
Keep the uncertainty explicit and hold the affected outreach. Assign a reviewer, preserve the source evidence, and avoid merging records or sending to both addresses merely to test the match.

