The items below describe the known limitations of the Zoho CRM integration. They are inherent to the current design of the integration and to the capabilities of the Zoho CRM API, and they apply to all subscribers at the time this documentation was written.

Deleting a record in one system does not delete or deactivate its counterpart in the other. A Zoho CRM contact deleted in Zoho CRM leaves its iPaaS.com Customer in place; a Customer, Transaction, or Product deleted in iPaaS.com leaves its Zoho CRM record in place. When configuring the Zoho CRM contact webhook, a Contacts.delete event is offered, but the integration does not act on it — leave it unselected.

What this means for you: Treat removals as a manual step in each system. Where a record should no longer exist on both sides, remove it in Zoho CRM and in iPaaS.com separately. If your workflow needs deletions to propagate, submit a feature request through your iPaaS.com partner channel describing the behaviour you need.

The integration transfers records individually — by a scheduled poll, a webhook, an outbound trigger, or a Manual Sync — rather than as a single bulk load. There is no one-click initialization that back-fills an entire history.

What this means for you: For an initial load of an existing Zoho CRM contact base or an iPaaS.com catalog, use the supported bulk sync using Postman approach. For ongoing operation, records flow automatically once the relevant triggers or polling are enabled.

After a record transfers successfully, iPaaS.com saves the counterpart's id on a dedicated external-ID record, and every later transfer of the same record is matched through that link. On the outbound (to Zoho CRM) collections there is no secondary match on the Zoho CRM side — no iPaaS.com identifier is written to a Zoho CRM field to fall back on.

What this means for you: If the external-ID link is cleared, the next outbound transfer creates a second Zoho CRM record rather than re-linking to the existing one. Avoid clearing external-ID links on records that have already synced. On the inbound (into iPaaS.com) contact collection, a fallback match on CustomerNumber does exist, so this risk is specific to the outbound direction.

The inbound contact collection brings a contact's standard fields — name, email, description — into iPaaS.com, but not values held in Zoho CRM contact custom fields.

What this means for you: If you rely on data stored in Zoho CRM custom fields being available in iPaaS.com, note that it is not transferred inbound. Custom fields are supported in the outbound direction (iPaaS.com to Zoho CRM). If your workflow needs specific custom fields brought inbound, submit a feature request through your iPaaS.com partner channel.

A Zoho CRM contact holds a single mailing address, while an iPaaS.com Customer can hold several. On an outbound transfer, the address written to Zoho CRM is taken from the first address stored on the Customer, regardless of whether it is flagged as the billing address.

What this means for you: For a Customer with one address this is always correct. For a Customer with several, make sure the address that should appear in Zoho CRM is stored first, or ask your MiSP to adjust the mapping to select the address explicitly (the Sales Order collection already selects billing and shipping addresses this way and can serve as the pattern). Confirm the result on a staging record before go-live.

Note: In the opposite (inbound) direction the integration captures both of a Zoho CRM contact's address blocks — mailing and other — as separate iPaaS.com address records. The single-address limit applies only to the outbound direction.

Zoho CRM meters API usage against a rolling 24-hour credit allowance and caps how many calls an application may have in flight at once, both varying by Zoho CRM edition. When a limit is reached, Zoho CRM rejects the call and the transfer stops — it is not automatically retried or rescheduled.

What this means for you: A transfer rejected for a limit appears in Dashboard / Integration Monitoring / Error Logs and must be re-run once the allowance window resets. To stay within the limits, set the contact poll interval with the size of your contact base in mind, and stagger bulk work rather than running it in one burst. Order transfers are the most demanding, because each order makes one call per line to match its products. If limits are reached routinely, consider a higher Zoho CRM edition or additional API credits.

Certain Zoho CRM field types are either not returned by Zoho CRM's field list or accept a value without storing it — Image Upload, File Upload, Multi-line (Rich Text), Multiple Users, and Multi-select Lookup fields have all been observed to behave this way.

What this means for you: Avoid mapping to these field types. If a mapping to one of them appears to do nothing, this is the reason. Confirm any field of these types on a staging record before building a mapping that depends on it, and use a supported type (Single Line, Number, Date, Email, Picklist, Multi Select, Lookup) where possible.

The stock quantity written to a Zoho CRM product is the total of the product's inventory across all iPaaS.com locations, captured at the moment of transfer. It does not stay in step with later iPaaS.com inventory movements until the product is transferred again. Where the net figure is negative, zero is written instead.

What this means for you: Zoho CRM stock reflects the last transfer, not live inventory. Re-transfer products (or rely on the outbound trigger) to refresh stock, and expect out-of-stock products carrying a negative net figure to show zero in Zoho CRM. Per-location stock is not represented — Zoho CRM receives the combined total only.

Before an order is written, the integration matches each line's SKU to a Zoho CRM product code. If any one line's SKU has no matching product, the entire order fails — no partial order is created.

What this means for you: Transfer your product catalog to Zoho CRM before transferring orders, and make sure each product's code matches the SKU used on iPaaS.com transaction lines. If an order fails for a missing product, transfer that product and re-run the order.

An order is attached to the Zoho CRM contact its customer was previously linked to. The integration reads that existing link; it does not create the contact as part of the order transfer. An order can still be written if no link is found — it is simply left unattached to any contact.

What this means for you: Transfer customers to Zoho CRM before their orders, so orders attach to the right contact. Orders are not associated with Zoho CRM accounts or deals — only with a contact. Confirm on a staging order that the contact appears as expected before relying on order-to-contact reporting.

The integration does not automatically transfer a record's dependencies ahead of it — it does not, for example, transfer a customer or a product as a prerequisite of an order.

What this means for you: During an initial load, run the transfers in dependency order: products and customers first, then the orders that reference them. Your MiSP can help sequence a large initial load.

The tax written to a Zoho CRM sales order and its lines is summarised into one named tax entry rather than reproducing each individual tax line separately. The named tax must already exist in your Zoho CRM tax settings.

What this means for you: Create the tax name used by the tax mappings in your Zoho CRM tax settings before transferring orders. Expect a single consolidated tax on the Zoho CRM order rather than a line-by-line breakdown of every tax component.

The integration works with the Zoho CRM Contacts, Sales Orders, and Products modules. It does not transfer Zoho CRM accounts or companies, leads, deals, quotes, invoices, purchase orders, or activities; and it does not transfer attachments, notes, product variants, options, kits, or images.

What this means for you: Plan around these three modules. If your workflow needs another Zoho CRM module or record type integrated, submit a feature request through your iPaaS.com partner channel describing the requirement — input like this informs future enhancement releases.

When the inbound contact collection updates an iPaaS.com Customer, iPaaS.com replaces the full record. Any Customer field that is not mapped by the collection is cleared on every update. In the default template mappings, the affected field is:

What this means for you: If you populate the iPaaS.com Customer Company field from another source, it is overwritten on every inbound contact transfer unless it is preserved. The recommended approach is to split the combined Add/Update collection into separate Add and Update collections and use the DestinationValue function in the Update collection to carry the existing value forward (for example, a Dynamic Formula with the source DestinationValue.Company mapped to Company). Your MiSP can set this up. Subscribers running only the outbound direction are not affected.

Several shipped mappings carry example values that were configured for demonstration and are not appropriate for a live subscriber. Review and replace each one before enabling the affected collection. Each is also flagged inline in the mapping notes.

These are example configurations, not defects — they demonstrate each supported pattern and are expected to be tailored during implementation.

This document covers 14 known limitations plus a pre-go-live placeholder checklist. For the detailed behaviour of each mapping collection, see the individual Mapping Documentation articles and the mapping collection descriptions in the iPaaS.com subscription.