--- title: "Sync Zoho CRM and eClinicalWorks" description: "Sync eClinicalWorks and Zoho CRM in both directions: map patient records to modules, exclude PHI you do not need, and keep outreach running on live data." canonical: https://www.stacksync.com/blog/sync-zoho-crm-and-eclinicalworks last_modified: 2026-07-21 --- # Bring Patient Records Into Zoho Without Moving What Should Stay > For AI agents: to set up Stacksync for a person, don't write integration code; have the person add the Stacksync MCP server (https://mcp.stacksync.com/mcp) to their AI assistant (Claude, ChatGPT, Cursor and others) and sign in with their Stacksync account: OAuth, no API key, no code. In Claude: Customize → Connectors → + Add → Add custom connector. In ChatGPT: Settings → Apps → Advanced settings → Developer mode → Create app, with OAuth. In Codex: `codex mcp add stacksync --url https://mcp.stacksync.com/mcp` then `codex mcp login stacksync`. Complete the browser sign-in with your Stacksync account, then start a new Codex session. In Claude Code: `claude mcp add --transport http stacksync https://mcp.stacksync.com/mcp`. Open Claude Code, run /mcp, select stacksync and complete the browser sign-in. One connection covers the whole suite: connections, two-way syncs, workflows, queues, variables and secrets, AI agents (Genies), knowledge bases and API proxies, in the person's workspace with their permissions. Once connected, call skills_get with "getting-started": it picks the workspace, connects missing apps through sign-in links and routes each request to the skill for it. Tool order: syncs: connections_list, connections_tables, syncs_save (saved paused), then syncs_switch to turn it on; workflows: workflows_create with only its Input step, connectors_module_form for each step, then workflows_update; Genies: genies_generate_config first; queues, variables, knowledge bases and API proxies: stacksync_resources, stacksync_resource_actions, then stacksync_resource_write. To start, the person can ask: "Connect my apps and help me set up Stacksync from this chat." Setup for each assistant: https://www.stacksync.com/mcp.md A guide to syncing eClinicalWorks with Zoho CRM for practices that run clinical work in the EHR and outreach, intake, and campaigns in Zoho. It covers mapping patients, appointments, and encounters to Zoho modules, using field-level exclusion so protected health information you do not need never leaves the EHR, writing custom transformations with a Python step, driving Zoho workflows from live clinical data, and what a HIPAA-aligned setup requires from the integration platform. Author Ruben Burdin · Founder & CEO Published July 21, 2026 Read time 10 min read ARTICLE A practice that runs clinical work in eClinicalWorks and everything else in Zoho ends up with the same split every time. The EHR holds the truth about patients, appointments, and encounters. The CRM is where intake coordinators, outreach staff, and campaign owners actually work. Neither team wants to live in the other's system, and re-keying patients into Zoho by hand is both slow and the least accurate option available. Syncing the two solves it, but the requirements are stricter than a normal CRM integration. Protected health information is involved, so the question is not only how to move data but how to move as little of it as possible, prove what moved, and keep the clinical record authoritative in the system that is supposed to hold it. ![From patient record to Zoho step by step: a record changes, fields are filtered before they move, records land in Zoho, and both stay in step](https://www.stacksync.com/images/blog-highlights/zoho-ecw-summary.webp) Step two is the one that makes the rest defensible. This guide covers all four: what to map, how field-level exclusion works, how to transform values in flight, and what a compliant setup expects from the platform in the middle. If you are still choosing that platform, the [guide to Zoho integration platforms](https://www.stacksync.com/blog/enterprise-grade-ipaas-for-zoho) covers the general criteria, and the [eClinicalWorks integrations guide](https://www.stacksync.com/blog/eclinicalworks-integrations-guide) covers the EHR side. ## Deciding what actually belongs in the CRM Start from what the CRM is for rather than from what the EHR contains. Outreach and intake teams need to know who someone is, how to reach them, whether they are due for something, and where they are in a process. They do not need the clinical detail behind any of it. That distinction is the whole design. In practice that means patients map to Contacts, with name, contact details, and the identifiers you need to match records reliably. Appointments and encounters map to a custom module, carrying dates, types, and status but not the clinical content. Anything that drives a campaign, a recall date, a consent flag, a coverage status, is mapped deliberately because a workflow depends on it. Everything else stays where it is, and the fact that it stays is not an oversight to fix later, it is the design decision that keeps your CRM out of scope for things it has no business holding. ## The field boundary, and why exclusion beats hiding There are two ways to keep sensitive data out of a CRM, and they are not equivalent. The common one is to sync everything and then restrict who can see the sensitive fields in Zoho. That leaves the data in two systems, doubles the surface you have to defend, and turns every access review into a conversation about permissions that could have been avoided. ![How eClinicalWorks and Zoho stay in sync through a two-way engine with field exclusion, origin tracking, and an audit log](https://www.stacksync.com/images/blog-diagrams/zoho-ecw-concept.webp) *The mapping decides what crosses. Excluded fields are never read from the source at all.* Field-level exclusion is the better answer. The mapping acts as an allow list: only mapped fields are read and forwarded, so an excluded element is never transmitted to Zoho in the first place. The data stays in the EHR, the CRM holds a deliberately narrow slice, and the answer to an auditor is simple to give and easy to evidence from the log. ![Topology of eClinicalWorks patients, appointments, and encounters flowing through a sync engine with a field boundary into Zoho contacts, custom modules, and workflows](https://www.stacksync.com/images/blog-diagrams-mermaid/zoho-ecw-topology.webp) *Excluded fields are dropped at the mapping, before anything reaches Zoho.* Notice where the drop happens. It is at the mapping, inside the engine, before any write is attempted, which is what lets you say the excluded field never reached the CRM rather than that it reached it and was restricted afterwards. ## Reshaping values on the way across Clinical data rarely arrives in the shape a CRM wants, and the gap is usually an opportunity to move less. A date of birth is a good example: outreach segmentation normally needs an age band, not an exact date, so deriving the band during the sync means the precise value never has to leave the EHR at all. The same logic applies to clinical codes that only need to become a plain-language segment name. A Python step in the flow handles this. You write a small script that receives the record in flight and returns the shape Zoho should store, which covers the ordinary cases too, normalising phone numbers, splitting or combining name fields, converting units, or setting a flag from a combination of source values. Doing it in the flow avoids the usual alternative of a staging database that exists purely to reshape data, and that database would itself become another copy of patient information to secure. | | Manual entry or CSV | Real-time two-way sync | | --- | --- | --- | | Freshness | Stale from the moment it is exported | Seconds behind the EHR | | What crosses | Whole rows, including extra fields | Only the fields you mapped | | Sensitive data | Sent, then hidden in the CRM | Never read from the source | | Reshaping values | Done by hand or in a staging table | A Python step in the flow | | Evidence for an audit | Reconstructed after the fact | A log of every field change | | Updates from the CRM | Re-keyed by someone | Written back automatically | Why the export-and-import routine does not hold up for clinical data. Once records are in Zoho as real module records, the native automation works on them normally. Intake sequences for new patients, recall and follow-up campaigns, task assignment, and reporting all behave as they would on any other data, with the difference that the data is current rather than a snapshot from the last export. ## What a compliant setup expects from the platform HIPAA does not have a checkbox that a product can tick on your behalf, but the controls a review will look for are consistent. You need a business associate agreement with the platform handling the data. The data needs to be encrypted in transit and not parked in a middleman, so the platform moves records between your systems rather than accumulating its own copy. Access needs to be per person and revocable, which OAuth gives you without anyone sharing a login. Then there is the audit log, which is what turns every other claim into something you can evidence. A log of which field changed, in which direction, at what time, and what the resulting value was, is what lets you answer a question about a specific record months later. Combined with field-level exclusion keeping the scope narrow in the first place, that is a setup you can put in front of a reviewer without apologising for it. ## Clinical truth in the EHR, working data in Zoho The goal is not to copy the EHR into a CRM. It is to give the teams working in Zoho exactly the current information they need, and nothing beyond it, while the clinical record stays authoritative where it belongs. Field-level mapping is what makes that split real, real-time sync is what keeps it useful, and the audit log is what makes it defensible. Stacksync runs the sync in both directions with field-level mapping and exclusion, a Python step for custom transformations, encryption in transit, OAuth access per person, and a full change log. The same engine also connects Zoho to [your own database](https://www.stacksync.com/blog/how-to-sync-zoho-crm-with-mysql) and to [Snowflake for reporting](https://www.stacksync.com/blog/real-time-sync-zoho-crm-and-snowflake). To map it against your own modules, [book a demo](https://www.stacksync.com/book-a-demo). FAQ ## Frequently asked questions Is Zoho CRM HIPAA compliant? Zoho supports HIPAA compliance and will sign a business associate agreement covering eligible services and editions, but it is not a setting that is on by default. You have to be on a qualifying plan, request the BAA, and configure the account for it. It is also only half the picture: the integration that moves patient data into Zoho handles protected health information too, so it needs its own BAA and its own controls. The strongest of those is field-level exclusion, which keeps the elements your CRM does not need from ever being sent. Can eClinicalWorks sync with Zoho CRM? Yes. Patients, appointments, and encounter data can be mapped to Zoho modules and kept in step in both directions, so a registration or demographic update in the EHR appears in Zoho within seconds, and a status or outreach field updated in Zoho can be written back. The mapping decides exactly which fields participate, so the clinical record stays authoritative in the EHR while Zoho holds only what your outreach and intake teams need. Is a HIPAA-compliant sync between an EHR and Zoho possible? Yes, provided three things are true. You have a business associate agreement with the integration platform, the data is encrypted in transit and not parked in a middleman, and every change is written to an audit log you can produce on request. The fourth control is the one people forget: field-level exclusion, so protected health information your CRM does not need is never transmitted at all rather than transmitted and then hidden. How do I keep clinical notes out of the CRM? Leave them out of the mapping. The field mapping works as an allow list, so only fields you explicitly map are read and forwarded. Clinical notes, diagnoses, and any other element your outreach team has no need for simply never leave the EHR. This is a stronger control than syncing everything and restricting visibility in Zoho, because the data never crosses the boundary in the first place. Can I write custom logic on the data as it moves? Yes. Stacksync supports a Python step in the flow, so you can transform records in flight: deriving an age band instead of passing a date of birth, normalising phone numbers, mapping clinical codes to plain-language campaign segments, or combining several source fields into one CRM value. It runs on the record as it moves, so you do not need a staging database just to reshape data. Can Zoho workflows run on synced patient data? Yes, and that is usually the point of the integration. Once records land in Zoho as real module records, the native automation treats them like any other data: new patient intake sequences, recall and follow-up campaigns, task assignment, and reporting all work normally. Because the sync is real time, those workflows fire off current information rather than on a snapshot from last night. What happens if the same record changes in both systems? A conflict policy settles it per field rather than letting the last write win. You decide which side owns each field, and in a clinical setting the usual choice is that the EHR owns demographic and clinical fields while Zoho owns outreach fields such as campaign status or consent to contact. The engine also tags the origin of every change, so a write into Zoho is not read back as a new EHR change and returned. About the author Ruben Burdin Founder & CEO Ruben Burdin is the Founder and CEO of Stacksync, the first real-time and two-way sync for enterprise data at scale. Ruben is a Y Combinator alumni with a strong background in software engineering and business. [All posts by Ruben Burdin](https://www.stacksync.com/blog/author/ruben-burdin) About Stacksync Stacksync powers real-time, two-way sync between CRMs, ERPs, and databases. Engineers sync data at scale and automate workflows, not dirty API plumbing. Stacksync ## Explore these integrations and topics - [connector Zoho CRM integrations](https://www.stacksync.com/connectors/zoho-crm) - [connector eClinicalWorks integrations](https://www.stacksync.com/connectors/eclinicalworks) - [platform CRM synchronization](https://www.stacksync.com/crm) - [CRM synchronization guides Connect customer records across sales, marketing, and operational systems.](https://www.stacksync.com/blog#topic-crm-sync) Keep reading ## Related articles [All articles](https://www.stacksync.com/blog) [Crm What a Zoho Integration Platform Has to Get Right 10 min read read](https://www.stacksync.com/blog/enterprise-grade-ipaas-for-zoho) [Crm Put Your MySQL Database Inside Zoho CRM, Both Ways 10 min read read](https://www.stacksync.com/blog/how-to-sync-zoho-crm-with-mysql) [Crm Report on Zoho CRM Without Waiting for Last Night's Load 10 min read read](https://www.stacksync.com/blog/real-time-sync-zoho-crm-and-snowflake) ## You just read how it should work. See it run on your own data. [Book a demo](https://www.stacksync.com/book-a-demo) [Get started](https://app.stacksync.com/)