Summary
Product-to-category membership is transferred from iPaaS.com into Adobe Commerce/Magento 2. Each iPaaS.com product category assignment becomes one product-to-category membership in the Magento catalog, so the product appears under the intended category in catalog navigation and in category-driven merchandising.
Two standalone collections cover this: an add-only collection that creates assignments, and a delete collection that removes them. The delete collection carries no mappings, by design — a delete has no field data to map.
Category membership is carried by its own record rather than folded into a product update, so that a product update arriving from another source cannot be processed ahead of the category assignment and leave the product filed in the wrong place in the catalog tree.
ID Format
Manual Sync ID Format
Enter the iPaaS.com product category assignment record identifier, for example 91204.
This is not the product identifier and it is not the category identifier — it is the identifier of the assignment record that joins them.
For the delete collection, the identifier must be supplied in the form <product_id>|<category_id>. A value that is not in that form is rejected with an error naming the expected format.
External ID Format
An assignment is identified in Adobe Commerce/Magento 2 by the combination of the product SKU and the category identifier rather than by an identifier of its own. Both are resolved from the external-ID records that the product and category transfers created, so those transfers must have run before an assignment can land.
Deleted Record Support
Delete is supported for category assignments, through the dedicated delete collection documented below. It is one of only a few entities in this integration where an outbound delete propagates.
Removal does not happen unless that collection exists and is enabled. Clearing a category on a product in iPaaS.com alone does not unassign it in Magento.
One gap applies at the time this documentation was written: if the last remaining category assignment on a product is deleted in iPaaS.com, the assignment is not removed in Adobe Commerce/Magento 2. Assigning a different category to that product allows a later product update to clear the abandoned assignment.
Custom Field Support
Neither collection reads a custom field. Both resolve their targets from the external-ID records created by the product and category transfers.
Mapping Collection Status
Status: Enabled. Both collections ship enabled.
Trigger Events: Creation of a product category assignment in iPaaS.com for the add collection, and removal of one for the delete collection, plus Manual Sync on demand.
Automatic outbound transfers are enabled on the subscription's Outbound Data Flows page. Until that flow is enabled, no assignments are sent automatically. Manual Sync is always available regardless.
Duplicate or Conflicting Mappings
The product collections also write category membership through their CategoryIds mapping, which resolves the categories held on the iPaaS.com product and assigns the product to them. That mapping replaces a product's assignments wholesale, except where the product is flagged as a parent item, in which case existing Magento assignments are left untouched. These assignment collections and the product families can therefore both change the same membership, and the last transfer to run decides it.
Add/Update Adobe Commerce/Magento 2 Product Category FROM iPaaS.com creates the categories these assignments point at. It is easily confused with these collections but acts on a different entity — it neither assigns nor unassigns products.
Subscribers or their MiSP should decide whether category membership is maintained through the product record or through these assignment records, and review both paths together before enabling either.
Duplicate matching
This integration implements no selectable collision-handling methods, and the behavior is not configurable on these collections. An assignment is identified by the product SKU plus the category identifier, so re-sending an assignment that already exists does not create a second one.
Unmapped field overwrite risk
These collections write no product or category attributes — only the membership link. The only values they map are Sku and CategoryId, both resolved rather than copied, so there is no field on either record whose manually edited value can be replaced by this transfer.
The overwrite risk here sits with the product collections instead: their CategoryIds mapping replaces a product's assignments on every transfer. The mitigation is a DestinationValue. Where a product's Magento category membership must hold a specific value that iPaaS.com does not supply, set a DestinationValue on that product mapping, or flag the product as a parent item so its existing assignments are left untouched.
Supported Child Collections
None. Both collections are standalone, with no parent and no children. Each acts on a single membership link and has no subordinate data to contribute.
System Caveats
Adobe Commerce/Magento 2 Caveats
Both the product and the category must already exist in Magento. An assignment names them; it never creates them.
Deleting the last assignment on a product does not remove it. Magento retains the final category membership. Assign a different category to that product so a later product update can reconcile it.
Assignment writes are subject to Magento's API limits. A large initial membership load can encounter Adobe Commerce/Magento 2 request-array and page-size limits. Stagger large manual catch-up runs rather than issuing them concurrently.
iPaaS.com Caveats
The product's external-ID record must be intact. The Magento SKU is resolved from the record linking the iPaaS.com product to its Magento counterpart. Without it the assignment cannot name a product.
The category's external-ID record must be intact. The Magento category identifier is resolved the same way. An assignment whose category cannot be resolved does not land in Magento.
Transfer order matters. Products and categories must both have transferred successfully before their assignments are enabled.
Integration-Specific Caveats
The delete collection carries no mappings, and that is correct. A delete has no field data to map — the collection exists to authorize and scope the removal. Subscribers or their MiSP should not add mappings to it.
The add collection never removes. It is deliberately add-only. Removing an assignment is handled solely by the delete collection.
There is no back-fill of pre-existing membership. Assignments that existed in Adobe Commerce/Magento 2 before the integration was installed are not linked to iPaaS.com assignment records automatically.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Confirm the products and categories the assignments reference already exist in the store.
iPaaS.com Configuration
Transfer the category structure and the products before enabling these collections.
Decide whether category membership is maintained through the product record's category mapping or through these assignment records, and configure only the intended path.
Confirm the delete collection is enabled if removals need to propagate; without it, clearing a category in iPaaS.com has no effect in Magento.
Enable the outbound flow for Adobe Commerce/Magento 2 category assignments on the subscription's Outbound Data Flows page.
Full step-by-step setup instructions are in the Adobe Commerce/Magento 2 Installation Instructions article.
Integration Flow
A product category assignment is created or removed in iPaaS.com, or a Manual Sync is run against one.
For an addition, the product referenced on the assignment is resolved to its Magento SKU, and the category referenced on it is resolved to its Magento category identifier.
The product is updated in Adobe Commerce/Magento 2 to include that category in its membership.
For a removal, the supplied identifier is split into its product and category parts and the membership is removed from that product in Magento.
Mappings
Add Adobe Commerce/Magento 2 Product Category Assignment FROM iPaaS.com
iPaaS.com data type: Product Category Assignment
This collection carries no mapping filter — every assignment record is processed. Subscribers or their MiSP who need only part of their iPaaS.com category membership to reach Adobe Commerce/Magento 2 should add a mapping filter before enabling the outbound flow, rather than relying on the transfer to exclude anything on its own.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Dynamic Formula |
| Sku | Required. Identifies which Magento product is being assigned. Resolves the product referenced on the assignment record to the Magento SKU recorded when that product was first transferred. An assignment whose product cannot be resolved does not land. |
Dynamic Formula |
| CategoryId | Required. Identifies which Magento category the product is assigned to. Resolves the category referenced on the assignment record to the Magento category identifier recorded when that category was first transferred. An assignment whose category cannot be resolved does not land. |
Delete Adobe Commerce/Magento 2 Product Category Assignment FROM iPaaS.com
iPaaS.com data type: Product Category Assignment
This collection carries no mappings and no mapping filter, and both are correct. A delete carries no field data — the collection exists to authorize and scope the removal of a membership link. Its absence would mean removals never propagate: without a delete collection, clearing a category in iPaaS.com removes only the internal link and leaves the assignment in place in Magento.
The identifier this collection acts on must be supplied in the form <product_id>|<category_id>. An identifier that is not in that form is rejected, and the failure names the expected format.
Because it has no mappings, there is no field mapping table for this collection. Subscribers or their MiSP should not add mappings to it — a delete collection that carries mappings is a different behavior, in which the removal triggers an update of the linked data instead of a deletion.
Error Handling
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 these transfers are:
Error message: Product Category Assignment Delete Attempt Failed: The supplied id was not in the correct format. It should be <product_id>|<category_id>. The identifier passed to the delete collection was not in the expected combined form. Resolution: supply the identifier as the product identifier and category identifier joined by a vertical bar.
An assignment that does not appear in Magento. Either the product or the category could not be resolved to its Magento counterpart. Resolution: confirm both the product transfer and the category transfer have run and completed successfully, then re-send the assignment.
The product to remove from a category was not found. The product named by a delete no longer exists in Magento. Resolution: confirm the product still exists, or accept that the membership is already gone.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
Create a category assignment in iPaaS.com for a product and category that have both transferred, and confirm the product appears under that category in Magento.
Manually sync using the iPaaS.com assignment record identifier and confirm it resolves.
Create an assignment referencing a category that has not yet transferred, and confirm it does not land.
Re-send an assignment that already exists and confirm a second membership is not created.
Remove an assignment in iPaaS.com and confirm the membership is removed in Magento, with the delete collection enabled.
Disable the delete collection, remove an assignment, and confirm the membership remains in Magento — verifying that removal depends on that collection.
Pass a malformed identifier to the delete collection and confirm the format error is raised.
Remove the last remaining assignment on a product and confirm it is not removed in Magento; then assign a different category and confirm a later product update reconciles it.
Assign categories through the product record's category mapping and through these collections in turn, and confirm which path last decided the membership.
Validation Checklist
Products and categories have both transferred before assignments are enabled.
The delete collection is enabled if removals need to propagate.
The delete collection carries no mappings.
The chosen path for maintaining membership — the product record or these assignment records — is the only one enabled.
The last-assignment gap is understood and, where it matters, a fallback category is in use.
Additional Notes
These collections are one of the few places in this integration where an outbound delete propagates. Most entities do not support it.
The add collection and the delete collection are deliberately separate, and the delete collection's empty mapping list is by design rather than an omission.
Validate filter changes in a staging environment before enabling automatic transfers in production.