Cookbook

Undo what an agent got wrong

Letting an agent write to your CRM is only reasonable if you can take a change back. Here is how, and the two cases where undo is the wrong tool.

The situation

An agent updated a record and got it wrong. Maybe it misread a page, maybe your instruction was ambiguous. You noticed an hour later, and you want the previous value back without hunting for what it was.

What must be true when you are done

The field holds what it held before, without you having to remember it.
The undo is itself in the history, rather than pretending nothing happened.
You know which changes cannot be undone this way, before you need one.

Find the change

Ask for the record's own history rather than the workspace feed. Every change carries who made it, when, and which fields moved.

You

Show me everything that has happened to Meridian Freight, most recent first.

Agent

upsert_company industryupsert_company websiteupsert_company domain, domain_normalized, industry, name

The most recent one is the industry edit you are looking at. The oldest is the creation, which matters in a moment.

Undo it

You

That industry change was wrong. Put it back to what it was.

Agent

reverted 1 fieldindustry: Freight forwarding

The previous value came from the change record rather than from your memory, which is the point: undo works even when nobody remembers what it used to say.

The undo is a change too, and it is in the history with your agent's name on it. A CRM where a correction leaves no trace is one where you cannot answer "has anyone touched this", which is the question that actually gets asked.

The two things it will refuse

Both refusals are worth knowing before you need them, because the answer in each case is a different tool rather than a workaround.

You

Actually undo the whole thing, get rid of the company.

Agent

refused: this change cannot be safely compensated Creations are undone by archiving, and a merge is undone by unmerge.

A creation is not undone by undo. Reversing a creation would mean deleting the record, and everything attached to it since would go too: the deals, the interactions, the tasks somebody else created. Archiving is the honest version, and it keeps the history.

A merge is not undone by undo either. A merge moved records rather than changing a field, so it has its own reversal.

There is a third case that is quieter. If the field has changed again since, the undo is refused rather than applied, because putting back a value from two edits ago would discard whatever happened in between without saying so.

Verify it

Read the record. The field holds the earlier value.
Read the history. Three entries where there were two: the original, the mistake, and the correction. Nothing was erased.

Run it again

Whenever you notice. There is no window on it, and the older the change the more useful it is that the previous value is in the record rather than in somebody's head.