CRM access should be granted field by field, not record by record. The agent may log contacts, add notes and record preferences the customer states in a verified conversation at depth 3. Changes to email, phone, name or address are held, because they are how someone takes over an account. Merges, deletions, ownership and payment details stay with people.
What does updating a CRM record involve, and who owns it?
A CRM record looks like one thing but holds several kinds of data with different owners. Contact details belong to the customer and are used to reach them and, often, to recover their access. Preferences and consents carry legal weight. Notes and activity are your staff's working memory. Commercial fields, such as account owner or value, belong to sales.
The CRM administrator owns field definitions and permissions. A data protection owner answers for consents and deletion. Name both before you grant anything. The question of whether an agent should touch CRM records at all is covered in can an AI agent update customer records in a CRM. The wider support position is in the AI support agent that knows when to say no.
Which fields should you grant, and at what depth?
| Field or action | Depth | Condition | Stays with a person |
|---|---|---|---|
| Read the record and activity history | 1 | Scoped to the customer in the conversation | Nothing |
| Log a contact and add a note | 3 | Always | Nothing |
| Record contact preferences (channel, times) | 3 | Customer verified in session | Nothing |
| Record marketing consent given or withdrawn | 3 | Customer's own words stored as evidence | Disputes about past consent |
| Change email or mobile number | 2, held | Always held | Person checks and approves |
| Change name or postal address | 2, held | Always held | Person checks evidence |
| Merge duplicate records | 2, held | Always held | CRM administrator |
| Change account owner or commercial fields | None | Refused by your limits | Sales |
| Delete a record | None | Refused by your limits | Data protection owner |
| Store payment details | None | Refused by your limits | Payment systems only |
Contact details are held because they are the takeover route. Someone who changes the email on an account can then reset the password. A held change gives a person the chance to send a confirmation to the old address and wait. Payment details should never sit in a CRM; the separate question is covered in can an AI agent update a customer's payment details.
How do you set it up, step by step?
- Person, CRM administrator: classifies every field as readable, writable at depth 3, held, or refused. Fields not on the list are refused.
- Person: creates the agent's integration user with field-level permissions matching the classification. The connection is set up as described in connecting an AI agent to your CRM.
- Agent, depth 1: confirms whose record it is. The customer must be verified through your own systems before any write. Reading the wrong record and updating it is the most common CRM error.
- Agent, depth 1: reads the current value of the field it intends to change.
- Agent, depth 3 or 2: writes or proposes the change. For depth 3 fields it writes the new value. For held fields it drafts the change with the old value, new value and the customer's words.
- Platform: checks the write against the minimum chain and files a verdict naming the bound that decided.
- Person, support team: works held changes. For a new email, the person sends a confirmation to both addresses before approving.
What stays with a person?
Merges stay with the CRM administrator because they are hard to undo cleanly. Two records become one, histories combine, and if they were two different people, one customer now sees another's notes. Deletions stay with the data protection owner because a deletion request has its own legal process and its own evidence.
Banks should note one more boundary. The CRM is rarely the system of record for identity. A name or address change that matters for regulation belongs in the core banking system, under its own grant and its own checks, described in letting an AI agent update customer records in your core banking system. Updating the CRM alone leaves the two out of step.
What is recorded for each change?
Every write, held change and refused attempt is filed in an append-only record. For CRM updates the useful fields are:
- the record, the field, the old value and the new value;
- the source of the new value and its provenance class, usually declared by the customer;
- the verification status of the customer at the moment of writing;
- the bounds checked and the bound that decided;
- for held changes, the person who approved or rejected, and when.
The CRM's own field history shows that a value changed. The verdict shows who asked for it, on what evidence, and which rule let it through.
How do you revoke the access?
Withdraw a single field grant if one type of update goes wrong; the rest keep working. Disable the integration user to stop everything. Because every change keeps its old value in the record, any individual update can be reversed. A certification run that clears no depth drops the agent to depth 1 the same day: it can still read records to answer questions, but writes nothing.
What should you measure?
- Writes to the wrong record, found by sampling. Should be zero.
- Held contact-detail changes later confirmed as fraud attempts.
- Notes that staff find useful, by a quick rating in the CRM.
- Consent changes without stored customer words. Should be zero.
- Time held changes wait before a person acts.
Where does it usually go wrong?
Free-text notes collect sensitive data. The agent writes down a health condition the customer mentioned in passing. Set rules for what a note may contain, and keep special-category data out unless there is a reason and a basis to hold it.
Duplicate records multiply. The agent cannot find the customer and creates a new record. Creating records should itself be held until matching is reliable.
Bulk updates slip in. A request like "update all my company's contacts" turns one verified conversation into many writes. Limit writes to the verified customer's own record.
Where Pryme fits
In Pryme, each CRM field is a separate capability with its own depth. Notes and preferences can be certified at depth 3 while contact-detail changes stay held for a person, in the same agent. Every write is filed with the old value, the new value and the source class of the new value.
Questions people ask
Can the agent correct a typo in a customer's email address?
It can propose the correction, but it is still an email change and is held. A one-letter difference is exactly what a lookalike takeover address uses.
Should the agent record what the customer said or a summary?
For consents and preferences, store the customer's own words. For general notes a short summary is better, as long as it separates what the customer said from what the agent checked.
Can the agent update records for business customers?
Only for the verified contact's own details, unless that contact has documented authority over the account. Changing other people's details on their behalf is held.