Summary
An iPaaS.com Customer is written back to a Salesforce Contact through the Add/Update Salesforce Contact FROM iPaaS.com mapping collection. When a Customer is created or updated in iPaaS.com, the integration creates or updates the corresponding Contact in Salesforce, and the Customer's primary shipping address flows back to the Contact's mailing address through the child collection. Write-back is partial: fields that are not mapped, or that arrive empty, are left unchanged on the existing Salesforce Contact rather than being blanked.
ID Format
Manual Sync ID Format
When syncing a Customer on demand from the Manual Sync page, enter the iPaaS.com Customer id for the record to write back to Salesforce.
Example: 123456
External ID Format
When the integration creates a Contact in Salesforce, the resulting Salesforce Contact Id is retained as the cross-reference for that Customer. Salesforce object Ids are 15 or 18 character alphanumeric values, for example 003Ux00000ABcdEFGH. On later updates the integration uses this saved reference to update the same Contact rather than creating a second one. The email address also participates in matching the Customer to the correct Contact, which helps avoid duplicate records.
Deleted Record Support
Record deletion is not synced. Removing a Customer in iPaaS.com does not delete the related Contact in Salesforce, and no delete mappings are included in the default templates. To remove a Contact, subscribers or their MiSP should manage that record directly in Salesforce.
Custom Field Support
iPaaS.com Customer custom fields can be written back to Salesforce Contact custom fields. The collection ships with two custom field examples, Languages and ContactTestCustomField, to demonstrate the pattern.
To map a custom field, create a matching custom field in Salesforce (under Data Management, Custom Fields), keeping the data type consistent, and create the corresponding field within the Subscription in iPaaS.com named to match the Salesforce API name. Once the field exists in both places, add the mapping. Keeping a 1:1 relationship between the matching fields results in a smoother integration.
Placeholder value — replace during implementation: the custom field examples are for demonstration only. The actual custom fields to map depend on the implementation, so subscribers or their MiSP should replace the examples with the fields relevant to their Salesforce org.
Mapping Collection Status
Status: Enabled
Trigger Events: Create, Update. A Customer that is created or updated in iPaaS.com is written back to Salesforce as a create (new Contact) or a partial update (existing Contact).
Duplicate or Conflicting Mappings
This is the only active mapping for writing Salesforce Contacts from iPaaS.com. Additional mappings may be needed to transfer other field values from iPaaS.com to Salesforce (for example Comments); the destination fields will be specific to each implementation.
Collision Handling
When the integration writes a Contact to Salesforce and a matching record already exists, the outcome depends on whether a collision-handling method is selected on the mapping collection in the iPaaS.com mapping UI. When a method is selected, the integration can link to the existing record instead of creating a duplicate. When no method is selected, the integration surfaces a duplicate error rather than guessing. See the Salesforce Error Messages article for the duplicate-detected condition and its resolution.
Supported Child Collections
This is a parent-level mapping collection. It has one child collection:
Add/Update Salesforce Contact Address FROM iPaaS.com: writes the Customer's primary shipping address back to the Contact's mailing address in Salesforce.
System Caveats
Salesforce Caveats
Salesforce requires every Contact to be associated with an existing Account, so the Account that the Customer's Company resolves to must already exist in Salesforce before the Contact can be written. Salesforce also treats Last Name as the required name field for creating a Contact, so a usable value should be present on the source Customer. Because Salesforce does not expose a public field-requiredness API, subscribers or their MiSP should validate field requirements and write-back behavior in a staging environment before relying on them in production.
Address details are stored on the parent Salesforce Contact (its Mailing address fields). There are no separate Salesforce address records; the address child collection writes those parent fields.
iPaaS.com Caveats
The Customer in iPaaS.com must have its Company value populated with a related Salesforce Account; a Customer with no Company is skipped by the collection filter and is not written to Salesforce.
Integration-Specific Caveats
Write-back is partial: fields that are not mapped, or that arrive empty on the source Customer, are left unchanged on the existing Salesforce Contact rather than being blanked. To force a value onto the Contact, use a static or destination value on the mapping. Record deletion is not synced in either direction.
Integration Flow
A Customer is created or updated in iPaaS.com.
Customers that have no Company value are skipped by the collection filter; only Customers with a Company are written back.
The integration resolves the Salesforce Account from the Customer's Company; that Account must already exist in Salesforce for the Contact to be written.
If no matching Contact exists in Salesforce, a new Contact is created from the mapped Customer fields; Last Name should be present as Salesforce uses it as the required name field.
If a matching Contact exists, it is updated as a partial update — mapped fields with values are written, and fields that are unmapped or empty are left unchanged.
The Customer's primary shipping address is written back to the Contact's mailing address through the address child collection.
Mappings
Mapping Filter
This collection processes only Customers that have a Company value. A Customer with no Company is skipped and not written to Salesforce. The filter is:
if(Company != null) return true;
Add/Update Salesforce Contact FROM iPaaS.com
This collection maps iPaaS.com Customer fields back to the Salesforce Contact. Because Salesforce does not expose a public field-requiredness API, subscribers or their MiSP should validate field requirements in a staging environment before relying on them in production.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Salesforce) | Required / Recommended / Optional | Description |
Field | Company | AccountId | Recommended | Maps the Customer's related Company to the Contact's parent Account. Salesforce requires every Contact to be associated with an existing Account, so the Account this resolves to must already exist in Salesforce. Customers with no Company are skipped by the filter. |
Field | Last Name | LastName | Recommended | Maps the Customer's last name to the Contact's LastName. Salesforce treats Last Name as the required name field for creating a Contact, so a usable value should be present. If empty on the source, the existing value is left unchanged rather than blanked. |
Field | First Name | FirstName | Optional | Maps the Customer's first name to the Contact's FirstName. If empty on the source, the existing value is left unchanged rather than blanked. |
Field | Email Address | Recommended | Maps the Customer's email address to the Contact's Email. The email address is also how the integration links a Customer to the correct Contact, which helps avoid creating duplicate records. | |
Dynamic Formula | Relationships | Level | Optional | Sets the Contact's Level field to "Primary" when the Customer has a primary Contact-type relationship; otherwise it leaves no value. It is provided as an editable dynamic formula. The Source is: |
Field | Languages (custom field) | Languages__c | Optional | Maps the value of an iPaaS.com Customer custom field to the corresponding Salesforce custom field. This is an implementation-specific example of custom-field mapping — see Custom Field Support. |
Field | ContactTestCustomField (custom field) | ContactTestCustomField__c | Optional | Maps the value of an iPaaS.com Customer custom field to the corresponding Salesforce custom field. This is an implementation-specific example of custom-field mapping — see Custom Field Support. |
Placeholder value — replace during implementation: the Languages__c and ContactTestCustomField__c rows are custom-field examples only; replace them with the custom fields relevant to the implementation.
Add/Update Salesforce Contact Address FROM iPaaS.com
This child collection writes the Customer's primary shipping address back to the Contact's mailing address in Salesforce. Only the address marked as the primary shipping address is written; other addresses on the Customer are skipped. The address fields are stored on the parent Contact record. Write-back is partial: address fields that are empty on the source are left unchanged rather than blanked.
Mapping Filter
This child collection writes only the address marked as the primary shipping address on the Customer. The filter is:
if(IsPrimaryShipping) return true; return false;
Mapping Type | Source Field (iPaaS.com) | Destination Field (Salesforce) | Required / Recommended / Optional | Description |
Field | Address1 | Street | Optional | Maps the Customer address's first address line to the Street of the Contact's mailing address. If empty on the source, the existing value is left unchanged rather than blanked. |
Field | City | City | Optional | Maps the Customer address's city to the City of the Contact's mailing address. If empty on the source, the existing value is left unchanged rather than blanked. |
Field | Region | State | Optional | Maps the Customer address's region to the State/Province of the Contact's mailing address. If empty on the source, the existing value is left unchanged rather than blanked. |
Field | Country | Country | Optional | Maps the Customer address's country to the Country of the Contact's mailing address. If empty on the source, the existing value is left unchanged rather than blanked. |
Field | PostalCode | PostalCode | Optional | Maps the Customer address's postal code to the Postal Code of the Contact's mailing address. If empty on the source, the existing value is left unchanged rather than blanked. |
Error Handling
Errors raised while writing a Contact back to Salesforce appear under Dashboard, Integration Monitoring, Error Logs. The conditions that most often affect this direction are documented in the companion Salesforce Error Messages article, which describes each message together with why it occurs and how to resolve it. Common conditions include:
The Customer has no Account Id available for linking the Contact. Resolution: confirm the Customer's Company is populated and that it resolves to an Account that already exists in Salesforce.
The related Account cannot be located in Salesforce. Resolution: the Account must exist in Salesforce before the Contact can be created under it; create or sync the Account first.
A duplicate Contact is detected on create with no collision-handling method selected. Resolution: select a collision-handling method on the mapping collection so the integration can link to the existing record, or resolve the duplicate in Salesforce.
A Salesforce API call fails. Resolution: review the error detail in the Error Logs and confirm the connection settings and Salesforce permissions, then re-run the sync.
Testing & Validation
Test Scenarios
Create a Customer in iPaaS.com with a populated Company (resolving to an existing Salesforce Account), a last name, and a valid email, and confirm a corresponding Contact is created in Salesforce.
Update a mapped field (for example, First Name or Email) on an existing Customer and confirm the change propagates to the Contact.
Clear a previously populated value on the Customer and confirm the existing Salesforce value is left unchanged rather than blanked.
Attempt to write back a Customer with no Company and confirm it is skipped and no Contact is created.
Attempt to write back a Customer whose Company resolves to an Account that does not exist in Salesforce and confirm an appropriate error appears in the Error Logs.
Populate the Customer's primary shipping address and confirm it is written to the Contact's mailing address; confirm a non-primary address is not written.
Mark the Customer's Contact-type relationship as primary and confirm the Contact's Level is set to Primary.
Validation Checklist
The Contact is created under the correct Salesforce Account.
Last Name, First Name, and Email match between the Customer and the Contact.
Clearing a source value does not blank the existing Salesforce value (partial write-back).
Only the primary shipping address is written to the Contact's mailing address.
The Contact's Level is set to Primary when the Customer has a primary Contact-type relationship.
No duplicate Contact is created when the same Customer writes back again.
Out of Scope
The following are not handled by this mapping collection, at the time this documentation was written:
Record deletion. Removing a Customer in iPaaS.com does not delete the Contact in Salesforce.
Field blanking. Write-back is partial; unmapped or empty values do not overwrite existing Salesforce values. Use a static or destination value to force a value.
Real-time capture. Change capture is poll based; there is no real-time push.
Separate address records. Addresses are limited to the Contact's Mailing fields on the parent record; only the primary shipping address is written.
Customers with no Company. Customers that have no Company are skipped; the related Account must exist in Salesforce before a Contact can be written.
Custom-field assignment. The custom-field examples are implementation-specific; the fields to map depend on each subscriber's Salesforce org and are configured during implementation.