The Job-Change Reconciliation Playbook: Moved Contact to Clean Record

A job-change feed tells you a customer or champion moved employers. This playbook turns each detected move into correct CRM records: new employer, verified email, re-assigned owner, old relationship history kept intact and linked to the old account, and no duplicate contact created. It is written for RevOps and recruiting-ops owners who run this on a weekly batch, and it is deliberately CRM-agnostic so the same move lands the same way regardless of who processes it and which platform they run.

Most of what ranks on this topic stops at "we alert you" or walks through a single Salesforce screen flow for one org. Neither gives you the rule for the overwrite-versus-create-new-and-link-versus-delete decision, nor the survivorship, identity-matching, and ownership-routing steps that follow. That is the gap this document fills.

Why moved contacts wreck a CRM if you handle them by hand

The core problem is that a job change destroys the same field most teams use to recognize the person. When someone leaves, their corporate email dies, the old record stays attached to the previous account, and they reappear with a new email and employer. Unless your system can connect those two identities, one person becomes two records with two histories, producing dead emails, outdated relationships, duplicate contacts, broken routing, and fragmented history.

This is not a rare edge case. B2B contact data decays at about 2.1 percent per month, compounding to 22.5 percent per year, a figure that originates in MarketingSherpa research and is validated by HubSpot's own decay simulation. Studies put the narrower job-change rate at 20 to 30 percent of B2B contacts annually, meaning a CRM without active maintenance has roughly one in four contacts at the wrong company within a year. Under certain conditions Gartner puts the upper bound at 70.3 percent.

The volume is real too. One vendor stopped repeating the folklore and measured its own database: about 1 percent a month, or 1,470,414 people changing companies in five months. So the question is not whether you will process moves, but whether you process them the same way every time. Improvised handling is where duplicates are born.

The three handling methods and why two of them lose

There are exactly three ways to handle a detected move, and only one is safe. Overwrite the employer on the existing record, delete the old record and recreate it, or archive the old record, create a new one, and link them. The default is always the third.

Here is what each choice actually does.

Overwriting looks tidy because the record "looks updated," but the old account's attribution silently vanishes. Deleting is worse: contact records carry field history, related tasks, events, and campaign memberships, and deleting legitimate records is risky enough that experienced admins never recommend it. Create-new-and-link is the documented best practice precisely because it preserves both histories and lets you see the person's full arc across two accounts.

Why email is the wrong match key, and what to use instead

Match on a stable profile URL or person ID, never on email. Email is an elective identifier that changes with each new job, and it is the exact field the move invalidates. That is the fundamental problem with email-first tracking: the field you use to identify someone is also the field most likely to become useless when the event you are detecting occurs. Roughly 23 to 30 percent of email addresses go stale each year.

A profile URL is stable and repeatable. It is one identifier you can drop into a CRM field and feed back into another tool later. Better still, a resolved person can carry an ID that stays the same across requests, job changes, and company moves. That is what lets you deduplicate records and detect when the same person shows up twice under two emails.

When you match, prefer company domain or profile URL over fuzzy name. Compare the enriched current employer to the account name stored on the contact, and only fall back to fuzzy name when neither domain nor profile link is available. Fuzzy name alone is dangerous: a personal email gives no employer, so you search on name alone, and for a name like "James Smith" at a large firm it will match the wrong person.

The reconciliation procedure

Run this as a batch, in order, with the roles and rough timings shown. The whole method is: pull the moves, strip the noise, resolve identity, decide the action, archive the old record, build and link the new one, protect history, then route ownership.

One sequencing note that matters. Some walkthroughs run archive-then-create inside a single button click, which is fine per record. But when a move triggers a merge across duplicates, sequence parent records (accounts) before child records (contacts). Delete or reparent the wrong record first and history can orphan permanently. Back up before you commit, and verify before you commit.

The friction this procedure fights is finding the moves and resolving each person to a durable identity before you touch the CRM. Refolk does that resolution in plain English, returning a stable profile link and verified email per person, so the anchor exists before you decide overwrite versus create-new-and-link. Because Refolk resolves each person to an ID that survives the move, the deduplication step has something reliable to match on rather than the email the move just killed.

Preserving old-account history correctly

The old-account timeline survives a move only if activities are anchored by the Related-To field, and the primary-account roll-up setting is decided on purpose rather than left on by default. This is where a clean-looking reconciliation quietly loses history, so treat it as its own configuration task.

The activity Related-To field (the WhatId, in Salesforce terms) creates an anchor. When it is populated, the activity stays connected to that record regardless of where the contact moves. Separately, there is a setting called "Roll up activities to a contact's primary account." When enabled, activities linked to a contact automatically appear on that contact's current primary account. So the same org can show two behaviours at once: newly logged activity follows the person to the new account, while old activity anchored to the old account stays put.

Three facts govern how you set this.

• Salesforce officially recommends deselecting the roll-up option, because an activity logged against a contact referencing a related account gets counted against the contact's primary account, distorting reports.
• The setting is not retroactive. When you change it, only new activities are affected; existing activities move only if updated in a way that recalculates the roll-up.
• If you turn roll-up off, activities appear only via the Related-To field. If that field is blank, the activity appears on no account at all.

Survivorship: what the merged record should contain

When a move produces a merge, survivorship decides which value wins for each field, applied at the attribute level and never at the whole-record level. Matching tells you which records are duplicates; survivorship tells you what the merged record should contain. This is the step home-grown efforts skip, and it is where they lose the better value.

Do not merge on "most complete." Completeness is not correctness. The most complete record can carry a stale email that overwrites a fresher verified one. Instead, assign the winning value field by field using explicit rules.

The recognized rule types are source priority, most-recent, most-complete, quality-score, conditional, and hybrid chains, all applied per attribute. For a moved contact, "most recent wins" on contact details, "earliest date" on first touch, and "most restrictive" on consent will cover the common cases. Write the rules down so the same move produces the same merged record no matter who runs the batch.

Matching finds the duplicates; survivorship decides what the merged record keeps. Skip the second step and you lose the better value.

Routing the new owner and the follow-up

The move is not finished until the new account's owner holds a dated follow-up task and no tasks orphan on the departed rep. Owner routing plus a follow-up task is a standard handoff pattern: assign the contact owner, create a follow-up task, notify the rep, and update the lifecycle stage, ideally within seconds, because speed to lead is the single biggest predictor of conversion at handoff.

The trap is that reassigning the record owner does not reassign the record's open tasks. When you change the contact owner, associated open tasks need an explicit reassign step, or they stay with the rep who no longer owns the relationship. Build the reassign into the routing workflow, then report on tasks whose owner does not equal the record owner to catch any that slip through.

WHEN a new contact is created via job-change reconciliation
  SET contact owner = owner of the new account
  CREATE follow-up task
    subject: "Job change: re-open relationship with {contact name} at {new account}"
    due date: today + {response-time SLA in days}
    assigned to: new contact owner
  REASSIGN all open tasks on the new contact to the new owner
  UPDATE lifecycle stage to your re-engagement stage
  NOTIFY new owner (email or channel message)
VERIFY no open task remains owned by the previous rep

How this goes wrong: failure modes and false positives

Every failure below produces a record that looks fine and is not. For each, the false positive is what you would see, and the check is how you catch it before it ships.

• Email as the match key. Two different people share a recycled corporate address and get merged into one. Check: require a profile-URL or person-ID match before any merge.
• Overwriting the employer field. The record "looks updated" while old-account attribution has silently vanished. Check: diff campaign membership and opportunity influence before and after the change.
• Assuming the roll-up setting fixed old records. An admin flips the setting and believes history is repaired; it is not, because only new activities are affected. Check: audit a known moved contact's old-account timeline after the change.
• Blank Related-To fields. With roll-up off, activities show only via Related-To; where it is blank, the activity appears on no account. Check: query activities with a null Related-To before flipping the setting.
• Fuzzy-name match on common names. A common name at a large firm matches the wrong person. Check: require a second corroborating field, such as domain or profile URL.
• Whole-record survivorship. The "most complete" record wins and overwrites a fresh verified email with a stale one. Check: enforce attribute-level rules and inspect the email field specifically.
• Tasks not reassigned with the owner. The contact owner changes but open tasks stay with the departed rep. Check: report on tasks whose owner does not equal the record owner.
• Wrong merge order. Deleting or reparenting the child before the parent orphans history permanently. Check: confirm parent-before-child sequencing and back up first.

Who runs this, and why it must be CRM-agnostic

Write the playbook so it does not depend on deep platform-specific knowledge, because most owners do not have it to fall back on. In Refolk's index of professional profiles, there are 1,035 US Revenue Operations Managers, and only 42 of them list Salesforce as a skill: a floor of 4.1 percent, since skill fields are self-reported.

Column source: Refolk's index (skill filter "Salesforce"); share is derived. Skill fields are self-reported, so treat 4.1 percent as a floor.

Team size raises the stakes per record. The UK RevOps pool is roughly one-fifth the US pool, which means smaller teams process the same weekly batch with fewer specialist hands - exactly the condition under which improvised, non-repeatable handling creates duplicates.

Column source: Refolk's index (title "Revenue Operations Manager", country filter); "vs US" is the derived UK/US ratio.

Decay also varies by field, which is why survivorship rules are field-level rather than record-level. The fields that move most are exactly the ones a job change touches.

Column source: publisher ranges per row (not derived).

Before you call the batch done

Run this checklist against every record in the batch, not the batch as a whole. A single overwrite or an orphaned task is enough to break the guarantee this playbook makes.

Keeping the process current

Re-check the mechanism, not a headline number, because the decay and job-change rates you will see quoted drift by source and by year. On a fixed cadence, sample a handful of known moved contacts and audit their old-account timelines to confirm history stayed put; that single audit catches the roll-up, Related-To, and overwrite failures in one pass. Confirm your identity anchor still resolves the same person across two emails, since that is the assumption the whole method rests on. And whenever your routing tool changes, re-test that open tasks reassign with the owner, because that is the failure most likely to reappear silently after a config change.