This article describes the known limitations of the Epicor Prophet 21 integration. These limitations are inherent to the integration's current design and to the capabilities of the Epicor Prophet 21 API, and they apply to all subscribers. They are described here so that subscribers, or their MiSP, can plan their configuration with the integration's behavior in mind. The descriptions reflect the integration as it was at the time this documentation was written.

This integration was built for Epicor Prophet 21 and communicates with a Prophet 21 instance over its REST and OData web services.

The integration keeps Prophet 21 and iPaaS.com aligned by polling on a schedule rather than by receiving real-time push notifications. Records flowing from Prophet 21 into iPaaS.com are picked up on the integration's regular polling cycle, within a per-entity look-back window controlled by the relevant Poll Search Days subscription setting. Records flowing from iPaaS.com into Prophet 21 are processed when the integration next runs. No webhook configuration is required, and none is used.

What this means for you: Changes are not reflected on the other platform the instant they happen — they appear after the next poll. This is the right shape for this integration: the look-back windows and polling cadence are designed for steady, reliable synchronization. If you need a record to move immediately, use the Manual Sync page to transfer it on demand rather than waiting for the next scheduled poll. If your workflow depends on tightening or widening how far back the integration looks, adjust the per-entity Poll Search Days settings described in the Connections and Settings article.

The integration does not provide a one-click bulk initialization that loads an entire historical dataset in a single pass. Synchronization is driven by the scheduled poll and by Manual Sync, both of which work on a record-by-record basis.

What this means for you: To bring existing records across for the first time, you can either widen the relevant Poll Search Days window so the scheduled poll reaches further back, or transfer individual records on demand from the Manual Sync page. For a larger historical or one-time load, follow the canonical iPaaS.com bulk-sync procedure, which uses Postman's Collection Runner to drive a Manual Sync across many records:

Syncing a large dataset using iPaaS.com and Postman Runner

Note: Plan a bulk load to respect the integration's throttling controls — the per-entity Poll Search Days windows and the Concurrent Batch Executions setting — so a large run does not overwhelm either platform. These controls are described in the Connections and Settings article.

When the integration writes a record into Prophet 21 — a customer, an order and its lines, a shipping address, or tracking detail — it sends only the fields that are populated and mapped on the iPaaS.com source. Fields that are not mapped, or that have no value, are left out of the write. Prophet 21 keeps its existing value for any field the integration does not send.

What this means for you: There is no risk that an unmapped field in Prophet 21 is blanked out or overwritten on a transfer. For the fields you do map, iPaaS.com is the source of truth — those values are written into Prophet 21 on each transfer. For everything else, the existing Prophet 21 value remains intact. If you want a particular Prophet 21 field to be maintained from iPaaS.com, map it; if you want Prophet 21 to retain its own value for a field, leave that field unmapped.

Note: This applies to the collections that write into Prophet 21 (the FROM iPaaS.com direction — customers, orders, order lines, order addresses, and tracking detail). For collections that read from Prophet 21 into iPaaS.com (the TO iPaaS.com direction), the record in iPaaS.com reflects the Prophet 21 record as it stood at the most recent poll.

Several entities are organized as a parent record with one or more child records — for example, a company with its address and its related contacts, a product with its inventory, or an order with its lines, shipping address, and tracking detail. A child record attaches to its parent using the parent's external identifier, which iPaaS.com saves after the parent transfers successfully.

What this means for you: A child record can only attach once its parent is present on the destination platform and carries its external identifier. In normal operation the integration handles this for you, transferring parents and their children together. If you transfer records manually, transfer the parent first (for example, the company before its address and contacts, or the product before its inventory) so the children have a parent to attach to.

When an order is written into Prophet 21, the integration requires that every line on that order carries a distinct SKU. Prophet 21 treats the SKU as the line's key, so the same SKU cannot appear on two lines of the same order. The integration checks this before the order is written: if a transaction has two or more lines that share a SKU, the transfer is stopped and the duplicated SKUs are reported.

What this means for you: Build orders so that each line item has its own unique SKU. If a single product appears more than once on an order, combine those into one line with the total quantity rather than repeating the SKU across multiple lines. If a transfer is stopped for a duplicate SKU, the reported SKU tells you which product is repeated so you can consolidate it on the source order.

Some transfers depend on related records already being present:

What this means for you: Sync products before the orders that reference them, sync locations before the inventory that belongs to them, and make sure a matching iPaaS.com Shipping Method exists before relying on tracking detail to flow into iPaaS.com. If an order, an inventory record, or a tracking record does not transfer as expected, confirm that its product, its location, or its Shipping Method has already been set up. Once the prerequisite record is present and carries its identifier, the dependent record transfers on the next run.

A small number of fields are set automatically to fixed values that the integration supplies, rather than being mapped from your data. These are deliberate design choices that place each record correctly in the destination platform:

What this means for you: These values are part of the integration's design and are applied consistently to every record of that type — you do not need to map them, and they are not intended to be changed per record. If your workflow requires a different product type, a different relationship role, a different sales location, or a different default carrier, validate the behavior in a staging environment first, and submit a feature request through your iPaaS.com partner channel describing the requirement so it can inform a future release.

When an order is written into Prophet 21, its shipping address and tracking detail come with their own expectations:

What this means for you: Make sure the source transaction has one address flagged as the primary shipping address, with its city, region, and country filled in. For tracking detail, confirm that the pick ticket exists in Prophet 21 and that the shipping method matches a carrier already configured there. If a carrier is not configured in Prophet 21, add it there before relying on the tracking transfer.

For certain records, the name shown in the destination platform is built by the integration from the detail available on the source record, rather than being a single field you map:

What this means for you: You do not map these composed names directly; the integration produces them from the underlying fields. To influence the resulting name, maintain the fields it draws on — keep first and last names, company names, and address detail populated and accurate on the source record so the composed name resolves to the value you expect.

Prophet 21 permits more than one customer to carry the same email address. When email is the value used to find a matching record, duplicate emails can make that lookup ambiguous.

What this means for you: A unique email address per customer is recommended so that records match cleanly and are not conflated. Likewise, keep customer numbers and source identifiers unique on the iPaaS.com side so each record resolves to a single counterpart. Reviewing and de-duplicating email addresses in Prophet 21 helps the integration link records to the right customer.

For some entities, the initial creation of a record and its later updates are handled by separate mapping collections. For example, a Prophet 21 customer, company, or location is created by one collection and kept up to date by a companion "Update" collection.

What this means for you: This is simply how those flows are organized — both the create and the update collections ship with the integration and work together, so a record is created once and then kept current on subsequent polls. No action is needed beyond having both collections enabled, which is their shipped state. The mapping collection descriptions identify which collection handles creation and which handles updates for each entity.

When connection settings are saved in the subscriber portal, the integration confirms the settings are in place. This is not a live round-trip test that contacts Prophet 21 to verify the API URL and credentials at that moment.

What this means for you: A saved connection does not by itself guarantee that the API URL is reachable or that the credentials are valid — those are exercised on the first real transfer. After configuring the connection, run a Manual Sync on a single record to confirm the integration can actually reach Prophet 21 and authenticate. If that first transfer reports an authentication or connection error, re-check the API URL, user name, and password in the Connections and Settings before relying on the scheduled poll. Transfer errors appear in Dashboard / Integration Monitoring / Error Logs.

This article covers 12 known limitations of the Epicor Prophet 21 integration. For the detailed, per-collection technical documentation — including the exact fields each collection transfers and the conditions under which records are processed — see the Epicor Prophet 21 mapping collection descriptions.