Writing a Rollback Plan for an Automation That Writes to Your CRM

What do you do when an automation writes bad data into your CRM?

You need to have decided that beforehand, because the answer depends on what you recorded while it was running. Without a record of what each write changed and what the value was before, a rollback becomes a manual investigation across thousands of records, and most teams simply give up and live with it.

This is the part of automation work nobody enjoys and everybody eventually needs. I build it into anything that writes to a system of record, because the cost of getting this wrong is not technical downtime. It is a sales team that stops trusting its own data.

Here is the plan I write before the automation goes anywhere near live records.

Why is a rollback plan different from a backup?

A backup restores everything to a point in time. A rollback undoes one specific set of changes while leaving everything else alone. In a live CRM the first option is almost never usable, because restoring wholesale would also discard every legitimate change made by humans in the meantime.

That distinction gets missed constantly. Someone asks whether the CRM is backed up, hears yes, and assumes they are covered. They are covered against catastrophe and completely exposed to the far more likely scenario, which is one automation quietly writing wrong values into one field across a few thousand records.

So the unit of a rollback is the change, not the database. Your plan needs to name which changes it can reverse and how it will find them.

What can you actually undo, and what can you not?

Deletions are usually recoverable and overwrites usually are not. HubSpot's developer documentation describes deleting contacts individually or in batches as adding the contact to the recycling bin, and says you can later restore the contact within HubSpot. That is a real safety net for one kind of mistake.

The documentation for updating contacts describes no equivalent restore path for a property value you have overwritten. I would not claim it is impossible, and I would plan as though it is, because designing around a recovery mechanism you have not personally confirmed is how incidents become permanent.

That asymmetry should shape your design. An automation that deletes has an escape hatch provided by the platform. An automation that updates a field is making a change whose previous value exists only if you kept it.

So the rule I follow is simple. Never let an automation overwrite a field whose previous value you have not recorded somewhere you control.

What should every write record so a rollback is possible?

Five things per change: the record identifier, the field name, the value before, the value after, and the timestamp of the write. That is one row per field per record, and unglamorous as it looks, it is the entire basis of any rollback you will ever be able to perform.

Store it outside the system you are writing to. A log inside the CRM is subject to the same mistakes as the data, and a log inside the automation platform disappears when a run is cleaned up. A separate table in Airtable or a database of your own is fine, and it is worth the extra step.

Add a run identifier to every row as well. Incidents are almost always scoped to a run or a range of runs, and having that identifier turns the question of what to undo from an investigation into a filter.

Record identifiers matter more than you expect. HubSpot's contact records carry an object identifier alongside created and updated timestamps, and using the platform's own identifier rather than an email address protects you when somebody changes an email address between your write and your rollback.

How do you find the damage after the fact?

Filter your own log by run identifier and time window first, then confirm against the live system before you touch anything. Never work from the automation's record alone, because the thing you are recovering from may be that the automation did not do what it logged.

Check the updated timestamps in the CRM too. A record whose update time sits inside your incident window and whose current value matches your bad write is almost certainly yours. One whose update time is later has been touched by a person since, and that record needs a different decision.

Count the affected records before you decide anything. The difference between two hundred and twenty thousand changes the right approach completely, and people consistently guess this wrong in the first ten minutes of an incident.

What does the rollback itself look like?

A second automation that reads your change log and writes the previous values back, run against a small sample before anything else. Treat that second automation with exactly the same caution as the one that caused the problem, because it is just as capable of making things worse and it runs under far more pressure.

Run it on ten records, check them by hand, then run the rest. Every instinct during an incident pushes towards speed, and every serious second failure I have seen came from skipping that check because somebody was in a hurry.

Exclude the records that humans have touched since. Those need a person to decide, and quietly overwriting a colleague's correction while fixing your own mistake is the fastest way to lose the trust you are trying to rebuild.

Pace it as well. CRM APIs have rate limits like any other, and a rollback is by definition a burst of writes. The handling for that is the same as for any bulk job, which I covered in handling rate limits and retries.

How do you avoid making the rollback worse than the incident?

Stop the source first, before anything else. Disable the automation that caused the problem before you begin the rollback, because rolling back while the original job is still running produces a fight between two processes and leaves you with a data set that matches neither one of them.

Then decide what good looks like before you write anything. Write down the correct value for three specific records and confirm your rollback produces exactly that. A rollback without a defined expected outcome is just another uncontrolled write.

And log the rollback itself with the same five fields. Incidents have second rounds more often than anyone admits, and arriving at one without a record of what you already changed is the worst possible starting position.

What should you build before the next automation goes live?

Three things: the change log, the kill switch, and a written owner for the automation. Those take an afternoon between them, and together they convert an incident from an emergency into a task with a known shape. Everything else in a rollback plan follows from having them in place.

The kill switch matters most and is the most often missing. There should be one obvious place to stop an automation that anyone on the team can reach without asking you. An automation only one person can stop is a risk concentrated in that person's availability.

Test the whole thing before it matters, on data that nobody cares about. Break it deliberately, roll it back, and time how long that took. That rehearsal is the difference between a plan and a document. My rules for that pre launch testing are in testing automations before real customer data.

What should you do next?

Pick the automation of yours that writes to the most important system you own, and check whether you could answer one question today: what did it change in the last week, and what were the previous values? If you cannot, that is the gap, and it is cheaper to close now than during an incident.

Prevention still matters more than recovery, and the two are not alternatives. The validation that keeps bad data out is covered in stopping an automation from sending bad data to your CRM. This plan is for the day that fails.

If you are about to point an automation at a live CRM and you want a second pair of eyes on the rollback path, describe the writes it makes and I will tell you where I would put the log.