Summary
B2B companies are written from iPaaS.com into Adobe Commerce/Magento 2. Each iPaaS.com Company becomes one Magento company carrying the company name and email address, its legal registration details, its billing address, the customer group that governs the pricing and tax rules it sees, and the company administrator — the super user — who owns the company account in the storefront.
Trade accounts maintained in iPaaS.com therefore appear as fully formed companies in the storefront, so buyers belonging to those companies can transact under the right pricing and account structure.
This collection applies only to stores licensed for and running the Adobe Commerce B2B module. On a store without B2B, leave it disabled.
ID Format
Manual Sync ID Format
Enter the iPaaS.com Company record identifier — the internal numeric identifier of the company in iPaaS.com, for example 20514.
The company name is not accepted as a Manual Sync value.
External ID Format
After a successful transfer, iPaaS.com stores the Adobe Commerce/Magento 2 company identifier as the external ID on a record linking the iPaaS.com Company to the Magento company. That record routes later transfers of the same company to the existing Magento company for an update rather than creating a duplicate, and it is what the customer transfer reads when it assigns a customer to a company by relationship.
Deleted Record Support
Outbound delete is not supported for companies. A company 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.
Removing a customer from a company is likewise not something the integration can do; that change must be made in the Magento admin.
Custom Field Support
This collection reads no custom fields directly. Its address values are read from the iPaaS.com company's primary billing address, and its legal name and reseller id come from named source values on the company record.
The related customer transfer does read custom fields for its company assignment; see the Customer FROM iPaaS.com documentation.
Mapping Collection Status
Status: Enabled. This collection ships enabled.
Trigger Events: Creation or update of a Company 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 companies are sent automatically. Manual Sync is always available regardless.
Duplicate or Conflicting Mappings
No other collection creates Magento companies, so there is no competing collection to reconcile filters with. There are, however, ordering dependencies in both directions:
Add/Update Adobe Commerce/Magento 2 Customer FROM iPaaS.com must have run for the intended super user, because a company cannot be created without a Magento customer to act as its administrator. That same customer transfer also assigns customers to companies, resolving the company either by relationship or by name — so companies must exist before those customers transfer.
Add/Update Adobe Commerce/Magento 2 Customer Category FROM iPaaS.com creates the customer groups a company can be assigned to.
Add/Update Adobe Commerce/Magento 2 Shared Catalog FROM iPaaS.com creates the Shared Catalogs that grant a company tailored catalog access. Catalog membership is granted in the Magento admin, not by the integration.
The practical sequence is: customer categories, then the super-user customers, then companies, then the remaining customers.
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 Company to its Magento company decides whether a transfer creates or updates.
The filter also enforces a one-to-one constraint on the super user: a customer who already administers another Magento company cannot be used again.
Unmapped field overwrite risk
Mapped fields that carry a value overwrite the matching values on the Magento company on every transfer, including values changed by hand in the Magento admin. The fields at risk are Status, CompanyName, CompanyEmail, Street, City, CountryId, RegionId, Region, Postcode, Telephone, CustomerGroupId, SuperUserId, LegalName, VatTaxId and ResellerId.
The integration provides no guarantee that unmapped or blank fields are preserved on a company 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 region and customer group values described below — set a DestinationValue on that mapping, or repoint the mapping at a source that carries the real value.
Supported Child Collections
None. This is a standalone collection with no parent and no children. It writes a single Magento company per record and has no subordinate data to contribute.
System Caveats
Adobe Commerce/Magento 2 Caveats
Adobe Commerce B2B is required. Companies are a B2B feature. On a store without the module this collection has nothing to write to.
A company must have a super user. Magento requires a customer to act as the company administrator, and that customer must exist in Magento before the company is created.
A customer can administer only one company. Magento will not accept a super user already linked to another company.
The customer group must already exist. It is assigned by numeric identifier.
The region is validated against the country. A region that is not valid for the country supplied is rejected.
Company writes are subject to Magento's API limits. Stagger large manual catch-up runs rather than issuing them concurrently.
iPaaS.com Caveats
The company email address is required. The filter stops the transfer when it is missing.
The super user must be resolvable and unused. The filter stops the transfer when the super user does not exist in iPaaS.com or is already linked to another Magento company.
The address comes from the primary billing address. Street, city, country, postcode and telephone are all read from the first address on the iPaaS.com company flagged as primary billing. A company with no primary billing address transfers without those values.
The region resolves from the primary billing address too, and is validated against that address's country.
Integration-Specific Caveats
Two address values are fixed rather than read from the company. The region identifier and the customer group are static values, so every company transferred receives the same ones. See Placeholder values below.
The status is a designed constant. Every company arrives approved and active. A company that should arrive in another state cannot be expressed through the shipped mapping.
Catalog access and membership are not managed here. This collection creates the company; granting it a Shared Catalog, and adding customers to it, are done separately.
Placeholder values
Two of this collection's fifteen mappings send fixed values that are environment-specific.
Placeholder value — replace during implementation:
RegionId ships as a fixed numeric region identifier from the environment the template was built in. Because the collection also resolves a Region code from the company's primary billing address, the fixed identifier and the resolved code can disagree. Replace the fixed identifier with the store's own, or drive it from the company's address so the two agree.
CustomerGroupId ships as a fixed numeric customer group identifier, so every company is assigned to the same group. Replace it with the group the companies should belong to, or drive it from the iPaaS.com record where different companies need different groups.
The Status static is a designed constant rather than a placeholder — leave it unless companies should arrive in a different state.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Confirm the Adobe Commerce B2B module is licensed and enabled.
Create the customer groups companies should be assigned to, and note their numeric identifiers.
Confirm the region identifiers for the regions companies will be located in.
iPaaS.com Configuration
Ensure every Company record has an email address and a primary billing address.
Ensure the intended super user exists as an iPaaS.com customer, has already transferred to Magento, and is not already administering another Magento company.
Replace the fixed region identifier and customer group identifier, or drive them from the iPaaS.com record.
Transfer customer categories and the super-user customers before companies, and the remaining customers after.
Enable the outbound flow for Adobe Commerce/Magento 2 companies 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 Company record is created or updated in iPaaS.com, or a Manual Sync is run against one.
The company is evaluated against the mapping filter, which requires an email address and a valid, unused super user. Failing either stops the transfer with an explicit message.
The company's primary billing address is read, and its street, city, country, postcode, telephone and region are resolved from it.
The super user is resolved to the Magento customer who will administer the company.
The company is created or updated in Adobe Commerce/Magento 2 with an approved status and the assigned customer group, and iPaaS.com records the link between the two.
Customers belonging to that company are then assigned to it by the customer transfer, which resolves the company by relationship or by name.
Mappings
Add/Update Adobe Commerce/Magento 2 Company FROM iPaaS.com
iPaaS.com data type: Company
Mapping Filter
if (string.IsNullOrEmpty(EmailAddress)){
throw new exception("Required: Email Address");
}
else{
bool isSuperUserValid= await IsValidSuperUserId(Id);
if(!isSuperUserValid){
throw new exception("Super User does not exist in iPaaS or is already linked to another company in Magento.");
}
return true;
}This filter enforces the two conditions Magento requires before a company can be created, and reports each in subscriber terms rather than letting the store return its own error.
When the company has no email address, it stops the transfer with:
"Required: Email Address"
When the super user cannot be resolved in iPaaS.com, or is already administering another Magento company, it stops the transfer with:
"Super User does not exist in iPaaS or is already linked to another company in Magento."
Otherwise the company passes and is written.
Search the Error Logs for either message to find affected companies. The remedies are to populate the company email address, and to nominate a super user who exists in iPaaS.com and is not already linked to another Magento company.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Field | Name | CompanyName | Required. The company name shown in the storefront and the Magento admin. |
Field | EmailAddress | CompanyEmail | Required. The company email address. The filter stops the transfer when it is missing. |
Static |
| Status | Required by design. Every company arrives approved and active in Adobe Commerce B2B. This is a designed constant rather than a placeholder. |
Dynamic Formula |
| SuperUserId | Required. Resolves the Magento customer who administers the company. That customer must already exist in Magento and must not already administer another company. |
Dynamic Formula |
| Street | Required. Builds the company street address from the three address lines on the company's primary billing address. |
Dynamic Formula |
| City | Required. The city from the company's primary billing address. |
Dynamic Formula |
| CountryId | Required. Resolves the two-letter country code from the country on the company's primary billing address. |
Dynamic Formula |
| Postcode | Required. The postal code from the company's primary billing address. |
Dynamic Formula |
| Telephone | Required. The telephone number from the company's primary billing address. |
Static |
| CustomerGroupId | Required. The customer group governing the pricing and tax rules the company sees. Placeholder value — replace during implementation: the identifier is fixed, so every company is assigned to the same group. Replace it with the store's own, or drive it from the iPaaS.com record where companies need different groups. |
Dynamic Formula |
| Region | Optional. Resolves the region code from the region and country on the company's primary billing address, validating the region against that country. |
Static |
| RegionId | Optional. The numeric region identifier. Placeholder value — replace during implementation: the identifier is fixed and environment-specific, so every company receives the same one — and it can disagree with the Region code resolved from the company's own address. Replace it with the store's own, or drive it from the address so the two agree. |
Field | TaxIdNumber | VatTaxId | Optional. The company's VAT or tax registration number. |
Field | legal_name | LegalName | Optional. The company's registered legal entity name, where it differs from its trading name. |
Field | reseller_id | ResellerId | Optional. The company's reseller or resale registration reference. |
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:
Error message: Required: Email Address. The iPaaS.com Company has no email address. Resolution: populate it and re-transfer.
Error message: Super User does not exist in iPaaS or is already linked to another company in Magento. The nominated super user cannot be resolved, or already administers another company. Resolution: confirm the customer exists and has transferred to Magento, and nominate a different super user if the intended one is already in use.
The company prerequisite could not be created. A dependency of the company could not be established. Resolution: confirm the super user and customer group exist, then re-run.
A company rejected for an invalid region. The fixed region identifier is not valid for the country resolved from the address. Resolution: replace the fixed region identifier, or drive it from the address.
A company that arrives without its address. The iPaaS.com Company has no address flagged as primary billing. Resolution: flag one and re-transfer.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
Create a Company in iPaaS.com with an email address, a primary billing address, and a super user who has already transferred, and confirm a Magento company is created.
Manually sync using the iPaaS.com Company record identifier and confirm it resolves; confirm the company name does not.
Remove the company email address and confirm the transfer stops with the documented message.
Nominate a super user who is already administering another Magento company and confirm the transfer stops with the documented message.
Nominate a super user who has not yet transferred to Magento and confirm the same.
Confirm the street, city, country, postcode and telephone all come from the primary billing address.
Remove the primary billing flag from every address and confirm the company transfers without those values.
Confirm the company is assigned to the intended customer group, after the fixed identifier has been replaced.
Confirm the region identifier and the resolved region code agree, after the fixed identifier has been replaced.
Update the company in iPaaS.com and confirm the same Magento company is updated rather than a duplicate created.
Transfer a customer with a company relationship and confirm the customer is assigned to the company created here.
Validation Checklist
The Adobe Commerce B2B module is licensed and enabled.
Every Company record has an email address and a primary billing address.
Super users exist in iPaaS.com, have transferred to Magento, and are not already administering another company.
The fixed customer group identifier has been replaced with the store's own.
The fixed region identifier has been replaced, and agrees with the region resolved from each company's address.
Customer categories and super-user customers have been transferred before companies.
Additional Notes
The transfer order matters more here than in most families: customer categories, then super-user customers, then companies, then the remaining customers.
The filter deliberately stops the transfer rather than skipping the record. Both of its messages name the problem and the fix directly, which is more actionable than the equivalent Magento API error.
Two fixed values — the region identifier and the customer group — mean every company receives the same ones as delivered. Replacing them is a required implementation step.
Catalog access is not granted here. Assigning a Shared Catalog to a company is done in the Magento admin.
Validate the super-user constraint and the address resolution in a staging environment before enabling automatic transfers in production.