Summary
Product categories are transferred from iPaaS.com into Adobe Commerce/Magento 2. Each iPaaS.com product category becomes one Magento category, carrying its name, its place in the Magento category tree, and its display order among sibling categories. Every category arrives enabled, because the active state is sent as a fixed value rather than sourced from iPaaS.com.
A single collection handles both new categories and subsequent updates to categories already created. The categories it creates are the targets that product transfers assign products to, so it normally runs before the product families.
The transfer is unidirectional. Categories move from iPaaS.com into Adobe Commerce/Magento 2 only.
ID Format
Manual Sync ID Format
Enter the iPaaS.com product category record identifier, for example 4021.
The category name is not accepted as a Manual Sync value.
External ID Format
After a successful transfer, iPaaS.com stores the Adobe Commerce/Magento 2 category identifier as the external ID on a record linking the iPaaS.com product category to the Magento category. That record routes later transfers of the same category to the existing Magento category for an update rather than creating a second one, and it is also what the parent-resolution formula reads when placing a child category in the tree.
Deleted Record Support
Outbound delete is not supported for categories. Clearing or removing a category in iPaaS.com does not remove the corresponding Magento category, and delete mappings are not included in the default templates for this collection.
The separate category assignment collections manage the link between a product and a category; neither creates nor removes the categories themselves.
Custom Field Support
This collection reads two iPaaS.com custom fields on the product category record:
Sort Order: a whole number controlling the category's display position among its siblings. When the field is absent, empty, or holds a value that is not a whole number, the position falls back to 0.
Shared Catalog Ids: read by the store-view mapping. When it holds a value, the category is scoped to the B2B store view; when it is empty, no store view is resolved. Note the field name carries spaces, unlike the SharedCatalogIds destination field.
Mapping Collection Status
Status: Enabled. This collection ships enabled and processes every iPaaS.com product category record that is not flagged as a shared catalog.
Trigger Events: Creation or update of Product Category 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 categories are sent automatically. Manual Sync is always available regardless.
Whichever method is used, transfer order matters. A category's parent must already exist in Adobe Commerce/Magento 2 when the child is transferred, or the child is created at the root of the catalog tree instead of beneath its parent.
Duplicate or Conflicting Mappings
Add/Update Adobe Commerce/Magento 2 Shared Catalog FROM iPaaS.com reads the same kind of iPaaS.com product category record and writes it as an Adobe Commerce B2B Shared Catalog rather than an ordinary category. It processes only the categories whose IsSharedCatalog custom field is true.
The two collections divide the same records between them. This collection takes the categories where the flag is absent or false; the Shared Catalog collection takes the ones where it is true. Because the two conditions are complements, an ordinary category is written once and a shared catalog once, and neither is written by both.
One case falls outside both conditions. A record whose IsSharedCatalog value is neither empty nor a recognised true or false — a typo, or a value left over from another process — satisfies neither filter and is silently skipped by both collections. No error is raised. Subscribers or their MiSP should confirm the flag holds only empty, true, or false values before enabling the outbound flow.
Add Adobe Commerce/Magento 2 Product Category Assignment FROM iPaaS.com and Delete Adobe Commerce/Magento 2 Product Category Assignment FROM iPaaS.com manage the link between a product and a category. They are easily confused with this collection but act on a different entity, and neither creates nor removes categories.
The product collections also write category membership through their CategoryIds mapping. A product flagged as a parent item has its existing Magento category assignments left untouched by that mapping; every other product has its assignments replaced from iPaaS.com.
Duplicate matching
This integration implements no selectable collision-handling methods, and the behavior is not configurable on this collection. The external-ID record linking the iPaaS.com category to its Magento counterpart decides whether a transfer creates or updates. Where no link exists, a new Magento category is created — including where an identically named category already exists in the store, which is why a first run against a store with an existing tree can produce parallel categories.
Unmapped field overwrite risk
When a category is re-transferred, the fields this collection maps are written again over the existing Magento category. The fields at risk are ParentId, Name, IsActive and Position. Values edited directly in the Magento admin on any of those will be replaced — notably, a category disabled by hand in Magento is re-enabled on the next transfer, because the active state is sent as a fixed value.
The integration provides no guarantee that unmapped or blank fields are preserved on a category 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 category this collection transfers.
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 this collection does not map.
Supported Child Collections
None. This is a standalone collection with no parent and no children. It writes a single Magento category per record and has no subordinate data to contribute.
System Caveats
Adobe Commerce/Magento 2 Caveats
A category's parent must exist before the child transfers. Magento places a category beneath the parent identified in the payload. If the parent has not yet been transferred, the child is created at the catalog root instead, and no error is raised.
Categories are not deduplicated by name. Magento permits identically named categories in different places in the tree, so a first run against a store with an existing category structure can create parallel categories alongside the ones already there.
A category cannot be removed by this transfer. Magento categories are removed only in the Magento admin.
Category writes are subject to Magento's API limits. Large initial tree loads 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 parent category's external-ID record must be intact. Parent placement is resolved from the record linking the iPaaS.com parent category to its Magento counterpart. If that link is missing, the category is placed at the catalog root.
The Sort Order custom field must hold a whole number. A missing, empty, or non-numeric value falls back to a position of 0 without raising an error.
A category with no name cannot be written. Magento rejects a category created without a name, and the failure appears under Dashboard / Integration Monitoring / Error Logs.
Integration-Specific Caveats
Every transferred category arrives enabled. The active state is a fixed value rather than a mapped one, so a category that should arrive disabled cannot be expressed through the shipped mapping. Disabling must be done in the Magento admin, and will be undone by the next transfer of that category.
There is no back-fill of pre-existing Magento categories. Categories that existed before the integration was installed are not linked to iPaaS.com product categories automatically.
Silent fallbacks are the norm here. An unresolvable parent and a missing sort order both fall back to a default rather than raising an error, so neither is visible in the Error Logs. Both are detected only by reviewing the resulting category tree.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Note the catalog root category identifier the store uses, if it differs from the standard default.
Decide whether any categories already in the store should be reused rather than duplicated, since the transfer will not match them by name.
iPaaS.com Configuration
Create the Sort Order custom field on product category records where display ordering matters.
Confirm each category carries the IsSharedCatalog flag intended for it, and that the flag holds only an empty, true, or false value — any other value is skipped by this collection and by the Shared Catalog collection alike.
Transfer parent categories before their children, so the tree is built top-down.
Enable the outbound flow for Adobe Commerce/Magento 2 categories 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
The iPaaS.com product category record is picked up by the outbound flow or a Manual Sync, and evaluated against this collection's mapping filter. A record flagged as a shared catalog does not pass and is handled by the Shared Catalog collection instead.
The category's parent is resolved: the parent recorded on the iPaaS.com category is looked up to find the Magento category iPaaS.com previously created for it. If no Magento counterpart exists yet, the catalog root is used instead.
The category payload is built with the resolved parent, the name, the fixed active flag, and the display position.
The category is created or updated in Adobe Commerce/Magento 2, and iPaaS.com records the link between the two.
Mappings
Add/Update Adobe Commerce/Magento 2 Product Category FROM iPaaS.com
iPaaS.com data type: Product Category
Mapping Filter
var IsSharedCatalog = GetCustomFieldValue(CustomFields, "IsSharedCatalog");
if(IsSharedCatalog == null || IsSharedCatalog.ToString().ToLower() == "false")
return true;
return false;This collection processes a record only when it is not flagged as a shared catalog. The filter reads the IsSharedCatalog custom field on the iPaaS.com product category and takes two branches:
The record passes when the field is absent, or when its value reads as false in any casing. These are ordinary product categories, and they are written to Magento as categories.
The record is skipped in every other case — including when the value reads as true, which is the branch the Shared Catalog collection picks up.
A skipped record raises no error. Note that the two collections' conditions are complements only across empty, true and false: a record whose flag holds some other value satisfies neither filter and is processed by neither collection, silently. See Duplicate or Conflicting Mappings above.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Dynamic Formula |
| ParentId | Required. Determines where the category sits in the Magento tree. Resolves the iPaaS.com parent category to the Magento category previously created for it. Placeholder value — replace during implementation: the fallback 2 is the catalog root of a standard Magento installation; replace it if the store's root identifier differs. A category whose parent has not yet transferred is created at that root, silently. |
Field | Name | Name | Required. The category name shown in the Magento admin and on the storefront. Magento rejects a category created without a name, and the transfer for that record fails. |
Static |
| IsActive | Recommended. Enables the category in the Magento catalog as soon as it arrives. Because this is a fixed value, every category transferred arrives enabled regardless of any state held in iPaaS.com, and a category disabled by hand in Magento is re-enabled on the next transfer. |
Dynamic Formula |
| Position | Optional. The display order among sibling categories under the same parent, read from the Sort Order custom field. Falls back to 0 when the field is absent, empty, or not a whole number. |
Field | SharedCatalogIds | SharedCatalogIds | Optional. Carries the Adobe Commerce B2B shared catalogs the category belongs to. Applies only to stores running Adobe Commerce B2B; leave it unmapped on a store without shared catalogs. |
Dynamic Formula |
| StoreId_Catalog | Optional. Resolves the Magento store view the category should be scoped to, but only for categories that carry shared catalog ids — every other category returns no value and is created in the default scope. Placeholder value — replace during implementation: the store view name B2B Store View is an example; replace it with the store view your own B2B catalog uses. A name that does not match a store view in Magento resolves to no value, silently. |
Configuration Examples
The StoreId_Catalog mapping ships with three alternative implementations retained alongside the active one but commented out, so they do not run as delivered. They are recorded here rather than in the field mapping table above.
The first alternative adds validation, raising an error rather than returning no value when the store view name does not resolve:
var sharedCatalogIds = GetCustomFieldValue(CustomFields, "Shared Catalog Ids");
if(!string.IsNullOrWhiteSpace(sharedCatalogIds)){
var storeId = await GetStoreIdByName("B2B Store View");
if(storeId <= 0)
throw new Exception("Invalid OR Default Store Name is provided through mappings");
return storeId;
}
return null;The second resolves the store view for every category, without first checking for shared catalog ids:
return await GetStoreIdByName("B2B Store View");The third combines that unconditional resolution with the validation:
var storeId = await GetStoreIdByName("B2B Store View");
if(storeId <= 0)
throw new Exception("Invalid OR Default Store Name is provided through mappings");
return storeId;Subscribers or their MiSP who want a mis-typed or missing store view name to surface as a reported error rather than resolving silently to no value should adopt one of the validating forms. Whichever form is used, the store view name is a placeholder to replace with the store's own.
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 this transfer are:
A category rejected for a missing name. The iPaaS.com category has no name. Resolution: populate the name and re-run.
A category created at the catalog root instead of beneath its parent. The parent had not transferred when the child was processed. This raises no error. Resolution: transfer the parent, then re-transfer the child.
A duplicate category alongside an existing one. No external-ID link existed, so a new Magento category was created rather than the existing one being reused. Resolution: remove the duplicate in the Magento admin and re-run once the link is established.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
Create a top-level category in iPaaS.com and confirm it arrives in Magento at the expected point in the tree, enabled.
Manually sync using the iPaaS.com product category record identifier and confirm it resolves; confirm the category name does not.
Create a child category whose parent has already transferred, and confirm it is placed beneath that parent.
Create a child category whose parent has not transferred, and confirm it is created at the catalog root with no error raised.
Populate Sort Order on several sibling categories and confirm their display order in Magento matches.
Omit Sort Order, or set it to a non-numeric value, and confirm the position falls back to 0 without an error.
Rename a category in iPaaS.com and confirm the same Magento category is updated rather than a second one created.
Disable a category by hand in the Magento admin, re-transfer it, and confirm it is re-enabled.
Flag a category with IsSharedCatalog = true and confirm it is written only as a Shared Catalog, not also as an ordinary category. Then set the flag to an unrecognised value and confirm the category is skipped by both collections with no error.
Run against a store that already has a category tree and confirm whether parallel categories are created.
Validation Checklist
The catalog root fallback identifier matches the store's own root.
Categories are transferred parent-first, so the tree is built top-down.
The Sort Order custom field exists and is populated where display ordering matters.
The IsSharedCatalog flag holds only empty, true, or false values across the catalog, so no category falls between this collection's filter and the Shared Catalog collection's.
The resulting Magento tree has been reviewed after the first run, since parent and sort-order fallbacks are silent.
Additional Notes
This collection creates the categories that the product families later assign products to, so it normally runs before them.
Both of this collection's fallbacks are silent. An unresolvable parent and a missing sort order each produce a default value rather than an error, so neither appears in the Error Logs and both are found only by inspecting the resulting tree.
Validate dynamic formulas and filter changes in a staging environment before enabling automatic transfers in production.