Summary
Customer categories are written from iPaaS.com into Adobe Commerce/Magento 2 as customer groups. Each iPaaS.com Customer Category becomes one Magento customer group carrying the group code, the tax class that governs how tax is calculated for its members, and the list of websites the group is excluded from.
The customer segments maintained in iPaaS.com therefore exist as customer groups in the storefront, so customers and B2B companies can be assigned to them and receive the correct pricing and tax treatment.
This collection creates the groups that the customer transfer later assigns customers to, so it normally runs before the customer families.
ID Format
Manual Sync ID Format
Enter the iPaaS.com Customer Category record identifier — the internal numeric identifier of the customer category in iPaaS.com, for example 10001.
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 customer group identifier as the external ID on a record linking the iPaaS.com Customer Category to the Magento group. That record routes later transfers of the same category to the existing group for an update rather than creating a second one.
Deleted Record Support
Outbound delete is not supported for customer categories. A category removed in iPaaS.com is not removed from Adobe Commerce/Magento 2, and delete mappings are not included in the default templates for this collection.
Custom Field Support
This collection reads no custom fields. Every value comes from a standard field on the iPaaS.com Customer Category or is resolved by formula.
Mapping Collection Status
Status: Enabled. This collection ships enabled and processes every iPaaS.com Customer Category record.
Trigger Events: Creation or update of a Customer Category record 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 customer categories are sent automatically. Manual Sync is always available regardless.
Duplicate or Conflicting Mappings
No other collection creates Magento customer groups, so there is no competing collection to reconcile filters with. There are, however, two dependencies:
Add/Update Adobe Commerce/Magento 2 Customer FROM iPaaS.com assigns a customer to a Magento customer group by resolving the customer's first iPaaS.com category by name. The groups this collection creates are what that resolution matches against, so this collection normally runs first.
Add/Update Adobe Commerce/Magento 2 Company FROM iPaaS.com assigns a B2B company to a customer group by its numeric identifier.
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 Customer Category to its Magento group decides whether a transfer creates or updates.
Because the group is identified in Magento by its code, changing the category name in iPaaS.com after the group exists creates a new group rather than renaming the existing one.
Unmapped field overwrite risk
When a customer category is re-transferred, the fields this collection maps are written again over the existing Magento customer group. The fields at risk are Code, TaxClassId and ExcludeWebsiteIds.
The integration provides no guarantee that unmapped or blank fields are preserved on a group 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 group this collection transfers.
The mitigation is a DestinationValue. Where a Magento field must hold a specific value that iPaaS.com does not supply, set a DestinationValue on that mapping so the integration writes the value chosen there instead of taking it from the source.
Supported Child Collections
None. This is a standalone collection with no parent and no children. It writes a single Magento customer group per record and has no subordinate data to contribute.
System Caveats
Adobe Commerce/Magento 2 Caveats
The tax class must already exist in Magento. It is resolved by name; the integration does not create tax classes.
Excluded websites must already exist in Magento. They are resolved by name.
A group code cannot be changed in place through this transfer. Renaming the source category produces an additional group rather than updating the existing one.
Customer group writes are subject to Magento's API limits. Stagger large manual catch-up runs rather than issuing them concurrently.
iPaaS.com Caveats
The category name becomes the group code. It must be acceptable to Magento as a group code, and it is what the customer transfer's group resolution later matches on.
Unmatched lookups resolve silently. A tax class name or excluded website name that does not match anything in Magento produces no error, so a group can transfer successfully without the tax class or website exclusion that was expected.
Integration-Specific Caveats
The tax class and excluded website are fixed example values. Both are resolved by name from values written into the formulas rather than read from the iPaaS.com Customer Category, so every group transferred by this collection receives the same tax class and the same website exclusion. See Placeholder values below.
This collection creates groups, not memberships. Assigning a customer to a group is done by the customer transfer; assigning a company to one is done by the company transfer.
Placeholder values
Two of this collection's three mappings resolve fixed names written into the formula rather than reading the iPaaS.com record.
Placeholder value — replace during implementation:
The TaxClassId mapping resolves a tax class by a fixed name. Replace that name with the tax class each group should actually receive. Because the name is fixed in the formula, every group gets the same tax class as delivered — a store that needs different tax classes per group must either drive the name from a field on the iPaaS.com Customer Category or use separate mapping collections with distinct filters.
The ExcludeWebsiteIds mapping resolves a fixed website name. Replace it with the websites each group should be excluded from, or remove the mapping where no exclusion applies.
Neither lookup raises an error when the name does not match, so an unreplaced placeholder is invisible in the Error Logs and shows up only as a group with no tax class or no exclusion.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Create the tax classes the customer groups should use, and note their exact names.
Confirm the names of any websites groups should be excluded from.
iPaaS.com Configuration
Confirm each Customer Category name is acceptable as a Magento customer group code.
Replace the fixed tax class name and excluded website name in the two formulas.
Where different groups need different tax classes, drive the name from the iPaaS.com record or use separate mapping collections.
Transfer customer categories before customers, so the customer transfer's group resolution finds a match.
Enable the outbound flow for Adobe Commerce/Magento 2 customer 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 Customer Category record is created or updated in iPaaS.com, or a Manual Sync is run against one.
The category is processed by this collection. It carries no filter, so every category record is processed.
The category name is written as the Magento customer group code.
The tax class is resolved by name and assigned to the group.
The excluded websites are resolved by name and applied to the group.
The customer group 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 Customer Category FROM iPaaS.com
iPaaS.com data type: Customer Category
This collection carries no mapping filter — every iPaaS.com Customer Category record is processed.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Field | Name | Code | Required. The Magento customer group code, taken from the category name. This is the value the customer transfer's group resolution matches on, and changing it after the group exists creates a new group rather than renaming the existing one. |
Dynamic Formula |
| TaxClassId | Required. The tax class governing how tax is calculated for members of the group, resolved by name. Placeholder value — replace during implementation: the tax class name is fixed in the formula, so every group receives the same one. Replace it with the tax class the groups should use, and drive it from the iPaaS.com record where different groups need different classes. An unmatched name resolves silently to no tax class. |
Dynamic Formula |
| ExcludeWebsiteIds | Optional. The Magento websites the group is excluded from, resolved by name. Placeholder value — replace during implementation: the website name is an example. Replace it with the store's own, or remove the mapping where no exclusion applies. An unmatched name resolves silently to no exclusion. |
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 group that arrives without a tax class. The tax class name in the formula does not match a tax class in Magento. This raises no error. Resolution: correct the name to match the store's tax class.
A group that arrives without its website exclusion. The website name does not match. This raises no error. Resolution: correct the name, or remove the mapping.
A duplicate group alongside an existing one. The category name changed in iPaaS.com after the group was created. Resolution: remove the unwanted group in the Magento admin and settle on a stable code.
A customer that transfers without its group. The customer transfer resolves the group by name and found no match. Resolution: confirm this collection has run and that the group code matches the customer's category name.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
Create a Customer Category in iPaaS.com and confirm a Magento customer group is created with the expected code.
Manually sync using the iPaaS.com Customer Category record identifier and confirm it resolves; confirm the category name does not.
Confirm the group receives the intended tax class, after the placeholder name has been replaced.
Set a tax class name that does not exist in Magento and confirm the group transfers with no tax class and no error.
Confirm the website exclusion is applied, after the placeholder name has been replaced.
Update the category description or other fields in iPaaS.com and confirm the same Magento group is updated rather than a second one created.
Rename the category in iPaaS.com and confirm a new group is created rather than the existing one renamed.
Transfer a customer whose category matches a group created here, and confirm the customer is assigned to that group.
Validation Checklist
The fixed tax class name has been replaced with the store's own, and the tax class exists in Magento.
The fixed excluded website name has been replaced or the mapping removed.
Where different groups need different tax classes, the name is driven from the iPaaS.com record rather than fixed.
Customer category names are stable and acceptable as Magento group codes.
Customer categories have been transferred before customers.
Additional Notes
This collection creates the groups the customer and company transfers later assign records to, so it normally runs first.
Both of its lookups fail silently. An unreplaced placeholder produces a group with no tax class or no exclusion and no entry in the Error Logs, so verify the result in the Magento admin after the first run.
Group codes are effectively immutable through this transfer: rename the source and you get a second group.
Validate the tax class and website resolution in a staging environment before enabling automatic transfers in production.