This article describes the known limitations of the iPaaS.com Salesforce integration so that subscribers and their MiSP can plan their implementation with the integration's current scope in mind. The behaviors below are accurate at the time this documentation was written; the integration is actively developed, so confirm the current behavior in your subscription if you are relying on a specific point.

The Salesforce integration keeps Account and Contact records (and their addresses) in step between Salesforce and iPaaS.com. Account and Contact data is bi-directional; the Contact-to-Company relationship is synced into iPaaS.com only. For how to connect and configure the integration, see the Salesforce Connections and Settings article.

The limitations below reflect this scope as of June 2026.

The integration detects Salesforce changes by polling on a schedule rather than receiving real-time push notifications. There is no inbound Salesforce webhook. As a result, changes made in Salesforce appear in iPaaS.com on the integration's next polling cycle rather than the instant they are saved.

The first time the integration polls each record type, it looks back over a configurable window of history (the Account Poll Days and Contact Poll Days settings, which default to 7 days each) so that existing records can be picked up. Increase these values if you need the integration to pick up records that changed further in the past on its first run. At the time this documentation was written, there is no real-time option.

What this means for you: Do not expect Salesforce changes to appear in iPaaS.com instantly. Plan for a short delay between saving a record in Salesforce and seeing it in iPaaS.com, and time any verification you do around the polling cycle rather than expecting an immediate result.

When iPaaS.com writes data back to Salesforce (a FROM iPaaS.com update), updates are partial. Fields that are not mapped, or that arrive empty, are left unchanged on the existing Salesforce record rather than being blanked. This protects existing Salesforce data from being unintentionally cleared, but it also means the integration will not clear a value in Salesforce simply because the corresponding value is empty in iPaaS.com.

This behavior applies to the Salesforce fields the integration writes back from iPaaS.com. The fields affected on each object are:

If you need to force a specific value into one of these Salesforce fields, including clearing it, add a mapping that supplies that value directly, for example a Static or Destination Value mapping, rather than relying on an empty source value. At the time this documentation was written, there is no field-blanking behavior for unmapped or empty fields.

What this means for you: A blank value in iPaaS.com will never erase the matching value already in Salesforce. If you intend a write-back to overwrite or clear one of the fields listed above, you must map an explicit value for it (for example a Static or Destination Value); otherwise the existing Salesforce value stays as it is.

Deleting a record in one system does not delete the corresponding record in the other, in either direction. Removing a Customer or Company in iPaaS.com does not delete the related Contact or Account in Salesforce, and deleting a record in Salesforce does not delete its counterpart in iPaaS.com. At the time this documentation was written, deletions must be handled manually in each system.

What this means for you: If you remove a record in one system, plan to remove the matching record in the other system yourself. The integration will not propagate the deletion, so the counterpart record will remain until you delete it manually.

Salesforce stores addresses directly on the parent record rather than as separate address records. The integration moves those built-in fields only:

There are no separate, standalone Salesforce address records, and the integration does not create or manage multiple address records per Account or Contact beyond these built-in fields. When iPaaS.com writes a Contact address back to Salesforce, only the address marked as the primary shipping address in iPaaS.com is written. At the time this documentation was written, this is the full extent of address support.

What this means for you: Only the single Billing and Shipping address on an Account, and the single Mailing address on a Contact, move through the integration. If you keep several addresses per record in iPaaS.com, only the primary shipping address reaches Salesforce; the others will not be synced.

A Contact is always tied to its Account or Company, so the related parent record must already exist before the Contact is synced:

To avoid creating duplicate iPaaS.com customers, the integration links to an existing iPaaS.com customer by email address when one matches. At the time this documentation was written, the related parent record must exist first; the integration does not create it on the Contact's behalf.

What this means for you: Sync or create the Account or Company first, then the Contact. A Contact whose parent record does not yet exist on the receiving side, or a Salesforce Contact with no Account assigned, will be skipped rather than created. Establishing the parent record up front avoids these skips.

The integration ships with example custom-field mappings to demonstrate how Salesforce custom fields can be mapped to and from iPaaS.com. These example mappings are illustrative only and are not intended to transfer data as shipped. The Salesforce custom fields and the matching iPaaS.com fields differ from one environment to the next, so these mappings must be configured for your own implementation before they will move data. For the custom-field example values that must be replaced, see Placeholder Values to Replace Before Go-Live below.

When you add your own custom-field mappings, create the corresponding fields in both Salesforce and iPaaS.com, named to match, before adding the mapping. At the time this documentation was written, no custom-field mapping works without this per-environment configuration.

What this means for you: Treat the example custom-field mappings as templates, not as working mappings. Before go-live, replace them with your own matching fields in both systems, or remove them; left unchanged, they will not move any data.

The integration does not assign customer categories as part of the Account or Contact sync. At the time this documentation was written, category assignment is outside the scope of the integration and must be managed separately.

What this means for you: If you rely on customer categories in iPaaS.com, assign and maintain them through another process. Syncing an Account or Contact will not set, change, or clear a customer category.

The custom-field example mappings described above contain placeholder values that must be replaced for your environment before go-live. They will not move data until they are configured:

For each example, create the matching fields in both Salesforce and iPaaS.com before adding the mapping, and verify the data transfers as expected before relying on it in production.

This article lists 7 known limitations of the Salesforce integration, current as of June 2026: poll-based change capture, the unmapped-field overwrite behavior on updates sent to Salesforce, record deletions not being synced, address support limited to the parent record's built-in address fields, the requirement that Contacts have an existing related Account or Company, custom-field example mappings being implementation-specific, and customer category assignment being out of scope. The Placeholder Values to Replace Before Go-Live section above is a go-live checklist for the custom-field examples rather than a separate limitation. For questions about any of these, contact iPaaS.com support.