AGIVIXZoho Systems, Rescued & Rebuilt

Services · Second practice

The same details, typed twice.
A CRM and an ERP that disagree on the numbers.

Connecting Zoho CRM to Priority ERP in B2B companies operating in Israel — when the handover between the two systems is manual, partial, or there was an integration and it broke.

When this is the right path for you

When you run both Zoho CRM and Priority, and the two systems manage the same customers without knowing about each other. A salesperson closes a quote in the CRM, and someone in operations retypes the same details as an order in the ERP. Prices, quantities and payment terms fall between the two keystrokes.

Sometimes the connection exists — it just broke two months ago, and nobody noticed until a customer called.

Signs the connection isn't working

  • Quotes are retyped as ordersThe same details get entered twice, by hand, and somewhere along the way a line comes out wrong.
  • The same customer exists twiceThe customer is created in the CRM before they exist in the ERP, then created again. Two records, and nobody knows which one is right.
  • Sales can't see inventoryStock lives only in Priority, so delivery dates get promised on guesswork.
  • Collection status never reaches salesThe salesperson doesn't know their customer owes money, and keeps pushing a new deal.
  • The sync fails silentlySomeone adds a mandatory field on one side. The sync keeps running, fails, and a queue of records that never made it piles up.
  • The reports don't reconcileRevenue in the CRM and revenue in the ERP show two different numbers, and each side defends its own.
The four failure points in a Zoho to Priority syncFour failure points are marked along the line between Zoho CRM and Priority ERP: a customer number created on both sides, a new mandatory field added on one side, a partial failure where an order transfers without its line items, and a log nobody reads.The four places it breaksZoho CRMPriority ERP1Customer numbercreated on both sides2New mandatory fieldadded on one side3Partial failure:order without lines4A log nobodyever reads
None of the four is a bug. Each one comes from a decision that was never made up front — who creates, who updates, and what happens when something fails midway.

What gets synced

Before touching code you have to decide who owns each field. That's a business decision, not a technical one, and it brings down more integrations than any technical problem. If both systems may update the same value, at some point they will do it simultaneously with different values — and one of them wins arbitrarily.

Field ownership between Zoho CRM and PriorityThe CRM owns the lead, opportunity and quote, which flow from it to the ERP. The ERP owns the customer number, inventory, invoicing and collection, which flow from it to the CRM. Customer address is shown as a field with no defined owner, written by both systems in both directions.Who owns each fieldZoho CRMPriority ERPLead & opportunityQuoteCustomer numberInventoryInvoice & collectionCustomer address
One direction per field. The CRM owns what happens before the deal, the ERP what happens after it. The last row is what happens when nobody decides: both systems write the same field, and eventually one of them wins arbitrarily.

Customers

One customer record, matched across both systems through a stable identifier so duplicates can't form. The customer number is created on one side only and stored on the other as an external ID.

Quotes → orders

An approved quote in the CRM opens as an order in Priority with no further typing — line items, prices, discounts and payment terms included.

Inventory

Stock levels and product availability flow from the ERP to the CRM, so whoever is selling can see what actually exists before committing to a date.

Invoices

Invoices issued from Priority are visible on the customer record in the CRM, including the link to the Israel Tax Authority allocation-number process.

Collection status

Outstanding balance and debt ageing come back to the CRM, so sales know what they're walking into before a call or a renewal.

Clear ownership of every field

Every field gets one direction and one owner, documented and enforced in code. If a specific field genuinely has to be bidirectional, that's a separate decision with an explicit tie-breaking rule.

How it works

1. Diagnose the existing connection — or map it, if there isn't one

If an integration already exists: what it actually transfers, where it fails, and what no longer matches today's data structure. If there's no connection: mapping the fields in both systems and the business process that runs between them. This stage ends in a written document saying what exists and what's missing.

2. Design the sync direction

An ownership table: for every field, who owns it, which way it flows, and what happens on conflict. This is the stage that decides whether the integration survives the next change, and it's agreed with you before a line of code is written.

3. Build in a sandbox

Development doesn't touch production. This includes handling partial failures — an order that transferred while its line items didn't is the worst case, because the system looks fine and only the data is wrong.

4. Go live

Rollout happens in versions rather than all at once, with a way back. A sync failure creates a task or an alert that reaches a person — not a log line nobody reads.

5. Support

An integration isn't a project that ends. The data structure on both sides will keep changing, and someone has to adjust the sync when it does.

Before rebuilding

If you have an integration that breaks now and then, the first assumption shouldn't be that it needs throwing away. In most cases I've seen the problem is a missing ownership decision rather than bad code, and it can be fixed without rebuilding everything.

If what's actually broken is Zoho itself rather than the connection, the rescue path is the right starting point.

Common questions

We already have an integration that breaks now and then. Does it need rebuilding?

Usually not. I start by diagnosing the existing connection, and it typically turns out the problem is an undecided field ownership or unhandled partial failure — not code worth throwing away.

Who should own the customer number, the CRM or the ERP?

In most companies I work with the ERP owns the customer number and the CRM stores it as an external identifier. It isn't a universal rule — what matters is that the decision gets made, documented and enforced in code, so both sides don't create the same customer twice.

Do we need a two-way integration?

Usually not for every field. One direction per field dramatically reduces the number of edge cases. If a specific field genuinely has to be bidirectional, that's a separate decision with an explicit tie-breaking rule.

Do you work on the production Priority environment?

No. Development happens in a sandbox, including runs against real data, and rolls to production in versions once the sync behaviour is approved.

What happens when the sync fails?

Failure has to be loud. Every failure creates a task or an alert that reaches a person, not just a log line. The rule I work by: if a failure can only be discovered by a customer calling, the integration isn't finished.

What is the connection built with?

On the Priority side: its REST API, webhooks or load interfaces. On the Zoho side: the Zoho CRM API and Deluge functions. Which combination depends on how fast each piece of data needs to move and in which direction.

Zoho and Priority not talking to each other?

Tell me what moves between the systems today and what gets typed by hand, and I'll come back with a preliminary read and what I'd look at first.

Talk to meWhatsApp +972-52-680-0325