Answer
Should AI have write access to your CRM?
To specific fields, yes, with validation and an audit trail. To the record generally, no; nobody could review what changed.
To named fields with validation and an audit trail, yes. To records generally, no. The difference is whether anyone can see what changed and undo it, which general update permission does not provide.
The question is usually posed as trust and is better posed as reviewability. General update permission produces changes that are indistinguishable from human edits, spread across records, discovered by their consequences. Field-level permission produces changes you can list, validate and reverse. The same system doing the same work is safe in one arrangement and not in the other, which tells you the arrangement rather than the system is the variable.
Three conditions make a field safe to grant. It has a defined set of permitted values or a checkable format, so a wrong value is often rejected before it lands. It is not a field that drives an irreversible action — a status that triggers an invoice, a flag that starts a sequence, an owner change that reassigns work. And a change to it can be attributed and reverted, which requires the system to record who changed what and when.
Attribution is the condition most often missing and the easiest to fix. If automated changes are indistinguishable from human ones in the history, then every subsequent question about a record is unanswerable: nobody can tell which entries were extracted, which were typed, or how a wrong value arrived. Marking the source of a change costs a field and it is what makes everything else on this page possible.
The fields that should stay manual are those that encode a commitment or a judgement. The agreed price. The promised date. The stage that signals the business has decided something. The note recording what a customer said. These are assertions about what the business and its customer have agreed, and a plausible reconstruction of one is not the same object even when it is accurate, because a later reader will treat it as a record of the conversation.
The middle path that works for most businesses is a proposal queue rather than direct writing. The system prepares the changes, a person releases them, and the release is a single action for a batch rather than a decision per field. This keeps almost all of the time saving, keeps a human in the path for anything unusual, and produces a natural audit trail without designing one.
Grant a field, not a record, because a field can be checked and a record can only be trusted.
Siddharth Sharma, Context Theory
Related questions
Does a separate integration user solve this?
It provides the attribution, which is a necessary part and not the whole. A dedicated account makes automated changes visible in the history and does nothing about whether a given field should be written at all or whether a wrong value can be reversed. Use it as the foundation and still decide the fields.
What about creating new records rather than updating them?
Creation is generally safer than update, because nothing is overwritten and a wrongly created record can be removed. The exception is duplication: a system that creates a record for an existing customer produces two histories, and the damage from a split customer history exceeds most field-level errors. Matching before creating is the control.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Constraint | General update permission produces changes indistinguishable from human edits and discovered by their consequences, while field-level permission produces changes that can be listed, validated and reversed, which makes the arrangement rather than the system the variable. | Attempting to list every automated change made to records in the last week under the current permission arrangement. |
| Software | A field is safe to grant when it has permitted values or a checkable format, does not trigger an irreversible action, and supports attributed reversible change, and the three conditions are independent. | Checking each candidate field against the three conditions before granting access to it. |
| Workflow | Without source attribution on changes, every later question about how a value arrived is unanswerable, which makes marking the origin of a change the prerequisite for any other control. | Selecting a record field and attempting to determine whether its current value was entered by a person or a system. |
| Response | A proposal queue released in batches preserves most of the time saving while keeping a person in the path and producing an audit trail as a by-product rather than as a designed feature. | Timing batch release of prepared changes against per-field approval on the same volume. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one