Summary
Shared Catalogs are created in Adobe Commerce/Magento 2 from iPaaS.com product category records that are flagged as shared catalogs. Each one carries the catalog's name and description, the catalog type, the store view it belongs to, and the tax class applied to it.
A Shared Catalog is an Adobe Commerce B2B feature that controls which products a company can see and what pricing it receives. Catalog structures maintained in iPaaS.com therefore become Shared Catalogs in the storefront, so B2B companies can be granted tailored catalog access.
This collection applies only to stores licensed for and running the Adobe Commerce B2B module. On a store without B2B, leave it disabled.
It creates the catalog only. Product membership and company access are managed in the Magento admin.
ID Format
Manual Sync ID Format
Enter the iPaaS.com Product Category record identifier of the category flagged as a shared catalog — the internal numeric identifier in iPaaS.com, for example 4108.
The catalog name is not accepted as a Manual Sync value.
External ID Format
After a successful transfer, iPaaS.com stores the Adobe Commerce/Magento 2 Shared Catalog identifier as the external ID on a record linking the iPaaS.com product category to the Magento catalog. That record routes later transfers of the same category to the existing catalog for an update rather than creating a second one.
Deleted Record Support
Outbound delete is not supported for Shared Catalogs. A category removed in iPaaS.com does not remove the corresponding Magento Shared Catalog, and delete mappings are not included in the default templates for this collection.
Custom Field Support
This collection reads one iPaaS.com custom field on the product category record:
IsSharedCatalog: the flag that routes a category to this collection rather than to the ordinary product category collection. A value of true is processed here.
Mapping Collection Status
Status: Enabled. This collection ships enabled.
Trigger Events: Creation or update of a Product Category record in iPaaS.com flagged as a shared catalog, plus Manual Sync on demand.
Automatic outbound transfers are enabled on the subscription's Outbound Data Flows page. Until that flow is enabled, no catalogs are sent automatically. Manual Sync is always available regardless.
Duplicate or Conflicting Mappings
Add/Update Adobe Commerce/Magento 2 Product Category FROM iPaaS.com reads the same kind of iPaaS.com product category record and writes it as an ordinary Magento category rather than a Shared Catalog.
The two collections divide the same records between them. This collection takes the categories where IsSharedCatalog is true; the product category collection takes those where the flag is absent or false. Because the two conditions are complements, a category is written once, as either a catalog or a category, and never as both.
One case falls outside both conditions. A record whose IsSharedCatalog value is neither empty nor a recognised true or false satisfies neither filter and is silently skipped by both collections. Confirm the flag holds only empty, true, or false values before enabling the outbound flow.
Add/Update Adobe Commerce/Magento 2 Company FROM iPaaS.com creates the B2B companies that a Shared Catalog is granted to. Granting the access itself is done in the Magento admin.
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 product category to its Magento Shared Catalog decides whether a transfer creates or updates.
Unmapped field overwrite risk
When a category is re-transferred, the fields this collection maps are written again over the existing Magento Shared Catalog. The fields at risk are Name, Description_Catalog, Type_Catalog, StoreId_Catalog and TaxClassId_Catalog.
Values edited directly in the Magento admin on any of those will be replaced. Product membership and company access, which this collection does not write, are unaffected.
The integration provides no guarantee that unmapped or blank fields are preserved on a catalog update. Subscribers or their MiSP should validate in a staging environment how fields left blank in iPaaS.com behave before relying on that behavior in production.
The mitigation is a DestinationValue. Where a Magento field must hold a specific value that iPaaS.com does not supply — which is the case for the fixed type and tax class values below — set a DestinationValue on that mapping, or repoint the mapping at a source carrying the real value.
Supported Child Collections
None. This is a standalone collection with no parent and no children. It writes a single Magento Shared Catalog per record and has no subordinate data to contribute.
System Caveats
Adobe Commerce/Magento 2 Caveats
Adobe Commerce B2B is required. Shared Catalogs are a B2B feature. On a store without the module this collection has nothing to write to.
The store view must already exist. It is resolved by name; the integration does not create store views.
The tax class must already exist. It is assigned by numeric identifier.
Product membership and company access are not created here. Which products a catalog contains, and which companies can see it, are set in the Magento admin.
Catalog writes are subject to Magento's API limits. Stagger large manual catch-up runs rather than issuing them concurrently.
iPaaS.com Caveats
The IsSharedCatalog flag routes the record. Only categories where it reads as true reach this collection.
An unmatched store name resolves silently. A store view name that does not match anything in Magento places the catalog under the global Admin store view rather than raising an error.
The catalog name is derived, not copied. A suffix is appended to the iPaaS.com category name, so the Magento catalog name will not match the source name exactly.
Integration-Specific Caveats
The catalog name carries an appended suffix. The Magento Shared Catalog is named for the iPaaS.com category with a suffix added, which distinguishes it from the ordinary category of the same name but means the two names differ.
The type and tax class are fixed values. Every catalog transferred receives the same ones. See Placeholder values below.
The store view name is fixed in the formula. Every catalog is placed in the same store view unless the formula is changed.
Placeholder values
Three of this collection's five mappings send or resolve fixed values rather than reading the iPaaS.com record.
Placeholder value — replace during implementation:
The StoreId_Catalog mapping resolves a store view by a fixed name. Replace it with the store view the B2B catalogs should belong to. An unmatched name does not raise an error — the catalog is placed under the global Admin store view instead, which is easy to miss.
TaxClassId_Catalog ships as a fixed numeric tax class identifier. Replace it with the tax class the catalogs should use.
Type_Catalog ships as a fixed catalog type. Confirm it is the intended type for the store's B2B configuration before the first transfer.
Configuration Examples
The StoreId_Catalog mapping ships with an alternative implementation retained alongside the active one but commented out, so it does not run as delivered. It is recorded here rather than in the field mapping table above.
The alternative resolves a different store view and adds validation, raising an error rather than falling back to the Admin store view when the name does not resolve:
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 silently placing the catalog under the Admin store view should adopt this validating form. Either way, the store view name is a placeholder to replace with the store's own.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Confirm the Adobe Commerce B2B module is licensed and enabled.
Create the store view the Shared Catalogs should belong to, and note its exact name.
Confirm the tax class identifier the catalogs should use.
iPaaS.com Configuration
Flag the product categories that should become Shared Catalogs with IsSharedCatalog set to true, and confirm the flag holds only empty, true, or false values across the catalog.
Replace the fixed store view name, tax class identifier, and catalog type.
Consider adopting the validating store-view form so an unmatched name is reported rather than silently defaulted.
Transfer companies so the catalogs can be granted to them in the Magento admin afterwards.
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
A Product Category record is created or updated in iPaaS.com, or a Manual Sync is run against one.
The record is evaluated against the mapping filter, which admits only categories whose IsSharedCatalog custom field reads as true. Ordinary categories do not pass and are handled by the product category collection instead.
The catalog name is derived from the category name with a suffix appended, and the description is carried across.
The store view is resolved by name, falling back to the global Admin store view where the name does not match.
The catalog type and tax class are supplied as fixed values.
The Shared Catalog is created or updated in Adobe Commerce/Magento 2, and iPaaS.com records the link between the two.
Product membership and company access are then granted in the Magento admin.
Mappings
Add/Update Adobe Commerce/Magento 2 Shared Catalog FROM iPaaS.com
iPaaS.com data type: Product Category
Mapping Filter
var IsSharedCatalog = GetCustomFieldValue(CustomFields, "IsSharedCatalog");
if(IsSharedCatalog != null && IsSharedCatalog.ToString().ToLower() == "true")
return true;
return false;This collection processes a record only when it is 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 present and its value reads as true in any casing.
The record is skipped in every other case — including when the field is absent or reads as false, which is the branch the ordinary product category 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.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Dynamic Formula |
| Name | Required. The Shared Catalog name, derived from the iPaaS.com category name with a suffix appended. The Magento name therefore differs from the source name, which distinguishes the catalog from an ordinary category of the same name. |
Static |
| Type_Catalog | Required. The Shared Catalog type. Placeholder value — replace during implementation: confirm this is the intended type for the store's B2B configuration before the first transfer. |
Dynamic Formula |
| StoreId_Catalog | Required. Resolves the store view the catalog belongs to, by name. Placeholder value — replace during implementation: the store view name is fixed in the formula, so every catalog is placed in the same one. An unmatched name places the catalog under the global Admin store view without raising an error. See Configuration Examples above for a validating alternative. |
Static |
| TaxClassId_Catalog | Required. The tax class applied to the catalog. Placeholder value — replace during implementation: the identifier is fixed and environment-specific. Replace it with the tax class the catalogs should use. |
Field | Description | Description_Catalog | Optional. The catalog description shown in the Magento admin. |
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 catalog that lands under the Admin store view. The store view name in the formula does not match a store view in Magento. This raises no error. Resolution: correct the name, or adopt the validating form so the mismatch is reported.
A catalog rejected for an invalid tax class. The fixed tax class identifier does not exist in the store. Resolution: replace it with a valid identifier.
A category that reaches neither collection. The IsSharedCatalog flag holds a value that is neither empty, true, nor false. Resolution: correct the flag value.
A catalog with no products or companies. Expected — this collection creates the catalog only. Resolution: grant product membership and company access in the Magento admin.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
Flag a product category with IsSharedCatalog set to true and confirm a Magento Shared Catalog is created rather than an ordinary category.
Manually sync using the iPaaS.com Product Category record identifier and confirm it resolves.
Confirm the Magento catalog name carries the appended suffix, and that this is acceptable to the business.
Confirm the catalog is placed in the intended store view, after the fixed name has been replaced.
Set a store view name that does not exist and confirm the catalog lands under the Admin store view with no error, so the behavior is understood before go-live.
Confirm the catalog receives the intended tax class and type, after the fixed identifiers have been replaced.
Set the flag to false and confirm the record is handled by the ordinary product category collection instead.
Set the flag to an unrecognised value and confirm the record is skipped by both collections with no error.
Update the category description in iPaaS.com and confirm the same Magento catalog is updated rather than a second one created.
Grant the catalog to a company in the Magento admin and confirm the company sees the intended products.
Validation Checklist
The Adobe Commerce B2B module is licensed and enabled.
The fixed store view name has been replaced, and the store view exists in Magento.
The fixed tax class identifier and catalog type have been replaced or confirmed.
The IsSharedCatalog flag holds only empty, true, or false values across the catalog.
The appended-suffix naming has been accepted by the business.
Product membership and company access have been granted in the Magento admin after the catalogs are created.
Additional Notes
This collection and the ordinary product category collection are complements. Between them they cover every category whose flag holds a recognised value; a category with an unrecognised flag value reaches neither.
The store view lookup fails silently by design in the shipped form, placing the catalog under the Admin store view. The commented alternative in Configuration Examples turns that into a reported error instead.
The integration creates the catalog shell only. Everything that makes a Shared Catalog useful — the products in it and the companies granted access — is configured in the Magento admin.
Validate the store view resolution and the fixed identifiers in a staging environment before enabling automatic transfers in production.
