Zoho CRM
Connect Zoho CRM once and your customers’ contact details keep themselves current on the Zoho contact record — from the fields each of them chose to share with you. One-way, live, and with nothing to configure by hand in the ordinary case.
Setting it up
- Open the allus portal — Configuration → Integrations.
- Step 1 — your allus account. Click Connect next to Zoho CRM. Nothing to paste: this creates the service your customers connect to (alerts go to your allus account's own email), its data client and its webhook, and publishes the standard request set (first name, last name, email, phone, address). You can add more request fields in your portal at any time; they appear in Zoho as their own properties.
- Step 2 — Zoho. Authorize the app. Zoho signs you in and sends you to your own data centre —
.com,.eu,.inand the rest are separate; the app follows whichever one your account lives in, and you do not pick it. - That is the whole setup. There is no admin procedure and no field wizard for Zoho. Within a few minutes the app maps your request fields onto Zoho properties and brings in the customers who were already connected.
One consequence worth knowing: customers who connected before this rule existed, and anyone who declined that field on an older consent, keep their connection. Their contact is simply not created in Zoho until they share a last name; the moment they do, it appears with everything else they had already shared.
What lands where on a Zoho contact
| What you asked for | Where it lands in Zoho |
|---|---|
| First name | First_Name |
| Last name | Last_Name |
Email | |
| Phone | Phone |
| Address | the mailing address block — street, city, state, ZIP and country |
| Anything else you request | a custom property created for you, labelled <your field’s label> (allme:<slug>) — the suffix is how the app tells its own fields from yours, so one of your existing fields is never written into by mistake |
Every contact the app creates also carries an allme_id property holding that customer’s allme share code. That is the durable link between the two records — leave it alone, and you can always tell which Zoho contact belongs to which allme customer. It is created for you, labelled allme ID (allme:allme_id) and marked unique, and it is matched on that label or on its allme_id API name — never on a field of yours that merely reads like it.
- An existing contact is adopted, not duplicated. On first contact the app looks for a Zoho contact by
allme_id, then by email, then by phone. If more than one contact matches, it creates a fresh one rather than guessing — a duplicate you can merge is recoverable; a merge onto the wrong person is not. - Edits arrive within seconds of the customer making them.
- Withdrawing a field empties the property and leaves a note on the contact naming the field and the date the customer withdrew it — with one exception: last name stays on the contact, because Zoho will not hold a contact without one. The note says so in that case, so the record still tells you the customer stopped sharing it.
- Country values arrive as country names, in the language you connected in — not as two-letter codes.
- Ending the connection leaves a note. The contact itself is never deleted or blanked — it is your record.
- Document and photo fields never sync. Their bytes do not enter Zoho at all.
Documents and contract flows on the timeline
When you send a customer a document, or run a contract flow with them, the contact’s Zoho notes show what happened — automatically, with no setup.
- A document shown, updated, or removed leaves a note naming it and the date.
- Signing, accepting, or cancelling a document leaves its own note — a signature note also names how it was confirmed (biometric, 2FA, email, or a custodian for a minor).
- A completed contract flow leaves a note naming the flow and the date it finished. Interim steps of a flow do not appear — only the finished run.
Zoho has no separate activity object the app needs, so all of this rides the same notes a field withdrawal or a disconnect already writes to.
Two limits worth knowing
- Zoho caps custom fields per module, by plan. The app creates one custom property per non-standard request field, plus
allme_id. If your plan’s ceiling is reached, that mapping shows on the connection’s sync-health card as a missing field: raise the plan, or create the property in Zoho by hand with the API nameallme_<slug>— the slug is the one shown beside the field on your service’s request list, andallme_idfor the join key itself. The app picks it up on its next pass, and everything else keeps syncing meanwhile. - A note can appear twice, rarely. Delivery is at-least-once, and Zoho notes carry no key the app can address, so a note is matched against the contact’s most recent 200 notes before another is written. A replay arriving after that many later notes writes a second copy.
If sync stops
The connection’s status page carries a sync-health card naming the customer and what to do. “The CRM refused our access” means the authorization was revoked or expired — reconnect Zoho from that page, and every change that was waiting is applied. Nothing is lost while a connection is broken: changes queue until it is repaired.
Next
CRM integrations overview · How the connection model works · Portal guides