OroCommerce Integration Known Limitations

These are the known limitations of the OroCommerce integration. They are inherent to the current design of the integration and to the capabilities of the OroCommerce API, and they apply to all subscribers.

This integration was built for OroCommerce (the OroCommerce B2B Commerce application) and communicates with its store-management REST API.

Not built for: This integration is specific to OroCommerce. It is not built for, and will not work against, other Oro products or unrelated commerce platforms (for example OroCRM used on its own, OroMarketplace, or Marello). If Oro releases a separate product line or a materially different API version in the future, this integration will not automatically support it.

New and updated OroCommerce orders are brought into iPaaS.com on the integration's polling schedule rather than instantly. The integration checks OroCommerce for orders created or changed within a recent time window, controlled by the Order Poll Days setting.

What this means for you: An order placed or updated in OroCommerce appears in iPaaS.com after the next poll, not the moment it is saved. Set Order Poll Days wide enough to cover the gap between polls so no order is missed, and expect a short delay between an order changing in OroCommerce and it arriving in iPaaS.com.

When bulk prices are sent from iPaaS.com to OroCommerce, each price is applied for a single product unit. Any unit-of-measure information on the iPaaS.com bulk price is not used.

What this means for you: Configure your OroCommerce products and price lists around the single pricing unit the integration uses. If your workflow requires prices that differ by unit of measure, submit a feature request through your iPaaS.com partner channel describing the requirement.

OroCommerce rejects a new price list whose name matches an existing one.

What this means for you: Make sure each price list produced by the integration has a distinct name. If two source records would create price lists with the same name, the second will fail to create until the name is made unique.

OroCommerce price lists are global, and the integration assigns customer groups to them when bulk pricing is transferred. Removing a customer group from a price list is done in OroCommerce, not from iPaaS.com.

What this means for you: Adding or updating bulk pricing assigns the relevant customer groups to the price list. If you later need a customer group to stop using a price list, remove that assignment in OroCommerce directly.

Several fields are resolved by looking up an existing OroCommerce record by name or code — for example a country, region, attribute family, tax code, brand, category, business unit, or organization. The looked-up record must already exist in OroCommerce for the transfer to resolve it.

What this means for you: Create the supporting records in OroCommerce (or confirm they exist) before transferring data that references them. If a referenced record is missing, the transfer reports an error identifying the value it could not resolve instead of creating a partial record.

A company transfer resolves its customer group from a customer category. The customer category must already be present in OroCommerce when the company is transferred.

What this means for you: Transfer customer categories before transferring companies that reference them. If a company arrives before its category, enable the Auto Create Customer Group setting to have the group created automatically, or transfer the category first.

To map data into an OroCommerce custom field, that custom field must already exist on the relevant OroCommerce entity, and a matching custom field must be configured on the iPaaS.com subscription.

What this means for you: Create the custom field in OroCommerce first, then add the matching custom field in iPaaS.com before mapping to it. OroCommerce offers two storage types for custom fields: a Serialized Field, which becomes available automatically, and a Table Column field, which requires an OroCommerce schema update before it can be used. Where possible, use the Serialized Field storage type to avoid a schema update; if you use a Table Column field, plan the schema update with your OroCommerce administrator, as it can briefly interrupt service.

When a kit product is updated from iPaaS.com, its kit items in OroCommerce are removed and recreated as part of the update. This happens on every kit product update, even when the kit definition has not changed.

What this means for you: This keeps the kit configuration in OroCommerce a faithful copy of the source, including support for adding or removing kit components. Expect kit items to be rewritten each time the kit product transfers; do not rely on manual edits to kit items in OroCommerce persisting across an update from iPaaS.com.

When you connect the subscription, the integration confirms that the required settings are present. It does not, at that moment, perform a live call against OroCommerce to confirm the credentials are accepted.

What this means for you: After connecting, run a test transfer to confirm the integration can reach OroCommerce with the supplied credentials. If credentials are missing a permission or were entered incorrectly, the issue surfaces on the first transfer rather than at connection time.

A bulk pricing transfer writes a price list together with its product prices and customer group assignments. If part of that transfer does not complete, the price list can be left partially updated.

What this means for you: After a large bulk pricing change, confirm in OroCommerce that the affected price list contains the expected prices and assignments. If a transfer reports an error, re-run it once the underlying cause (for example a missing customer group or product) has been resolved.

The integration moves each type of record in a single direction. Orders are sent from OroCommerce to iPaaS.com on the polling schedule; all other records (products, product variants, kits, companies, customer users, customer categories, bulk pricing, and shipment tracking) are sent from iPaaS.com to OroCommerce. No record type is synchronized in both directions.

What this means for you: Because nothing is sent both ways, there is no risk of a record bouncing back and forth between the two systems. Decide which system is the source of truth for each record type based on the direction above, and make your edits there. A change made on the receiving side is not sent back to the originating system.

When the integration updates an existing OroCommerce record from iPaaS.com, it sends a partial update that includes only the fields defined in the mapping.

What this means for you: Fields that are mapped are set to the iPaaS.com value on every transfer, so iPaaS.com (or the upstream source feeding it) is the source of truth for those fields — if you edit a mapped field directly in OroCommerce, the next transfer replaces your change. Fields that are not mapped are left untouched; the integration does not clear or overwrite OroCommerce data outside its mappings. Manage mapped fields upstream rather than in OroCommerce to avoid having manual edits replaced.

Note: Kit items are the one exception to the partial-update behavior. As described above, a kit product update removes and recreates the kit's items each time, so manual edits to kit items in OroCommerce do not persist across an update.

OroCommerce enforces per-instance request rate limits on its REST API. When the integration reaches one of those limits, the affected transfer is automatically rescheduled to resume after the limit window resets. No subscriber action is required. See OroCommerce's Request Rate Limit Rules documentation for how the limits are applied.

What this means for you: You do not need to do anything when a rate limit is hit — the integration waits and continues on its own once the window resets. Large transfers may take longer to finish while the integration paces its requests within OroCommerce's limits.

The integration does not back-load pre-existing OroCommerce records. Initialization is unsupported across all models, so records are synchronized going forward only, from the point the integration is active.

What this means for you: Records that already existed in OroCommerce before the integration was set up are not imported automatically. Only records created or updated from when the integration is active flow through the mappings; if you need historical data to move, transfer it through the normal mapping flow.

Deleting a record in one system does not delete its counterpart in the other. This applies across record types, including orders, line items, customers, customer users, customer categories, products, and pricing.

What this means for you: Removing a record in OroCommerce or in iPaaS.com (or its upstream source) does not remove the matching record in the other system. Manage any required deletions directly in each system.

The integration's templates ship with example values that each subscriber must review and replace for their own OroCommerce instance before relying on them in production. Many of these are set inside mapping formulas, where a sample name or code is used to look up the matching OroCommerce record. Replace each with the value that exists in your own OroCommerce instance.

This document covers fifteen known limitations of the OroCommerce integration plus a pre-go-live checklist of placeholder values to replace. For detailed, field-level documentation of each workflow, see the OroCommerce mapping collection descriptions and mapping documentation.