BigCommerce B2B Edition companies, company addresses, company hierarchy, and company users transfer into iPaaS.com. A B2B company is captured as a Company record carrying its identity and B2B attributes; its addresses, its parent/subsidiary hierarchy, and its company users are captured alongside it. The individual buyers who belong to a company — the company users — are captured as Customer records, and the tie between a company and its users is modeled as a relationship between a Company and a Customer. Transfers run from scheduled polling or subscribed triggers, or on demand from the iPaaS.com Manual Sync page.

This article is the field-level companion to BigCommerce B2B Edition Support, which covers the higher-level picture — what B2B Edition is, how to turn it on, and how automatic transfer is set up. B2B handling is off by default and only applies when B2B support is enabled on the subscription. Writing iPaaS.com companies and company users back to BigCommerce is covered by the companion iPaaS.com to BigCommerce B2B Company and Customer Mapping Documentation. Standard (non-B2B) customers are handled by a separate set of collections — see the Related Documents footer. Only one of the standard (B2C) or B2B mappings should apply to any given customer.

This article documents the following mapping collections and the iPaaS.com data type each one operates on. Every collection here transfers BigCommerce to iPaaS.com.

In BigCommerce B2B Edition, a company relates to other companies as departments or subsidiaries, and to its users. In iPaaS.com those ties are modeled as relationships: company-to-company links form the hierarchy, and company-to-user links connect a company to its buyers. The company-to-user tie is a relationship between a Company and a Customer — not the Employee data type.

Manual Sync IDs differ by collection because each collection acts on a different record. Addresses and relationships transferred as part of a company or a customer have no independent Manual Sync entry point; sync the parent and its children transfer together.

After a successful transfer, iPaaS.com records the BigCommerce identifier as the external ID on a dedicated external-ID record for the transferred record:

The external-ID record is the primary match that routes later transfers of the same record to an update rather than creating a duplicate.

Inbound record delete is not supported for these collections. Deleting a company, address, relationship, or company user in BigCommerce does not propagate the deletion to iPaaS.com; remove records manually in each system as needed.

BigCommerce does not expose custom fields for the company, company address, or customer data types. The integration populates several iPaaS.com custom fields inbound to carry B2B-specific values and to route records; none require manual creation for the default templates, and the ones that route records add no mapped data.

Values written to the iPaaS.com Company and its relationships:

Values written to the iPaaS.com Customer to identify and route a B2B user:

All collections in this article ship Enabled. Trigger events:

Whether a given event drives an Add or an Update depends on whether the record is already linked to iPaaS.com by an external ID. Automatic transfers do not run until the corresponding poll events or triggers are configured — see Setup Requirements.

Several collections operate on the same underlying records. Review their filters and Add/Update settings before enabling them, and decide which collection is the source of truth for each record.

The integration decides whether an incoming B2B record is new or one it already knows about so updates land on the right record instead of creating duplicates:

When a match is found, the record is treated as the same record and the configured collision method for that data type decides the outcome. The selectable methods are:

Review the collision method for the Company and Customer data types so records merge with, or stay separate from, existing records as your workflow expects. A company without a name, or a company user without an email, cannot be matched reliably.

The Company and Customer collections drive their related records through child collections that transfer as part of the parent:

The company-to-user relationship is carried through the Company Relationship and Customer Relationship child collections. The company-to-company hierarchy (parent/subsidiary) is carried on the Company record itself.

Automatic transfers do not run until the corresponding poll events or triggers are configured. All of the setup below is done on the Subscriber Dashboard; see the BigCommerce Installation Instructions for the step-by-step screens.

Company and its children:

Company user:

Each collection below lists its Mapping Filter (when the collection has one), the iPaaS.com data type it operates on, and its field mapping table. Source and destination field names are shown as they appear in each system. Where an Add and an Update collection are near-identical, they are presented together with any differences noted.

iPaaS.com data type: Company

Both collections capture a BigCommerce B2B company into an iPaaS.com Company: Add handles new companies; Update handles changes to a company that already exists in iPaaS.com. Neither collection has a mapping filter, so all companies passed to them are processed.

The Add collection maps the company's core identity and B2B attributes directly from BigCommerce. The Update collection maps the same B2B attributes, and for the core identity fields (name, email, phone, and several others) it carries the existing iPaaS.com value forward rather than overwriting it — so an inbound update does not blank iPaaS.com-owned values. The tables below show the shared B2B-attribute fields, then the direction-specific identity fields.

Shared fields (Add and Update):

Lookup Translation Tables

The B2B Company Status mapping resolves the BigCommerce status through the BC B2B Company Status To iPaaS lookup translation. These are subscriber-configurable defaults — review and customize them so BigCommerce company statuses map to the iPaaS.com statuses your workflow expects.

Add — identity fields:

Update — identity fields (each carries the existing iPaaS.com value forward):

iPaaS.com data type: Company Address

These are child collections of the company transfer. Each address is linked to the parent Company and transferred as part of the company; there is no independent sync. Neither collection has a mapping filter, so every address on a transferred company is processed. The Add and Update field tables are identical.

iPaaS.com data type: Company Relationship

These are child collections of the company transfer. They link the company to its B2B users — one relationship per user — and carry the user's B2B role. There is no independent sync, and neither collection has a mapping filter. The Add and Update field tables are identical. Each related user is transferred as a prerequisite Customer.

Type formula (maps the BigCommerce B2B role to the relationship type):

iPaaS.com data type: Customer

Both collections capture a BigCommerce B2B company user into an iPaaS.com Customer: Add handles new users; Update handles changes to a user that already exists in iPaaS.com. The two share the same filter and the same core fields; the Update collection additionally preserves the customer number, company, and comment from the existing iPaaS.com record.

Mapping Filter

Filter Description. A customer is processed here only when it carries a BigCommerce B2B user identifier (B2B_UserIdFromB2B is not null) — that is, only when it is a B2B company user. This is the exact inverse of the standard (non-B2B) Customer collections, which process customers whose B2B user identifier is null. The two filters route each customer to exactly one path. This filter references a custom-field value rather than an environment-specific value, so no placeholder substitution is required.

Shared fields (Add and Update):

Add — customer number:

Update — preserved fields (carried forward from the existing iPaaS.com record):

iPaaS.com data type: Customer Relationship

These are child collections of the company user transfer. They link the B2B user (a Customer) to the company it belongs to, and carry the user's B2B role. The link is modeled as a relationship between a Customer and a Company — not the Employee data type. There is no independent sync, and neither collection has a mapping filter. The Add and Update field tables are identical.

Type formula (maps the parent user's BigCommerce B2B role to the relationship type):