How We Check AI-Drafted CRM Updates Before They Ship

Each change our extraction proposes carries the line from the call that justifies it and a confidence score. The reviewer sees "Stage: Discovery to Evaluation" next to the customer saying "we're going to run a technical eval with two of our engineers", not a bare field value.

This is the cheapest check we have and the one that does the most work. A change with no quote is a change nobody can verify without replaying the call, so in practice nobody verifies it. With the quote beside it, a wrong stage takes about two seconds to spot: the sentence does not say what the field says.

We keep the few lines of conversation around each quote so the context is there when a reviewer needs it. We do not keep the transcript itself.

The most damaging CRM error is not a wrong value. It is a right value on the wrong record. Tuesday's call notes on the renewal that was not discussed, or the new phone number on a different Sam.

When a name from the call matches more than one contact at the account, the draft does not pick. It asks: More than one "Sam" at Acme. Whose record changes? The options are the matching records with their email addresses, and that item cannot run until a person answers, even if it would otherwise have qualified to run on its own. Guessing here is how a tool earns a reputation for corrupting data, and one question costs the reviewer a click. We wrote up the wider matching problem, including multiple open opportunities on one account, in CRM updates after sales calls.

By default every drafted change waits in the Review Console, where the account owner approves, edits or rejects it item by item. Approving today's batch does not approve tomorrow's. Anything that reaches the customer, a follow-up email or an invite, waits for a person every time, because there is no taking it back.

A team can let some internal changes run on their own, but only when all of these hold at once: that kind of change has built up a track record on this team above a threshold the admin set, the extraction confidence is at least 0.95, the change is rated low risk, an admin has switched auto-run on for that specific type, and the account is not on the list of accounts that always get a human. If any input is missing, a score that was never recorded or a setting that failed to load, the answer is no. Trust earned is not trust granted until someone grants it.

Before an approved stage or field change is written, a preflight reads the object's metadata from the CRM and checks the write against it. Two things fail here.

Required fields. Salesforce treats a field as required when it cannot be blank, has no default and can be edited. If moving the stage means a required field must be filled and the record does not have it, the change goes back to the reviewer naming the missing field, rather than failing halfway inside Salesforce with an error nobody reads. If the record already has a value in that field, the change goes through.

Fields that do not exist. Models are good at inventing plausible custom fields, a Custom_Renewal_Date__c that sounds right and lives in no org. Writes are checked against the fields we have read from that customer's CRM, and a field we cannot write to stops the change. One honest gap: the field-name check uses a saved copy of the schema, and if that copy is more than a week old it lets the write through rather than block a working integration. The preflight's own metadata read still runs.

The rule underneath this check matters more than the check. When the preflight cannot read the metadata or the record, because of a timeout or a permissions change, the write does not go ahead on the assumption that nothing changed. It stops and goes back for re-approval. Could not check is not the same as nothing to check, and we keep them as different outcomes in the code so they cannot be confused.

This is the check most tools skip, because the failure it prevents is silent. A rep approves "Stage: Evaluation" at 10:00. At 10:20 a colleague moves the deal to Negotiation. At 10:30 the approved write lands and quietly puts it back. The API call succeeds, a read-back shows exactly what was written, and every status says done.

So when a reviewer approves, we save the current value of each field the change will overwrite. Just before writing, we read those fields again. If they still match, the write goes ahead. If someone has changed one, the write stops and the reviewer sees what moved, approved value against current value, and decides again. If the record cannot be read, that is a stop too.

Today this runs on Salesforce. The HubSpot version of the staleness check is not built yet, so on HubSpot the preflight and the read-back apply but this check does not.

Admins can write rules that apply to every change: block any email to a given domain, block any text that mentions pricing or discounts, require a specific phrase. They are plain pattern matches, deliberately. A false positive costs a reviewer a second look. A false negative sends a discount to a customer.

The rules run on human-approved changes too, not only on the ones that run automatically. If the policy says no pricing in outbound email, an approval click does not override it. A new rule can run in dry-run mode first, where it records what it would have blocked without blocking anything, so an admin can see the effect before switching it on.

After a stage or field write, we read the record back from the CRM and compare it to what we meant to write. If they differ, because a validation rule, a trigger or a flow on the customer's side rewrote the value, the change is marked not persisted, with the expected and actual values, instead of done. The reviewer sees "Checked: Stage reads Evaluation" only when the read-back confirmed it.

The gap here is the CRM being unreachable at read-back time. Then the change stays marked as done, without that Checked line. We would rather show an unconfirmed success as unconfirmed than block on a read that may never come back.

CRM field and stage changes can be reversed afterwards, back to the value saved at approval, and notes and internal tickets can be closed. Emails, invites and Slack posts cannot be taken back, which is exactly why they never run without a person. Every step, what was proposed, who approved it, what changed and what the read-back said, goes into the audit trail.

A change can carry a real quote, land on the right record, fit the schema, pass every rule, read back perfectly and still be wrong. The customer said "we're going to run a technical eval" to be polite and has no intention of doing it. No check on the write can see that. Only the person who was on the call can.

That is why the approval step is the centre of the system rather than a formality, and why it has to be fast enough to actually read. If a reviewer faces fifty items a day with no evidence attached, they will approve all fifty, and the gate becomes decoration. The checks above exist partly to make the human step cheap: by the time an item reaches a person, the mechanical questions are answered, and the only question left is the one only they can judge. More on where that line sits in human in the loop vs on the loop.

If you are evaluating a tool that drafts or writes CRM updates, ours or anyone's, these questions get past the demo.

Does every proposed change show the sentence it came from? What does it do when two records match, pick one or ask? What happens when it cannot read the record or the schema: does it write anyway? Does it check whether the record changed between approval and write? Does it read the record back afterwards and tell you when the write did not stick? And which changes can be undone, and from where?

A tool that answers "the model is very accurate" to any of these has answered a different question.

These checks are built into ASTRA, the system we run for customer-facing teams: a call becomes a drafted batch of CRM updates, tickets and follow-up emails, each with its source sentence, each passing the checks above before anything is written, and each logged with who approved it. We build your first post-call workflow free: you pick the call type, the fields it may touch and the approval rule, and we ship it. Start at mindlyft.io/start.