CRM lead source keeps getting overwritten? Fix the field model

The problem in plain English

A new lead enters the CRM with the correct source. Later, the source changes or becomes blank. The website and form did their job—the correct value reached the CRM—but another tool replaced it.

The change may come from an automated workflow, spreadsheet import, integration, contact merge, or a second form submission.

The solution in plain English

Protect the fields that store the original source. Give later visits and reporting labels their own fields. Then decide exactly which tools are allowed to change each field.

This prevents a sales workflow or import from erasing the marketing source that brought the lead to you.

Prove that an overwrite happened

Start with one contact whose value changed. Open the field history and check workflow, integration, and import logs. Answer these questions:

1. What value arrived at record creation?
2. Which actor changed it?
3. When did the change occur?
4. Was the actor a user, workflow, integration, import, merge, or API client?
5. Did the rule apply only to existing records?

If the contact never had the correct source, this is not an overwrite problem. Start with why CRM lead-source data goes missing. Use this guide only when the correct value existed and changed later.

Why one lead-source field fails

One lead-source field is often used for several different answers:

• original acquisition source;
• most recent campaign;
• conversion source;
• SDR-entered source;
• record creation method;
• reporting channel;
• partner or event influence.

Each tool uses “lead source” to mean something different. Whichever tool updates the field last replaces the earlier value.

Split the data into three simple groups

1. Original source fields

These fields keep the original values your website observed:

• first_utm_source, first_utm_medium, first_utm_campaign;
• original landing page and referrer;
• supported click IDs;
• first capture timestamp;
• source at form submission and the submission page.

Allow as few tools as possible to change these fields. A first-source field should normally be filled only when it is empty. If someone corrects it manually, record who changed it and why.

2. Reporting fields

Fields such as acquisition_channel can group original values into labels such as “Paid social” or “Organic search.” You can change these grouping rules later because the original source fields remain untouched.

3. Sales and operations fields

Keep the record-creation method, partner name, salesperson, event name, or import name in separate fields. Do not reuse the original source field for sales notes or routing.

Assign field ownership

For every source field, write down what it means, which tools may change it, and when they may change it.

Property	Meaning	Allowed writers	Update rule
first_utm_source	First observed campaign source	Capture integration	Set only when empty
converting_utm_source	Source associated with submission	Form integration	Update per qualified submission
acquisition_channel	Simple reporting group	Reporting workflow	Rebuild from original values
record_creation_method	How CRM record was created	CRM/platform	Platform controlled
source_override_reason	Approved manual correction	Operations admins	Required with correction

Document the null behavior too. A workflow should not replace a known value with blank merely because its input is empty.

Audit the common overwrite paths

Workflows

Search for every automation that writes to source fields. Check reenrollment, default branches, “clear property” actions, and rules that run whenever a form is submitted.

Imports

An import can change existing contacts, not only add new ones. Check how rows match contacts, what blank cells do, and whether a broad “source” column points to a protected original-source field.

Enrichment and routing tools

Some tools add a source label for routing or sales work. Send that label to its own field instead of the first-source field.

Repeat form submissions

An existing contact may submit a new form with no UTMs. If blank incoming fields are allowed to overwrite known values, history disappears. Configure the connector or workflow to ignore blank updates for protected fields.

Record merges

Check which contact’s value wins when records are merged. A newer contact with less source information can sometimes replace an older contact that had complete data.

Manual edits

Restrict permissions where possible and provide an explicit correction workflow. A manual correction should capture who changed the value and why.

A safe correction process

1. Export affected record IDs, current values, and property history.
2. Identify a reliable source of truth for the correction.
3. Stop or fix the writer that caused the overwrite.
4. Restore original values only when logs or history prove what they were.
5. Rebuild reporting fields from the restored values.
6. Validate a sample of new and existing records.
7. Monitor change history for recurrence.

Do not guess missing UTMs from a broad label such as “Paid social.” If you cannot prove the original value, use unknown and record why it is missing.

Stop the problem from coming back

Test source fields whenever you change forms, integrations, workflows, imports, or the CRM. Create a new contact, let the normal workflows run, and submit the form again without UTMs. Confirm that the original source stays unchanged.

You can also count how often protected fields change after they are first set. Group the changes by the workflow, integration, import, or person responsible. This shows which process needs attention.

Keep CRM-built fields and your custom fields separate

Your CRM may have built-in fields for traffic source and record creation. Those fields follow the CRM’s own rules. Do not put your custom UTM values into them only because the names look similar. In HubSpot, for example, Original and Latest Traffic Source differ from Record Source.

Keep the CRM’s built-in fields and your custom source fields separate. Choose the correct field when building each report instead of replacing one with the other.

Where TraceSig fits

TraceSig can help source details reach supported forms and CRMs. It cannot stop an unrelated CRM workflow from changing those fields later. Your team still needs to control which tools may update each CRM field.

If you first need to check whether the form sends the source, follow the form-source implementation guide. For a review of your form and CRM path, book a demo.

Frequently asked questions

Should lead source ever be editable?

Reporting and sales fields may need controlled edits. Original first-source fields should have stricter permissions and a clear correction process.

What should happen when a repeat form has blank UTMs?

Blank incoming values should not erase known first-touch evidence. The repeat submission can still update its own converting-touch fields.

Can I use property history to restore overwritten data?

Often, yes. Check whether the CRM kept the old value in its field history. Export that history before changing workflows or restoring data.

Is “Original source” the same as record creation source?

Not necessarily. A source field may describe how the person reached your website, while a record-creation field describes whether a form, import, or integration created the contact.

How do I stop integrations from competing?

Give every field one clear meaning. List the tools that may change it, and send other updates to a different field.