A HubSpot contact is an employment, not a person

When someone in your CRM changes jobs, do not update their contact record. Create a new contact for the new employment and keep the old record as the historical truth for the prior company. That one rule - a contact is an employment, not a person - protects your activity history, your attribution, and your email deliverability at the same time.

What breaks when you treat a contact as a person

Overwriting a contact's company and email on a job change quietly corrupts three things at once. I explain this to HubSpot admins, RevOps experts, and HubSpot solution partners weekly, because the damage looks like normal CRM life until you try to report on it.

• Activity history is mixed across companies. The calls, meetings, and deals from the old employer now hang off a contact who "belongs" to the new one. Ask "what happened with Company A last year" and the record says: nothing, the person works at Company B.
• Lifecycle and attribution turn into fiction. The contact arrives at the new employer already marked "customer" or half-way down a lifecycle they never entered there. First-touch attribution points at a company they no longer work for.
• The email address becomes questionable. The old work address starts bouncing, and the consent you collected was for that employment, not the person forever. Keep mailing the merged record and you get bounces at best, a ghost of consent at worst.

None of this is a data-entry mistake. It is the data model itself: one record cannot honestly describe two employments.

The employment model: one contact per job

The fix is to stop pretending the contact record is the person. The rule we run for our clients has two halves:

1. Create a new contact record for each new employment, associated with the new company.
2. Keep the old record untouched as the historical truth for the prior company.

The two records stay linked through a contact-to-contact association, so the human being is still one click away. On both records we set custom properties that make the state machine explicit - an Employment Status ("Working There" or "No Longer With Company") and a note recording why it changed. Any rep, any report, and any AI agent reading the record can now tell a current employment from a historical one without folklore.

What the model keeps intact

The payoff is that every consumer of the data gets an honest answer to its own question.

• Company reporting: activity stays attached to the company where it happened. The Company A record keeps its meetings and deals even after every champion has left.
• New-employer truth: lifecycle stage, ICP fit, and attribution start clean at Company B, where they actually apply. A returning champion is one of the strongest buying signals in B2B - but only if your CRM can see it is the same human in a new employment.
• Deliverability and consent: the old address retires with the old record instead of bouncing from a live one, and marketing consent stays scoped to the employment where it was given.

Doesn't this create duplicates?

No - a duplicate is the same employment recorded twice; two employments are two facts. Your dedup logic should merge records that describe the same person at the same company, and it must never merge across employments. That distinction matters more in the AI era, not less: when we cleaned 485,587 HubSpot contacts, the expensive judgment calls were exactly these - which records describe one fact twice, and which describe two facts that merely look alike. An agent working on top of your CRM inherits whatever your model says, so a model that conflates person and employment feeds it fiction.

Model the change, don't overwrite it

People change jobs all the time; your CRM should record that instead of erasing it. If your reports have unexplained gaps at exactly the accounts where contacts moved on, the model - not the team - is what needs fixing. We implement this employment model, including the associations, properties, and the migration of historical records, as part of our HubSpot data work: book 30 minutes and bring your ugliest job-change example.

FAQ

Should I create a new HubSpot contact when someone changes companies?

Yes. Create a new contact associated with the new company and keep the old record as history for the prior employer. Link the two with a contact-to-contact association so the person remains traceable across employments.

What happens to the old contact record?

Nothing - that is the point. It keeps its activity history, lifecycle stage, and attribution as the permanent record of what happened at that company, and its Employment Status is set to "No Longer With Company" so no automation treats it as live.

Won't two records for one person break deduplication?

No. A duplicate is the same employment recorded twice. Two employments are two legitimate records, and your dedup rules should be scoped to merge only within one employment - same person, same company.

Does this work in HubSpot without custom development?

Yes. It uses native features: contact-to-contact associations plus a small set of custom properties for employment status. The work is in defining the rules and migrating existing records, not in code.