Short answer: when a contact changes jobs, do not overwrite the record and do not quietly create a second one. Treat the person as a durable identity and the job as a time-bounded relationship. Close out the old account link with an end date, open a new link at the new account, set the new work email as primary while keeping the old address on the same person, and store a lineage field your reports can group by. Overwriting destroys the account history that made the lead warm. Duplicating destroys your ability to prove the lead was warm at all.
Most teams never decide this. A rep notices a bounce, edits the company name in place, and six months later nobody can explain why a closed-won account has no buyer attached to it.
This post is the decision, written as a data model.
What should you do with the CRM record when a contact changes jobs?
There are three things teams do by default. All three lose information.
Overwrite in place. The rep edits company, title and email on the existing contact. The record now describes a person at the new employer while still hanging off the old account, so the old account’s closed-won deal points at a buyer who, according to your CRM, works somewhere else. Reparent the record to fix that and the old account loses its buyer entirely. Either way the history is gone, and the history is the entire reason this lead is worth more than a cold one.
Create a new contact and leave the old one. Now you have two records for one human and no link between them. The old record still looks active, so sequences keep firing at a dead mailbox. The new record looks like a net-new prospect, which means the warmest lead in your database enters your funnel disguised as a stranger.
Delete the old record. This is the worst option and the most tempting during a data-hygiene project. You are deleting the proof of the relationship.
The correct shape is different from all three. A person is durable. A job is an edge between that person and a company, with a start date and an end date. Model it that way and a job change stops being a destructive update and becomes what it actually is: closing one edge and opening another.
Why does overwriting the record cost you so much?
Three specific losses, in order of how much they hurt.
You lose the warmth. Champion-sourced deals close with 2.7x higher probability than cold pipeline, in roughly half the sales cycle. That premium comes from one fact: the person already bought from you, so the trust is pre-built. Your CRM record is where that fact lives. Erase the prior account and prior deal from the contact and you have converted a 2.7x lead into an ordinary one, because the rep who picks it up has no idea what they are holding.
You lose attribution. If a moved champion enters your pipeline as a generic new contact, champion-sourced revenue is unreportable. You cannot forecast a channel you cannot count, and you cannot defend the budget for a signal whose output is invisible. The six metrics worth reporting on this channel are in champion-sourced pipeline metrics, and every one of them depends on a lineage field surviving the move.
You lose suppression. This one has legal teeth, and we will come back to it when we get to HubSpot, because the default behaviour there is the opposite of what you want.
Should you create a new contact or update the old one?
Keep one person. Add a relationship. The mechanics differ by CRM, so here are the two that matter most.
Salesforce: use Contacts to Multiple Accounts
Salesforce has a purpose-built answer and most teams have it switched off. Contacts to Multiple Accounts lets you “relate a single contact to multiple accounts so you can easily track the relationships between people and businesses without creating duplicate records” (Salesforce Help, Contacts to Multiple Accounts).
The hierarchy is worth understanding before you wire anything. “Each contact still requires a primary account (the account in the Account Name field). The contact and its primary account have a direct relationship. But you can add other accounts to the contact. These secondary account-contact relationships are indirect.” Under the hood, each pair is an AccountContactRelation record, and the Direct field is read-only, derived from Account Name on the contact.
So the move becomes four edits on one person, not a new record:
- Repoint Account Name on the contact to the new account. That makes the new employer the direct relationship.
- The old account stays attached as an indirect relationship instead of disappearing.
- On the old relationship, uncheck Active and set End Date. Those fields exist to keep a history of the relationship rather than overwrite it (Account Contact Relationship Fields). Set Start Date on the new one.
- Keep the Roles picklist current on each relationship, because “Decision Maker at the old account, Evaluator at the new one” is exactly the context the rep needs in the first thirty seconds.
Two honest caveats before you commit to this, because vendor write-ups tend to skip them. First, reporting: “Indirect contacts aren’t available in reports run from an Account & Contact standard report type,” so if your champion-sourced reporting depends on indirect relationships you will need a custom report type on AccountContactRelation. Second, the exit is lossy: “Disabling Contacts to Multiple Accounts deletes all indirect account-contact relationships,” and “when you remove indirect relationships, they’re deleted and can’t be restored from the Recycle Bin” (Considerations for Relating a Contact to Multiple Accounts). Decide once, then leave it on.
If you want the alerting layer that sits on top of this, the field and Flow build is in how to build a job change alert in Salesforce.
HubSpot: one contact, multiple email addresses
HubSpot’s constraint is different, and it forces your hand in a useful direction. Email is the deduplication key: “When a new contact is added, HubSpot will look for a matching value in the Email property,” and if you try to create a contact manually with an address that already exists, “HubSpot will alert you that a contact already exists, and you won’t be able to add the additional contact” (Deduplicate records in HubSpot).
That means you cannot solve a job change by spawning a parallel record keyed on the new address without creating exactly the duplicate you were trying to avoid. The supported path is to keep one contact and give it more than one address. Set the new work email as the primary and retain the old one as a secondary: “Once added, HubSpot will de-duplicate a contact against the multiple addresses,” while “marketing emails will always be sent to the contact’s primary email address” (Add multiple email addresses to a contact). One person, one record, correct send behaviour, old address preserved as history. Then associate the contact with both companies and mark the new one primary.
Now the gotcha, and it is the suppression problem from earlier. HubSpot is explicit: “Email bounces and unsubscribes are associated with an email address, not a contact. If a contact’s primary email address hard bounces, it will be ineligible to receive emails in the future, but the other email addresses associated with the contact will remain eligible to receive emails.”
Read that in the context of a job change. A person who unsubscribed at their old company has not consented to anything by acquiring a new mailbox, but address-level suppression does not follow them. Your system will cheerfully email someone who already told you to stop, and no human will have made that decision. Suppress at person level and make sure the flag survives the move. The legal reason this is not optional, including why the right to object has no balancing step, is in is job change tracking GDPR compliant.
The workflow side of HubSpot is covered in how to build a job change alert in HubSpot.
What fields do you actually need on the record?
Whatever your CRM, the move is only useful if these survive it. Six fields, and they are all cheap:
- Previous company and previous title. The credential that makes the first line of the email land.
- Previous email. Keeps the old thread history searchable and tells you what already bounced.
- Move detected date. Your clock. Mandate and budget concentrate in a new leader’s first 90 days, so age on this field is the only prioritisation input that matters.
- Prior relationship owner. The rep who actually earned the trust, which is rarely the rep the new account’s territory would assign.
- Prior account and prior closed-won value. This is the attribution key. Without it, champion-sourced revenue is a story rather than a report.
If you only add one, add move detected date. If you add two, add prior relationship owner.
How do you stop your dedupe rules from fighting you?
This is the failure that quietly undoes everything above, and it is structural rather than a configuration mistake.
Most dedupe and matching logic keys on email, or on name plus company. A job change changes the email and the company at the same time. So on exactly the event you most want to catch, every identifier your matching rules depend on moves at once. Match on email and the person reads as a brand-new human. Match on name plus company and they read as a different human too. Your dedupe layer is blind precisely when it matters.
You need a person-level key that does not depend on current employment: a provider-side person identifier, or your own stable key that survives both an email change and a company change. Then your rules dedupe humans instead of mailboxes. The same principle applies to your merge rules: merging on email will happily fuse two different people who inherited the same address pattern at the same company, and will refuse to fuse one person who moved.
Who should own the record after the move?
Route the new relationship to the rep who held the old one, then let territory rules apply afterwards if you must.
Standard assignment logic routes by account territory, which hands your warmest lead to someone with no history with the buyer. The whole asset is the existing relationship, so the routing rule should preserve it. That is what the prior relationship owner field is for, and it is the single most common reason a correctly detected move still produces a cold-sounding email.
What does the old account need?
Do not stop at the new opportunity. The seat your champion just vacated is a renewal risk, and the record change is your earliest warning that the person who defended your line item is gone. Close the old relationship with an end date, flag the account for a CS review, and get a new internal sponsor identified before the renewal conversation starts. The full play is in champion departure as a churn signal, and what Customer Success owns in it is on the use cases page.
One detected move should create two work items: an opportunity at the new account and a defence at the old one.
How do you do this at volume?
Everything above is tractable for one contact and impossible for a database.
Every month, 2 to 3% of B2B contacts change jobs, and only about 6% of them tell the vendor they used to buy from, so 94% of these moves hit your CRM as silence. On a 10,000-contact CRM, roughly 20% surface as hot leads on day one, about 2,000 relationships that have already moved and are currently modelled wrong, then 200 to 300 new warm leads every month after that. That is the volume your record-hygiene process has to absorb. Nobody is hand-editing AccountContactRelation records 250 times a month, which is why the data model only works if detection and write-back are automated. The reframe is worth sitting with: the contacts your data-hygiene project is about to delete as stale are the same contacts that are currently warm, which is the argument in CRM data decay.
Champions detects the move, writes the new company, title and verified email back to the record, preserves the prior relationship, and routes the alert to the owner who held it, across Salesforce, HubSpot, Pipedrive, Zoho and others. There is no app to install and no logins for reps. The platform page covers the monitoring loop, how it works covers the sequence, and the API page has the event fields and delivery modes if you would rather consume the signal as a feed and apply your own record logic in a warehouse or a lead router. For how detection approaches differ across the category, the job change tracking comparison puts the tools side by side.
Quick answers
- Should I overwrite a contact when they change jobs? No. Overwriting erases the prior account and deal history that made the lead warm.
- Should I create a second contact record? Only if it is linked to the first. An unlinked duplicate turns your warmest lead into an apparent stranger.
- Should I delete the old contact? Never. You would be deleting the proof of the relationship.
- What about the old email address? Keep it on the same person as a secondary address. It preserves thread history and tells you what already bounced.
- Does an unsubscribe follow someone to their new job? Not by default. Suppression is usually keyed to the address, not the person. Fix this deliberately.
- What is the one field I should add? Move detected date. Prioritisation is about age, because budget and mandate peak in the first 90 days.
- Who should the new lead go to? The rep who owned the prior relationship, not whoever owns the new territory.
Where to start
Pick the single ugliest record in your CRM: a closed-won account whose buyer left. Model it correctly by hand, person durable and employment time-bounded, and look at what you can suddenly report that you could not report before. That one record is the business case for doing it everywhere.
Then fix the input. The data model is the easy half; knowing the move happened at all is the hard half, and it is the half you cannot solve with field configuration. Only 6% of contacts will tell you.
We back the signal contractually. If champion-sourced revenue does not reach 2x your annual service fee, you are covered under our terms. Among the tools compared on the job change tracking landscape, only Champions offers that.
Want to see how many records in your CRM are currently wrong, and who those people became? Book a demo and we will run detection against your database so you can watch the moves surface against your own accounts. If you would rather start in writing, email [email protected] and we will walk you through the field mapping first.
Your records are already out of date. The only question is whether the next update throws the history away.
