Connecting Zoho to Your Existing Business Systems: An Integration Architecture Guide
The Integration Architecture Decision: Single Source of Truth
Before building any integration, the most important decision is which system is authoritative for each type of data. When the same data exists in two systems — a customer record in Zoho CRM and in the accounting software — which system’s version is correct when they differ?
Common authority assignments for Zoho implementations:
Document the authority assignment before building integrations. When a conflict resolution question arises during integration design — “what happens if the contact email is different in both systems?” — the answer is determined by which system is authoritative, not by a developer’s judgment call.
| Data Type | Authoritative System | Rationale |
|---|---|---|
| Contact and account information | Zoho CRM | Sales team maintains it; most current |
| Invoice and payment status | Zoho Books / accounting | Finance team maintains it |
| Product catalogue and pricing | ERP or Zoho Books | Finance/operations owns this data |
| Stock levels and inventory | ERP or custom inventory app | Warehouse operations owns this |
| Project delivery status | Zoho Projects / PM tool | Delivery team owns this |
| Payroll and HR data | Zoho People / HR system | HR owns this |
Integration Patterns
One-Way Push (Simplest)
Data flows in one direction only. When a deal closes in Zoho CRM, an invoice is created in the accounting system. The accounting system never writes back to Zoho. Simple to implement, easy to troubleshoot, no conflict resolution required. Appropriate when one system produces the event and another system consumes it without feedback.
One-Way Sync (Scheduled)
A scheduled process reads data from the authoritative system on a regular schedule and updates the non-authoritative system. Every 15 minutes, a script reads all updated product records from the ERP and updates the product catalogue in Zoho CRM. Users in Zoho see ERP pricing data without the ERP needing to connect to Zoho. Slightly more complex than a one-way push — requires tracking which records have changed since the last sync run.
Bi-Directional Sync (Most Complex)
Both systems can update shared data. A customer’s delivery address can be updated in Zoho CRM by a sales rep or in the ERP by the warehouse team. The sync must handle the case where both systems update the same record between sync runs — by using the most recent timestamp, by using a defined authority rule or by flagging the conflict for manual resolution.
Bi-directional syncs require careful conflict resolution logic and are the most complex and fragile integration type. ABR only recommends bi-directional sync for data where the use case genuinely requires both systems to be authoritative — which is less common than clients initially assume. Most apparent bi-directional requirements can be solved by clarifying which system is authoritative and implementing a one-way sync from the authoritative system to the consumer.
The Integration Stack ABR Uses
ABR implements Zoho integrations using the appropriate method for each data flow: Zoho Flow for simple, connector-available connections; Deluge custom functions for logic-heavy CRM-side operations; and a lightweight middleware service (typically a Python service deployed to AWS Lambda or Google Cloud Run) for bi-directional syncs, webhook receivers and bulk data operations using the Zoho REST API.
The middleware service handles: receiving webhooks from external systems, transforming data between schemas, resolving conflicts using the defined authority rules, queuing failed operations for retry and providing an operations dashboard showing integration health and last successful sync times.
What to Expect From an Integration Engagement
- Discovery session — document every system in the stack, define the authority assignment for each data type, map the data flows and identify any conflict scenarios.
- Integration design document — written specification of every data flow, the trigger for each, the field mapping between systems and the error handling approach.
- Build and sandbox testing — all integrations are built and tested against sandbox environments for both systems before any production data is touched.
- Parallel run — the integration runs alongside the manual process for two to four weeks. Discrepancies are identified and resolved before the manual process is retired.
- Monitoring and documentation — every ABR integration includes an operations dashboard and documented runbook for investigating and resolving common integration issues.
Frequently Asked Questions
What business systems does ABR commonly integrate with Zoho?
What information does ABR need to scope a system integration project?
How does ABR handle data conflicts in bidirectional integrations?
Can ABR integrate Zoho with a system that has no public API?
Can ABR integrate our existing business systems with Zoho?