Which CRM fields should an automation never write?

Which CRM fields should an automation never write?

Three kinds. Fields a human owns as a judgement call, fields that record a real world event, and fields other systems read as truth. Lifecycle stage, deal amount, owner, and anything a salesperson types are judgement fields, and an automation writing over them destroys information nobody can recover.

Almost every CRM I inherit has this problem somewhere. The automation works, the sync runs, and the data slowly stops meaning what it says. Nobody notices until a report looks wrong, and by then the original values are gone.

The fix is not more careful automations. It is deciding, field by field, who owns the value.

Why does a working automation still corrupt data?

Because writing is not the same as knowing. An automation writes what it was told at the moment it ran, using whatever it could see. If a human changed that field five minutes earlier for a reason the automation cannot see, the write is technically correct and factually wrong.

This is why the failures feel mysterious. Nothing errored. No alert fired. A deal amount got replaced by a number from a form, or a lifecycle stage moved backwards because an old contact filled in a newsletter box. The system did exactly what it was built to do.

The underlying rule is simple and widely ignored. Every field should have exactly one owner, and that owner is either a person, one specific automation, or one upstream system. Two writers on one field is a bug that has not happened yet.

Which fields are judgement fields?

Anything that represents a human opinion about the relationship. Deal stage, forecast category, deal amount before it is contractual, owner, priority, and free text notes. These are the fields where the value is the judgement, so overwriting them deletes the only thing that mattered.

Lifecycle stage is the classic casualty. An automation that sets a stage based on a form submission will happily move a customer back to lead, which then breaks every report and segment built on that field. If you must automate stage changes, make them one directional and make the direction explicit.

Deal amount is the expensive one. Any automation that writes a number into a revenue field is writing into your forecast, and a wrong forecast survives in slides long after the record is fixed. My rule is that revenue fields are human owned until a contract exists, and after that they come from the system that issued the contract.

Which fields are safe for an automation to own?

Machine facts. Timestamps, source, campaign, form name, page URL, enrichment fields kept in their own namespace, and computed flags. Anything a machine observed and a human would only ever transcribe is a good candidate for automated ownership.

The trick that saves the most pain is keeping enriched data separate from human data. If the company size that came from an enrichment tool lives in its own field rather than in the field your sales team edits, both can coexist and you can see when they disagree. Merging them to keep the record tidy is how you lose the ability to audit either.

Computed flags are also safe and underused. A boolean recording whether a contact has a work email, or whether an account has more than one active contact, can be recalculated any time. Fields that can be rebuilt from other data are the least dangerous fields in your CRM.

What breaks when two systems write the same field?

You get a loop, a flap, or a silent winner. Two systems syncing one field will either bounce values back and forth, alternate depending on which ran last, or one will consistently win while everyone assumes the other is working. All three are hard to see in a dashboard.

I have spent more time debugging this than any other automation problem. The tell is usually a record whose modified timestamp changes constantly with no human involved. If a contact updates itself every few minutes, you have two writers arguing.

The cure is directional design. For one of the automations I keep in production for Ajust, an Airtable and WhaleSync setup that has carried more than 25,000 delivered cases, the thing that keeps it boring is that every field has a declared direction. For Kismet Health, the same rule applies to a HubSpot flow running through Zapier. Direction first, features second.

Where do dates and timezones quietly go wrong?

At every boundary between systems. A date field without a timezone, a datetime written in the automation platform's timezone rather than the business's, or a date parsed from text will all produce records that are off by hours or a day, and reports that disagree with each other.

The symptom is a report that is nearly right. Monday numbers that belong to Sunday, a deal closing in the wrong month, a renewal date a day early. Because the values look plausible, nobody suspects the pipeline, and people start distrusting the report instead.

My habit is to store machine timestamps in UTC, keep a separate field for any human meaningful date, and never let a text parser guess a format. Check your platform's documentation for how it handles timezones on date fields, because that behaviour differs between tools and it is exactly the kind of detail that changes.

What about picklists, deletions, and merges?

Treat all three as breaking changes. An automation writing a value that is not in a picklist will either fail or create a new option, a deletion can cascade further than you expect, and a merge decides which record's values survive. None of these should happen without a human deciding.

Picklist drift is the small one that accumulates. Every slightly different spelling written by an automation becomes a new segment nobody intended, and a year later your industry field has forty values with four real ones. Validating against the allowed list before writing costs one step and prevents that entirely.

Deletion is the one I will not automate at all. If an automation can delete a record, then a bad input can delete many records, and a restore is rarely as clean as people hope. Marking as inactive is reversible, and reversible is the whole game. If you do automate something destructive, it needs a rollback plan written before it runs.

How do you find the corruption you already have?

Look for records that change without a person, fields whose values are impossible, and disagreements between systems. Three queries usually find it. Records modified most often, records whose stage moved backwards, and counts that differ between your CRM and the source system.

I also read a random sample by hand, because aggregate checks miss the weird ones. Twenty records read properly will show you the pattern that no report surfaces, and it takes twenty minutes. This is the same instinct as reading actual sales calls rather than only dashboards.

Once you find a corrupted field, resist the urge to bulk fix it first. Turn off whichever writer should not own it, confirm the values stop changing, then repair. Repairing while the cause is still live means doing it twice, and the same principle covers stopping an automation from sending bad data into a CRM in the first place.

What does a good field ownership map look like?

A single page listing every field that matters, its owner, its direction, and whether it can be rebuilt. It takes an afternoon for most CRMs and it prevents the category of problem that costs weeks. If a field is not on the list, no automation should write it.

I keep this next to the automation documentation rather than inside it, because the map outlives any individual automation. When a new integration arrives, the first question is which fields it wants to write, and the map answers immediately whether that is allowed.

The map also makes handover possible. A client who has the list can evaluate a new tool without me, and an automation whose ownership rules are written down is one a successor can maintain. Even something helpful like turning sales calls into CRM notes with AI needs a declared home for its output rather than a free text field a person also edits.

What should you do next?

List the ten fields your reports depend on and write down who owns each one. Then check whether any automation writes to them. Every conflict you find is a future incident you can cancel this afternoon by removing one writer.

If you have inherited a CRM full of automations nobody documented, untangling that is work I do regularly, and the ownership map is usually the first deliverable. Reach out if you want help working out which writer to switch off first.