These are the known limitations of the SugarCRM integration. They are inherent to the current design of the integration and to the capabilities of SugarCRM's API, and they apply to all subscribers at the time this documentation was written.

This integration is built for SugarCRM and calls the SugarCRM REST API on your own SugarCRM instance, at https://<your-sugarcrm-host>/rest/<version>. It targets the SugarCRM v11 REST API (for example, v11_25).

It is not built for Sugar Market, which is a separate product with its own API, nor for SugarCRM's older SOAP or v10-and-earlier REST APIs. If SugarCRM introduces a separate product line or a materially different API version in the future, this integration will not automatically support it.

The integration does not run a background poll of SugarCRM. New and changed Accounts reach iPaaS.com either through SugarCRM's Web Logic Hook or through an on-demand Manual Sync.

What this means for you: Enable the Accounts event under the subscription's Inbound Data Flows so changes transfer automatically, or use the Manual Sync page to pull a specific Account. There is no setting to schedule a recurring background pull; to bring across a large batch of existing records, see bulk sync using Postman.

SugarCRM queues its Web Logic Hook events and delivers them when its scheduled cron.php job runs. The integration receives events only as fast as SugarCRM sends them.

What this means for you: Configure cron.php to run as frequently as possible on the SugarCRM server. If automatic transfers seem delayed, the cron.php schedule is the first thing to check.

The integration uses SugarCRM's native Web Logic Hooks, and it faithfully reflects how that feature behaves. SugarCRM records a webhook job as processed once it has sent it, even if the receiving server did not confirm receipt, and it does not eliminate redundant calls, trigger on advanced business logic, or automatically retry and notify on failure.

What this means for you: Treat a "processed" webhook job in SugarCRM as "sent," not as "confirmed received." If you suspect a change did not transfer, re-sync the Account from the Manual Sync page. For a workflow that needs guaranteed delivery or advanced triggering, submit a feature request to your iPaaS.com partner channel describing the requirement.

The integration does not perform an initialization (a bulk import of all existing records on first connect).

What this means for you: Configure your mappings and transfer records through Manual Sync or automatic transfers. To load a large set of existing Accounts at go-live, use the bulk sync using Postman workflow.

SugarCRM stores a single billing address and a single shipping address on the Account record. The integration transfers the primary billing address and the primary shipping address in each direction.

What this means for you: Only the Customer's primary billing and primary shipping addresses are written to SugarCRM, and only SugarCRM's billing and shipping addresses are captured back. Additional addresses held in iPaaS.com are not transferred.

SugarCRM keeps contacts as records related to an Account, while an iPaaS.com Customer has no separate contact record. The integration maintains one primary contact per Account, using the Account fields whose names begin with Contact_. When no contact has been linked yet, the first contact associated with the Account is the one used.

What this means for you: For Accounts with more than one contact, review which contact should be the primary one so the intended contact is linked. Map the SugarCRM PrimaryContactID field so the same contact is matched on later transfers instead of a new one being created.

When the integration updates a record, it sends the complete record rather than only the changed fields. Any field that is not mapped is set to empty on each update. On the iPaaS.com side this affects the Customer Comment field and the Customer Address Company, FirstName, LastName, PhoneNumber, and Type fields; on the SugarCRM side it affects Account fields that are not part of the mapping set.

What this means for you: If you rely on a field that the default mappings do not cover, either add a mapping for it or preserve it by splitting the combined Add/Update collection into separate Add and Update collections and carrying the value forward with a Dynamic Formula (for example, DestinationValue.Comment). Validate the behavior of SugarCRM fields outside the mapping set in a staging environment before enabling automatic transfers.

SugarCloud enforces a published limit of 20 API requests per second. SugarCRM's policy requires at least 7 calendar days' advance notice, raised as a case with SugarCRM, before activity that will exceed that rate either temporarily or on an ongoing basis.

What this means for you: For a large initial load or a sustained high-volume sync, arrange the increased rate with SugarCRM beforehand, and reduce the subscription's throttle settings if you encounter rate-limit errors. Routine transfers stay well within the limit; when the limit is reached, the transfer is retried automatically once the window resets.

The default mappings ship with an example custom-field mapping in each direction. Review and replace it before go-live.

This document covers eight known limitations of the SugarCRM integration, plus the placeholder values to replace before go-live. For detailed, per-field behavior, see the SugarCRM mapping collection descriptions and the SugarCRM to iPaaS.com and from iPaaS.com Account Mapping Documentation.