iPaaS.com customers and their addresses write out to BigCommerce customers and addresses, and iPaaS.com customer categories write out to BigCommerce as customer groups. Outbound transfers run automatically from subscribed iPaaS.com triggers or on demand from the iPaaS.com Manual Sync page.

This article covers the standard (non-B2B) outbound customer collections. Customers, companies, and users belonging to BigCommerce B2B Edition are handled by a separate set of collections — see the Related Documents footer. Capturing BigCommerce customers and addresses into iPaaS.com is covered by the companion BigCommerce to iPaaS.com Customer Mapping Documentation. Only one of the B2C (standard) 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 iPaaS.com to BigCommerce.

Manual Sync IDs differ by collection because each collection acts on a different record. Enter the ID that matches the collection you are syncing.

Addresses written as part of a customer have no independent Manual Sync entry point; sync the parent customer and its addresses transfer together.

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

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

Outbound delete is not supported for these collections. Delete mappings are not included in the default templates, and deleting a customer, address, or category in iPaaS.com does not propagate the deletion to BigCommerce. Remove records manually in each system as needed.

BigCommerce does not expose custom fields for the customer, customer address, or customer group data types, and no iPaaS.com custom fields are created by default for these records. No custom-field configuration is required to run these collections.

Two iPaaS.com custom fields are read by filters — they route records rather than adding mapped data — and neither is created automatically:

All collections in this article ship Enabled. Trigger events:

Whether a given trigger drives an Add or an Update depends on whether the record is already linked to BigCommerce by an external ID. Automatic transfers do not run until the corresponding triggers are subscribed — see Setup Requirements.

Review each collection's filter and Add/Update settings before enabling them, and decide which collection is the source of truth for each record.

The Customer data type matches on email address. When iPaaS.com finds an existing BigCommerce customer with the same email, the two records are assumed to be the same customer, and the transfer updates the existing record rather than creating a duplicate.

The behavior on a match is configurable on the mapping collection. The selectable methods are:

Choose the method that fits how your business wants duplicate emails handled before enabling the collection. A customer without an email cannot be matched reliably.

Customer Category does not use email collision handling; it matches on its external-ID link.

The outbound Customer collection drives its addresses through a child collection that transfers as part of the customer:

Customer Address and Customer Category are leaf collections with no children of their own.

Automatic transfers do not run until the corresponding triggers are subscribed. Configure them in the subscription configuration:

Customer and its addresses:

Customer category:

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.

iPaaS.com data type: Customer

Writes an iPaaS.com Customer to BigCommerce, creating the customer when it does not yet exist and updating it when it does. Create-versus-update routing is decided by whether the customer is already linked to a BigCommerce customer by an external ID.

Mapping Filter

Filter Description. The filter reads the customer's iPaaS.com B2B_SendToB2B custom field. When that field is set to y or true, the customer is skipped here (return false) and handled by the B2B Customer collection instead. Every other customer passes through (return true). The filter references a custom-field name rather than an environment-specific value, so no placeholder substitution is required.

CustomerGroupId formula:

ChannelIds formula:

Placeholder value — replace during implementation: the default channel 1 in the ChannelIds formula is a BigCommerce channel identifier. Confirm that 1 is the correct channel for your store, or adjust the formula, before relying on it in production. The commented if(1==2) branch is an example scaffold for adding further channels and has no effect as written.

iPaaS.com data type: Customer Address

Writes an iPaaS.com Customer Address to BigCommerce, linked to its parent customer. This is a child collection of Add/Update BigCommerce Customer FROM iPaaS.com and transfers as part of the customer; it is not synced on its own.

Mapping Filter

Filter Description. An address is processed only when both the Address1 street line and the Region are present. Addresses missing either value are skipped. This filter contains no environment-specific value, so no placeholder substitution is required.

Id formula:

Placeholder value — replace during implementation: the "000" phone fallback is a filler value used when the customer has no phone number. Replace it, or remove the fallback, if your business needs a real phone value on BigCommerce addresses. The "US" country default likewise assumes a US-centric customer base — adjust it if your customers are primarily elsewhere.

Duplicate address prevention. To prevent duplicate addresses in BigCommerce, add a Static mapping to a destination field named PreventDuplicate on this collection. When its value is Y, y, or true, iPaaS.com searches BigCommerce for an existing address that exactly matches every mapped field (excluding custom fields); on an exact match, the address is not added and no external ID is assigned. This applies to addresses transferred as a subcollection of the customer.

iPaaS.com data type: Customer Category

Writes an iPaaS.com Customer Category to BigCommerce as a customer group, creating the group when it does not yet exist and updating it when it does. Create-versus-update routing is decided by whether the category is already linked to a BigCommerce customer group by an external ID.

Mapping Filter

Filter Description. The filter reads the category's iPaaS.com Customer Pricing Group custom field. Only categories whose value is true are processed (return true); every other category is skipped (return false). Set this custom field on the categories you want to become BigCommerce customer groups. The filter references a custom-field name rather than an environment-specific value, so no placeholder substitution is required.

The category's CategoryId and InternalId are also required for the transfer to operate — they are the iPaaS.com identifiers the transfer acts on and the link back to the iPaaS.com record. They are supplied by the transfer rather than mapped as fields.

DiscountRules formula:

Placeholder value — replace during implementation: the price list ID 1 in the DiscountRules formula is an example. Replace it with your own BigCommerce price list ID before enabling this collection. To find the ID: log in to BigCommerce, open Products, click Price Lists, open the desired price list, and copy its ID. The commented example shows how to select the price list by category name instead.

Category access types. SetCategoryAccessForCustomerGroup supports three access types:

To find a BigCommerce product category ID: log in to BigCommerce, open Products, click Product Categories, open the desired category, and copy its ID.