---
title: "Updating CRM with AI: fields and rollback"
description: "Which CRM fields a model may fill, what approval looks like within the system itself, and what rollback means in practice after a wrong update."
source_name: "Gen8"
source_url: "https://gen8.app/en/kennis/crm-bijwerken-met-ai/"
site_home: "https://gen8.app/"
source_description: "Managed AI service for SMEs. We set up, connect and manage; you stay in control."
locale: "en"
authors:
  - name: "Tijs Berens"
    url: "https://gen8.app/en/kennis/author/tijs-berens/"
copyright: "© 2026 Gen8 VOF · Dutch Chamber of Commerce 92978789 · Delft"
published_at: "2026-08-26T00:00:00.000Z"
modified_at: "2026-10-21T20:08:26.696Z"
---

# Updating CRM with AI: fields and rollback

“May AI write to our CRM?” is the wrong question because the answer differs by field. Divide fields into three categories and the control level and rollback follow naturally.

By Tijs Berens · August 26, 2026 · Sales

## Classify the fields, not the system

A CRM contains fields with very different consequences. Lumping them together leads to the wrong answer whichever way you choose: automating everything pollutes management information; doing everything manually saves no time.

### Category 1 — Facts with a source

A contact moment that demonstrably occurred, a received document, a changed phone number from an email signature. The value is verifiable and its origin identifiable. Automatic updates are possible here, provided the source stays visible in the timeline and every step is logged.

### Category 2 — Interpretations

Stage, qualification, probability, expected amount, priority, sentiment. These are judgments, and precisely the fields used to steer decisions: forecasts rely on them. Human approval belongs here, even if the model is usually right — because silent errors are costly here and take a long time to notice.

### Category 3 — Fields with consequences outside the CRM

A field that starts an email campaign, triggers an invoice, sets a contract end date or moves a client to another service tier. Here the update is an action, not a record. Treat it as an action: approval, explicit confirmation and a log stating which follow-on action it triggered.

## What approval looks like when it works

Three properties distinguish approval that happens from approval that piles up:

- **The difference is visible.** Old value, new value and reason on one line.
- **It is where work already happens.** In the CRM, inbox or chat channel — not a separate screen someone must remember.
- **Rejecting is as easy as approving**, and a rejection goes into the same log. A workflow where rejection takes effort does not measure its own quality.

## Rollback is more than an undo button

Rollback works only if you have arranged three things beforehand. First, **identifiable origin**: every workflow change is marked as such so you can find it among manual changes. Second, the **previous value**, stored with the change itself — many CRM fields keep no history, making "reversing" guesswork rather than a possibility. Third, a **batch route**: if something went systematically wrong, you want to restore a hundred records at once rather than individually.

Category 3 has an additional condition: restoring the field does not undo the follow-on action. A campaign email already sent does not come back. That is why approval never disappears for this category.

## Two cases where it is better to write nothing

If several sources write to the CRM — an import script, form, marketing tool and soon a workflow — without showing who wrote what, the first task is making origin visible. Otherwise every error requires investigation.

And if nobody owns the field definitions, you automate filling fields whose meaning differs across teams. That consistently fills an inconsistent concept, which is worse than an empty field.

## What to do with this

Export your field list and add three columns: category, control level and whether the previous value is retained. Fields where that third column remains empty are those you should not update automatically for now.

## Frequently asked questions

Our salespeople want the CRM to update itself. Is that possible?

Certainly for category 1: those fields take time and require no judgment. Fields keeping the CRM useful for decisions are better left as proposals — usually a small share of the typing.

How do you prevent an approval backlog?

Put approval where work already happens and limit proposals to one per event. A backlog usually signals that the workflow proposes too much, not that the team is too slow.

Does this also work for a CRM with many custom fields?

Yes, but classification then takes longer than the technology. Especially with many custom fields, asking which ones are actually used is often the most valuable result of the exercise.

## Want to apply this to your own process?

Bring one process to a conversation. We assess suitability, risk and the cost of the first step.

[Book an introduction](<https://gen8.app/en/contact/>)

- Reply within one business day
- No obligation