Push Updates Back

Outcome: repaired values written to the CRM through a staged, reviewed diff, with human-entered fields untouched and a rollback path that exists before the first write.

Surface: Sync GTM app
Level: Intermediate
Uses: CRM integration · export
Credits: 0
Prerequisite: Lessons 03–05

Stage the diff, always

Never write directly from an enrichment column. Produce a diff first, review it, then write.


record_id
field
current_value      what the CRM has
proposed_value     what enrichment found
change_type        fill | update | no-change
source             enriched | inferred | verified
confidence         high | low

Then sort by change_type and read. fill rows are usually safe. update rows — where something already existed — are where the risk lives, and they deserve individual attention on the first run.

The diff is also the artifact you show whoever owns the CRM. “Here are the 340 changes I propose, grouped by field, with sources” is a very different conversation from “I ran an enrichment on your database”.

The never-overwrite list

Some fields are off limits to automation, permanently.

Field type	Why
Owner, account team	Assignment is a business decision
Stage, amount, close date	Deal data, human-maintained
Notes, descriptions, custom text	Human-written, and unrecoverable
Manual disqualification flags	Someone decided this deliberately
Anything a rep edited in the last 30 days	Recent human input beats automation

That last row is the one to implement carefully. Where your CRM exposes a last-modified-by field, use it: if a human touched the field recently, skip it.

Fill versus update

Fill — the field was empty

Safe. Write it. This is most of your first run and where most of the value is.

Update — the field had a value

Only where you can justify it: the existing value failed validation, the enrichment is verified and the existing one is not, or the record is stale past your threshold.

Never update on a tie

If the enrichment says something different but not demonstrably better, leave the CRM alone. Difference is not evidence of error.

Batch, and have a rollback

Write 20 records first

Open them in the CRM. Read every changed field.

Then 200

Check a sample, and check nothing unexpected changed alongside.

Then the rest

In batches, not one call.

Keep the before-values

Export the current state before writing. That export is your rollback, and it costs nothing to produce.

Most CRMs have no bulk undo. A write that overwrites 5,000 titles with a badly-mapped field is reversed only from a backup you took beforehand — or not at all. Export the current values of every field you intend to touch before the first batch, and keep it until you are confident.

Confirm the write

The write reporting success is not the same as the write being correct.

Row count written matches row count in the diff
Spot-check 20 records in the CRM UI, field by field
Check that fields you did not intend to touch are unchanged
Check that a record with a recent human edit was skipped

Do this now

Build the diff table

Six columns, one row per proposed change.

Export current values as a rollback

Before anything.

Apply the never-overwrite list

As a filter on the diff.

Review every `update` row on the first run

Fills can be reviewed in bulk; updates cannot.

Write 20, check in the CRM UI

Write 200, sample-check

Write the remainder in batches

Confirm counts and spot-check 20

Check your work

A diff was reviewed before any write
A rollback export exists
Never-overwrite fields are excluded by filter
Recent human edits were skipped
You spot-checked records in the CRM after writing, not just the export report

Where this breaks

Overwriting a field a rep corrected by hand is the mistake that ends the project. It only has to happen once for the CRM owner to withdraw write access, and they will be right to. Build the never-overwrite list before the first write, include the recent-human-edit rule, and treat any request to relax it as a decision that needs the CRM owner’s agreement.

Further automation

Once the diff-then-write loop is trusted, it can run with review only on update rows and automatic application of fill rows. That is a meaningful reduction in effort and it is safe — but only after several runs have shown the diff to be reliable.

Next lesson

07 — Hygiene and job changes, turning leavers into leads.

Reference for this lesson: CRM integrations, HubSpot, Salesforce, Export.