Which CRM fields should an AI automation never write?
Short answer: give every CRM field one of three labels: the automation may write it directly, the automation may only suggest it for a person to approve, or the automation never touches it. Then enforce that list in one place in your workflow, not in the prompt.
A recent thread in r/automation described the problem well: an AI notetaker wrote a kickoff date that a customer had only floated, and someone who was not on the call approved it. The question that followed was simple, which CRM fields would you never let an automation write?
Why AI updates go wrong in a CRM
- The model only sees the one call or email it is processing, so it can contradict what was agreed earlier.
- A "maybe next month" becomes a hard date, because the field only accepts a date.
- Approvers who were not in the conversation cannot tell a guess from a commitment, so they click approve.
- The bad value looks official once it is in the CRM, and other automations start using it.
The three-label write policy
| Label | What it means | Typical fields |
|---|---|---|
| Auto-write | Low risk, easy to verify, easy to undo | Call logged, meeting date that already happened, contact's job title from their own signature, activity notes |
| Suggest only | Useful, but a wrong value changes what people do | Next step, close date, kickoff date, deal stage, product interest, budget mentioned |
| Never | Commitments, money, legal or ownership | Contract value, discount, payment terms, deal owner, closed won or lost, consent and opt-out flags |
Adjust the table to your own CRM, but write it down. The list is the policy; the prompt is not.
How to enforce it in about 30 minutes
- Keep the policy in one place. A Set node in n8n, or a data store in Make, holding each field name and its label.
- Make the AI return proposals, not updates. Ask for JSON with the field, the proposed value, and a short quote from the source that supports it.
- Filter by label before writing. Auto-write fields go straight to the CRM. Suggest-only fields go to a review list (a sheet, a Slack message or a CRM task). Never fields are dropped and logged.
- Require the quote for every suggestion. If the model cannot point to the exact words, the suggestion does not go to review. That alone removes most invented dates.
- Send suggestions to the person who owns the deal, not to whoever is free. The thread above is a good reminder of why.
- Store who approved what. Write the approver and the time into a note on the record, so later questions have an answer.
Quick test
Feed the workflow a call transcript where the customer says "we might start in March, but nothing is confirmed." If the kickoff date field changes in the CRM without a review step, your filter is not wired correctly.
Where Make helps
Make scenarios can route each proposed field through a router with a filter per label, which suits this pattern without code. You can try it on the free plan: Make free plan.
Disclosure: Some links are affiliate links — I may earn a commission at no extra cost to you.
Top comments (0)