Standalone products are transferred from iPaaS.com into Adobe Commerce/Magento 2 as simple products. The product record carries the SKU, name, price, status, tax class, weight, stock figures and category assignments, and two child collections write the product's per-location inventory and its alternate units of measure onto the same product.

The family ships as an add-only collection paired with an update-only collection, each with its own inventory and unit children. Creation and maintenance can therefore be filtered and enabled independently. The transfer is unidirectional — products move from iPaaS.com into Adobe Commerce/Magento 2 only.

Configurable products and their variants are covered by a separate family; this documentation covers standalone products only.

Enter the iPaaS.com Product record identifier — the internal numeric identifier of the product in iPaaS.com, for example 58231.

This is not the product SKU. Entering a SKU will not resolve a product record.

After a successful transfer, iPaaS.com stores the Adobe Commerce/Magento 2 product SKU as the external ID on a record linking the iPaaS.com product to its Magento counterpart. That record is what routes later transfers of the same product to the existing Magento product for an update rather than creating a duplicate, and it is what the standalone inventory collections read to resolve the SKU.

Outbound delete is supported for products through a separate delete mapping, which is not part of this family and is not included in the default templates. Removing a product in iPaaS.com does not remove it from Adobe Commerce/Magento 2 through the collections documented here.

This family reads several iPaaS.com product custom fields, which must exist by these exact names for the behavior they control to work:

A catalog that does not use these behaviors does not need the fields; the standard calculations then apply.

Status: Enabled. All six collections in this family ship enabled.

Trigger Events: Creation or update of Product records in iPaaS.com, plus Manual Sync on demand.

Automatic outbound transfers are enabled on the subscription's Outbound Data Flows page. Until that flow is enabled, no products are sent automatically. Manual Sync is always available regardless.

Subscribers or their MiSP should review the filters and the sync settings on all of these collections together before enabling or modifying any of them.

This integration implements no selectable collision-handling methods, and the behavior is not configurable on these collections. The link between the iPaaS.com product and its Magento SKU decides whether a transfer creates or updates; where no link exists, the add collection creates a new product.

When a product is re-transferred, the fields this family maps are written again over the existing Magento product. Values edited directly in the Magento admin on any mapped field will be replaced.

The integration provides no guarantee that unmapped or blank fields are preserved on a product update. Subscribers or their MiSP should validate in a staging environment which fields are affected on their own store before relying on manual edits to any product this family transfers.

The CategoryIds mapping is the one deliberate exception: for a product flagged as a parent item, it instructs the integration to leave existing Magento category assignments untouched.

The fields at risk are every field the parent collections map — Sku, Name, AttributeSetId, Price, Status, Visibility, TypeId, Weight, StockItemQty, StockItemIsInStock, TaxClassId, Cost, SpecialPrice, CategoryIds, AlwaysInStockOverride and UrlKeyMethodOverride — plus the per-source quantity and status written by the inventory child and the unit values written by the unit child.

The mitigation is a DestinationValue. Where a Magento field must hold a specific value that the source system does not supply, set a DestinationValue on that mapping so the integration writes the value chosen there instead of taking it from the source. Values that must be maintained only in Magento should be kept on fields these collections do not map.

The parent collections are Add Adobe Commerce/Magento 2 Simple Product FROM iPaaS.com and Update Adobe Commerce/Magento 2 Simple Product FROM iPaaS.com. Each is the parent of two child collections, which write onto the Magento product created or updated by their parent and do not transfer independently of it.

Each row below is a pair of collections — one add-only and one update-only. In the iPaaS.com interface they appear under their own names, beginning Add and Update respectively (for example Add Adobe Commerce/Magento 2 Simple Product Inventory FROM iPaaS.com and Update Adobe Commerce/Magento 2 Simple Product Inventory FROM iPaaS.com). They are documented together here because their mappings are identical.

Full step-by-step setup instructions are in the Adobe Commerce/Magento 2 Installation Instructions article.

Because the product and its children are written as one sequence, a subscriber troubleshooting a product that arrived in Magento with no per-location inventory or no alternate units should check the child collections' filters before concluding the product transfer failed.

Subsections headed Add / Update cover an add-only and an update-only collection that share the same mappings. Where the pair differs, both filters are shown and the differing rows are marked.

iPaaS.com data type: Product

Mapping Filter — Add collection

Mapping Filter — Update collection

Both collections process iPaaS.com product records whose tracking method is Product, which restricts them to standalone products and excludes variant records handled by the associated product variant collections. Both also exclude one specific SKU. The update collection adds a third condition excluding records flagged as a secondary update, so that an inventory-only movement does not re-send the complete product payload — those records are the subject of the inventory totals collection instead. Records that do not pass are skipped without error.

Placeholder value — replace during implementation: the excluded SKU GC-TEST-100 is a test gift-card record carried over from the template environment. Replace it with the SKUs the store actually needs to exclude, or remove the exclusion if it has no meaning in the catalog.

The two collections map the same seventeen shared fields. The only difference is the date stamp: the add collection writes CreatedAt, the update collection writes UpdatedAt. Both rows are shown in the table below and marked accordingly.

iPaaS.com data type: Product Inventory

Neither the add nor the update child carries a mapping filter, and both map the same three fields identically. They inherit the product from the transfer above them, so they need no product-existence condition of their own — that condition belongs only to the standalone inventory collections, which have no transfer above them.

iPaaS.com data type: Product Unit

Mapping Filter

Both the add and the update child carry this identical filter and map the same four fields. The filter excludes units belonging to one specific parent SKU.

Placeholder value — replace during implementation: the excluded parent SKU ADM-TL2 is an example exclusion carried in the template. Replace it with the SKUs the store actually needs to exclude, or remove the exclusion if it has no meaning in the catalog.

Used by the Status mapping on both parent collections.

In Adobe Commerce/Magento 2, 1 means Enabled (visible and purchasable, subject to visibility and stock) and 2 means Disabled. A status with no matching row is not translated: no status value is sent, and the product is created with Magento's own default status rather than the state intended by the source record. This is silent rather than reported, so complete the translation before the first production run.

Used by the TaxClassId mapping on both parent collections.

The final row is entered as a formula whose value is always true and placed last, so any tax class not matched by the rows above it is mapped to Taxable Goods. A tax class that has no row of its own — including one that is misspelled or newly added in iPaaS.com — is therefore not skipped, it is taxed as Taxable Goods.

Subscribers or their MiSP must verify these destination IDs against their own store: custom tax classes created in Magento receive their own IDs, and the IDs above are correct only for a store using the stock classes. Add an explicit row for every tax class the catalog uses, above the fallback row, and review whether Taxable Goods is the right default.

Used by the SourceCode mapping on both inventory children. This is the same translation used by the standalone inventory collections, so a change made here affects those transfers too.

The source side is not a plain location name — each row matches the inventory record's location by resolving an iPaaS.com location name to its identifier and comparing it to the location on the record.

Placeholder value — replace during implementation: the shipped location names and the Magento source codes they point at are example values. Replace the location name inside the match condition on the source side and the source code on the destination side, editing each row in place rather than replacing the row as a whole — a bare location name on the source side breaks the lookup. Ensure exactly one row per iPaaS.com location, and confirm the mapping is one-to-one.

The full catalog of messages this integration produces, with causes and resolutions, is in the Adobe Commerce/Magento 2 Error Messages article. The conditions most often seen on this transfer are:

Errors are reported under Dashboard / Integration Monitoring / Error Logs.