A CRM piles up contact details an AI does not need
A Zoho CRM that has been running for a few years holds contacts, accounts, deals, and a leads module where imported or bought lists lie dormant. Most of the volume in it is contact details, email addresses, phone numbers, postal addresses.
The questions a director actually wants to put to an AI almost never need those fields. Where a deal stands, which account signed twice this year, what the last exchange said about a project, all of that is answered with names, stages and notes.
The Zoho CRM connector is built on that observation. It names the fields it writes, and contact details are not among them.
What Zoho hands over and what your Kastel keeps
Zoho's interface cannot deliver a trimmed record. It returns the whole thing, contact details included, and no setting on the Zoho side lets you ask for less.
The sorting therefore happens at the moment of writing. The connector projects a list of fields settled per module, a contact with their first name, surname, job title, the account they belong to and the department they sit in at their employer, a deal with its name, stage, amount and closing date. Nothing else is written, and Zoho's full response is never kept.
That mechanism has one property worth naming. When a field arrives in a shape the connector does not expect, an array of values for instance, it writes nothing for that field. The only mistake the connector can make is to write too little. It cannot be to tip a whole structure into a note, carrying along a field nobody had examined.
The four modules read, without an address or a phone number
On a CRM, scope is described field by field. Here is the list the connector writes, module by module.
The leads module is read like the others, and it is where imported or bought lists lie dormant. A lead's name and company come in, its email address and phone number stay in Zoho.
The owner is written on the record itself
Zoho returns each record's owner along with their work address, right there on the record. The connector therefore has no directory to walk through to know who a record belongs to. It resolves that address into a person in your organisation, then files the record in that person's department.
When the record has no owner, when that owner has no address, when the address matches nobody on your side, or when the person found spans several departments, the record is filed in no department and waits for an administrator's decision. Those four cases are more frequent than one imagines in a CRM that has lived, where bulk imports and service accounts leave traces.
A reassignment of accounts catches up on its own, because changing a record's owner counts as a modification of that record. It comes back in the next read window and is filed in the new owner's department. Other tools need one pass more, since their sharing changes without the record moving, as the Pipedrive page shows. The owner principle itself also turns up on the HubSpot page, with limits of its own.
What people ask us before connecting a CRM
Do a contact's email address and phone number come into my Kastel?
No. Those fields are not read, even though Zoho sends them with the record. A plugged-in AI knows a contact's name, their job title and the account they belong to, which is enough to place them in context. To get in touch with them, you open Zoho.
Do my records change region when I connect them?
Zoho serves your organisation from one regional data centre, the one you picked when you opened your account. The connector is pinned to that region's hosts, for reading as well as for renewing its token, and it refuses a host belonging to another region. The security page describes this kind of guardrail.
What happens to a record deleted in Zoho?
It is marked as gone at the source and kept in your Kastel, readable by the same people as before, until an administrator decides to erase it. Zoho's own deletion feed does not reach back indefinitely, so the connector does not rely on it and compares the full inventory against what it already tracks.
Can a plugged-in AI modify a Zoho record?
No. The connector's only calls are reads, plus the renewal of its own access token, which touches no data. No create, update or delete method exists in the code that talks to Zoho, so the question is closed at the level of the connector and not merely at the level of a setting.
What this connector does not do
Zoho can restrict a record by more than its owner, through sharing rules and territories. The connector does not read them, it reads the owner only. A record Zoho was keeping for two named people therefore becomes readable by its owner's whole department, which is more open than your original setting. This is the most important limit on this page, and it deserves a look before you connect.
It reads five modules. A module you created yourself stays out until it has been added to that list, and a module's custom fields are never written, even when the module itself is.
The projection is short, so it deliberately impoverishes your records. A plugged-in AI will not recount the full history of a client relationship, with its campaigns, its tasks and its correspondence. It recounts what your deals and your notes say about it.
A note's content is free text, and it comes in whole. What a salesperson writes there about a counterpart comes in with the rest, including what they would not put in an official field. Disconnecting the connector deletes its key and stops the reading, and the content already filed stays readable by the same people until an administrator decides to erase it.
See what Kastel makes of a CRM once it is filed.
The product page describes what happens after the reading, when your records, your meetings and your documents become knowledge you can question, and what each plugged-in AI gets out of it depending on the person it works for.
See the product
