The short version

Your CRM's lead source field can only hold one value at a time. Every time a lead fills out a second form, clicks a new ad, or gets touched by a workflow, that field quietly gets overwritten, and the channel that actually created the deal disappears. The fix isn't a better tracking script. It's splitting one shared property into three properties with different write rules: a first-touch source that locks once it's set, a latest-touch source that's allowed to keep changing, and a converting source that's written once, at the moment the lead qualifies.


What's really happening when your lead source "changes"

Most forms, native ad integrations, and marketing automation tools are built to update a contact record on every submission. Lead source isn't treated as a historical record, it's treated as a "last known value" field, the same way a job title or phone number gets refreshed whenever new information comes in. That logic is fine for a phone number. It's a problem for lead source, because the entire point of that field is to remember something that happened once, at the start of the relationship, not whatever happened most recently.

Say a contact discovers you through a LinkedIn ad and downloads a guide. Lead source gets set to LinkedIn Ads. Four months later, that same person clicks a retargeting ad and fills out a demo request. If nothing is guarding that property, the second form overwrites LinkedIn Ads with Paid Search or Retargeting, and the record now says the deal started with the ad that only ever closed it. The channel that actually generated the pipeline gets zero credit.

Why this quietly wrecks your reporting

The overwrite problem doesn't show up as an error. Nothing breaks, no one gets an alert, and the report still runs. It just runs on the wrong number. Retargeting and remarketing campaigns end up looking like they generate demand, when they're actually capturing it a second time. Meanwhile the content, organic, and first-touch paid channels that did the early work show flat or declining ROI, and marketing ends up defending a budget cut for the channel that was actually working.

It also turns into a credit fight that has no winner. Sales points at the field on the record and says the deal came from the retargeting ad. Marketing points at the original campaign notes and says it started with a webinar. Neither side is lying, they're just reading two different values that happened to sit in the same field at two different points in time. That's the same root cause behind why leads quietly pile up under one label in your CRM, which we cover in why your leads show up as "Direct".

How to stop your lead source from being overwritten

None of this requires new tracking. It requires new rules for who's allowed to write to what.

  1. Split lead source into three properties. Give each one exactly one job: First Source (the channel that introduced the contact), Latest Source (whatever touched them most recently), and Converting Source (the channel active when they actually qualified).
  2. Lock First Source with a write-once rule. Add a workflow step that only writes to First Source when the property is empty. Once it's set, nothing else touches it, not a new form, not a new ad click, not a rep editing the record by hand.
  3. Let Latest Source update freely. This is your multi-touch trail. Every new form submission or campaign touch should overwrite Latest Source, since tracking every touch, not just the first, is the point of this property.
  4. Set Converting Source at the qualifying moment, not before. Write to it once, when the lead becomes an MQL, books a demo, or hits whatever event your funnel counts as conversion, then freeze it the same way you froze First Source.
  5. Give every writer a defined lane. Forms, native ad integrations, and reverse-ETL feeds should each know exactly one property they're allowed to write to. If two systems can write to the same property, one will eventually overwrite the other without anyone noticing.
  6. Audit what's already broken. Pull a sample of existing contacts and check whether First Source was already overwritten before you put the write-once rule in place. Flag those records so historical reports don't treat them as reliable.

One shared field vs. three separate properties

The difference isn't more data. It's who's allowed to overwrite what, and when.

AspectOne shared lead source fieldThree-property model
What happens on the 2nd form fillGets overwritten, original source lost for goodOnly Latest Source updates, First Source stays locked
Who can write to itAny form, integration, or rep, in any orderEach property has exactly one defined writer
What sales sees on a closed dealWhichever channel touched the lead lastFirst touch, every touch, and the converting touch, side by side
Reporting riskRetargeting and last-touch channels look artificially strongEach report pulls the property built to answer its question
Setup effortNone, it's the default behaviorOne workflow per property, set up once

Your lead-source-overwrite checklist

Before you trust the lead source field on another report, run through this.

  • ☐ First Source, Latest Source, and Converting Source are three separate CRM properties, not one shared field.
  • ☐ First Source is guarded by a workflow that only writes when the property is blank.
  • ☐ Latest Source is allowed to update on every touch, so you keep a multi-touch trail instead of erasing it.
  • ☐ Converting Source is set once, at the qualifying event, and frozen after.
  • ☐ Every form, ad integration, and automation knows which single property it's allowed to write to.
  • ☐ You've spot-checked existing contacts for records where First Source was already overwritten before the fix went in.

Where to start

If you're not sure whether this is already happening in your CRM, start with the leads sitting under a source you don't fully trust. A large chunk showing up as one channel is often the same root cause covered in why your leads show up as "Direct": one property, too many writers, no rule for who wins. And if you've already added a "How did you hear about us?" field to catch what tracking misses, read self-reported attribution, done right to make sure that answer isn't falling into the same overwrite trap.

Before you touch a single workflow, run the free attribution audit to see which of your forms and lead sources are already unreliable, then fix the write rules before you trust another report.

Lead Source Overwrite FAQ

Why does my CRM's lead source field keep changing?

Most forms and native integrations update contact records on every submission, and they treat lead source as a last known value rather than a historical record. When a returning lead fills out a new form or clicks a new ad, that submission overwrites whatever source was there before, silently erasing the original channel.

What's the difference between First Source, Latest Source, and Converting Source?

First Source is the channel that introduced the contact, set once and never changed. Latest Source updates with every new touch, giving you a multi-touch trail. Converting Source is set at the moment the lead actually qualifies, then frozen. Splitting one field into these three stops any single form submission from erasing history the others rely on.

Can I fix this without a workflow tool?

Only partially. You can stop some overwrites by disabling cookie-based repeat tracking on certain forms, but that also blocks legitimate multi-touch data you'd otherwise want. The reliable fix is a workflow, or equivalent automation, that checks whether First Source is already populated before writing to it, which requires a CRM tier that supports contact-based automation.

How do I know if this has already happened to my existing contacts?

Pull a sample of closed-won deals and compare the recorded lead source against what you know anecdotally about how they found you. If deals you know started with content or organic search show up under a paid retargeting channel instead, the overwrite has already happened, and it's worth auditing before you trust the report.