Summary

A SugarCRM Account can be created or updated from an iPaaS.com Customer through the subscription's outbound triggers or through Manual Sync. Each transfer writes the Customer's company details and email, maintains a single primary contact on the Account, and writes the Customer's primary billing and shipping addresses onto the Account's own address fields.

ID Format

Manual Sync ID Format

Enter the iPaaS.com Customer id on the iPaaS.com Manual Sync page.

Example: 197689

External ID Format

After a successful transfer, iPaaS.com saves the SugarCRM Account id as the external id on a dedicated external-id record for the Customer. That external-id record is the primary match that routes later updates to the same SugarCRM Account.

Two additional identifiers support matching:

The default template maps the iPaaS.com Customer id into the SugarCRM Spaceport_SourceId field, so the originating Customer can be identified from the SugarCRM side.
On the first transfer, when no external-id record exists yet, the integration looks for a SugarCRM Account whose email matches the Customer's Email1 value. If one is found, that Account is linked and updated instead of a duplicate being created.

Deleted Record Support

Outbound delete is supported. When a delete is dispatched for a linked Customer, the integration removes the Account's primary contact first, where one is linked, and then deletes the SugarCRM Account.

Delete mappings are not enabled by default; subscribers or their MiSP who want deletions to propagate should confirm the delete configuration before enabling it, and should be aware that the removal in SugarCRM is not reversible from iPaaS.com.

Custom Field Support

Custom fields defined in SugarCRM through SugarCRM Studio can be written from iPaaS.com. To map a value to one, create the field in SugarCRM Studio, add a custom field to the iPaaS.com Customer using the same name, and map it in this collection.

The default mappings include an example custom-field mapping (customfield). Replace it with your own field, or remove it if not needed.

Mapping Collection Status

Status: Enabled. This collection has no mapping filter, so every Customer presented to it is processed.

Trigger Events: iPaaS.com Customer create and update activity, for subscribers who have enabled the corresponding outbound triggers; and Manual Sync on demand. Whether a transfer creates a new SugarCRM Account or updates an existing one depends on whether the Customer is already linked, not on which trigger fired.

Duplicate or Conflicting Mappings

Add/Update SugarCRM Account TO iPaaS.com transfers the same records in the opposite direction. Before enabling both directions, subscribers or their MiSP should decide which system is the source of truth for Account and Customer data and review each collection's Add/Update settings, so a change is not written back and forth between the two systems.

Unmapped field behavior in SugarCRM

The integration sends the complete Account payload on each update. SugarCRM Account fields that are not covered by these mappings may therefore be cleared when an update is written. Subscribers or their MiSP who maintain data directly in SugarCRM on fields outside this mapping set should validate the behavior in a staging environment before enabling automatic transfers.

Unmapped Field Overwrite Risk (inbound direction)

When the inbound collection Add/Update SugarCRM Account TO iPaaS.com runs, iPaaS.com replaces the whole Customer record, and the iPaaS.com Customer Comment field is not mapped in the default template mappings — so any value held there is cleared on each inbound transfer. Subscribers or their MiSP who rely on that field should review the inbound collection before enabling both directions.

Supported Child Collections

None. Unlike the inbound direction, this collection writes the billing and shipping addresses directly onto the SugarCRM Account using formulas that read the Customer's primary billing and shipping addresses, so there are no separate child address collections.

System Caveats

SugarCRM Caveats

Account name required: SugarCRM requires an Account name; the transfer sets it from the Customer's company name.
Account matching on create: New Accounts are matched to an existing SugarCRM Account by Email1 before a new Account is created.
Primary contact only: Only one primary contact is maintained per Account. If no value is present in the SugarCRM PrimaryContactID mapping, the primary contact is not updated when an existing Account is updated.
Addresses written inline: Billing and shipping addresses are written onto the Account's own address fields; SugarCRM does not maintain them as separate records.
Rate limiting: SugarCloud instances are subject to SugarCRM's published limit of 20 API requests per second. When SugarCRM reports that the request limit has been reached, the transfer is retried automatically once the limit window resets, and no subscriber action is required. On-premise instances are governed by their own server configuration.

iPaaS.com Caveats

The Customer's addresses must be flagged as the primary billing and primary shipping addresses for them to be written to SugarCRM. Only those two addresses are transferred.
A custom field named SugarCRM PrimaryContactID must exist on the iPaaS.com Customer model for contact matching to be preserved across transfers.

Setup Requirements

iPaaS.com Configuration

The Customer create and update outbound triggers enabled under the subscription's Outbound Data Flows. No automatic transfers occur until these are enabled.
A custom field named SugarCRM PrimaryContactID on the Customer model.

SugarCRM Configuration

An API user with permission to read and write Accounts and Contacts.
Any SugarCRM Studio custom fields you intend to populate created ahead of the first transfer.

See SugarCRM Installation Instructions for the full setup walkthrough.

Integration Flow

A Customer is created or updated in iPaaS.com and a subscribed outbound trigger fires, or a subscriber runs a Manual Sync using the iPaaS.com Customer id.
If the Customer is already linked to a SugarCRM Account, the integration updates that Account. Otherwise it first looks for an Account whose email matches the Customer's Email1 value.
If a matching Account is found, it is linked and updated. If none is found, a new Account is created in SugarCRM.
The Customer's primary billing and shipping addresses are read and written onto the Account's billing and shipping address fields as part of the same write.
When the Customer's contact name fields are present, the integration creates or maintains a single primary contact on the Account, and records its identifier on the SugarCRM PrimaryContactID mapping.
iPaaS.com saves the SugarCRM Account id as the external id for the Customer, so later updates route to the same Account.

Mappings

Add/Update SugarCRM Account FROM iPaaS.com

iPaaS.com data type: Customer

Description: Writes the iPaaS.com Customer to a SugarCRM Account, including the primary contact and the primary billing and shipping addresses.

Mapping Type	Source Field (iPaaS.com)	Destination Field (SugarCRM)	Description
Field	`Company`	Name	Required. SugarCRM requires an Account name; it is set here from the Customer's company name.
Field	`EmailAddress`	Email1	Recommended. The Account's primary email address. Also used to match an existing Account on the first transfer so a duplicate is not created.
Field	`FirstName`	Contact_First_Name	Recommended. First name of the Account's primary contact. When a contact name is present, a single primary contact is created or maintained.
Field	`LastName`	Contact_Last_Name	Recommended. Last name of the Account's primary contact.
Static	`iPaaS.com`	Contact_Portal_App	Identifies iPaaS.com as the portal application for the contact. A fixed system value that does not normally need to be changed.
Field	`Id`	Spaceport_SourceId	Recommended. Writes the originating iPaaS.com Customer id onto the Account so the source record can be identified from SugarCRM.
Field	`customfield_test`	customfield	Optional custom field, provided as an example of mapping a custom field to SugarCRM. Replace it with your own SugarCRM Studio field, or remove it.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address1")`	Billing_Address_Street	Recommended. The first street line from the Customer's primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address2")`	Billing_Address_Street_2	Optional. The second street line from the Customer's primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address3")`	Billing_Address_Street_3	Optional. The third street line from the Customer's primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "City")`	Billing_Address_City	Recommended. The city from the Customer's primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region")`	Billing_Address_State	Recommended. The state or region from the Customer's primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "PostalCode")`	Billing_Address_PostalCode	Recommended. The postal code from the Customer's primary billing address.
Dynamic Formula	`CountryCode(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Country"))`	Billing_Address_Country	Recommended. The country from the Customer's primary billing address, converted to its country code.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address1")`	Shipping_Address_Street	Recommended. The first street line from the Customer's primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address2")`	Shipping_Address_Street_2	Optional. The second street line from the Customer's primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address3")`	Shipping_Address_Street_3	Optional. The third street line from the Customer's primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "City")`	Shipping_Address_City	Recommended. The city from the Customer's primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region")`	Shipping_Address_State	Recommended. The state or region from the Customer's primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "PostalCode")`	Shipping_Address_PostalCode	Recommended. The postal code from the Customer's primary shipping address.
Dynamic Formula	`CountryCode(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Country"))`	Shipping_Address_Country	Recommended. The country from the Customer's primary shipping address, converted to its country code.

Error Handling

Errors raised during a transfer appear under Dashboard / Integration Monitoring / Error Logs. Most errors in this direction are returned by SugarCRM and are reported as received. See SugarCRM Error Messages for the full catalog of subscriber-visible messages and their resolutions.

Connection validation failures: the transfer cannot start because the configured API URL, user, or password is rejected by SugarCRM. Resolution: confirm the credentials and API URL on the subscription, then retry. See SugarCRM Connections and Settings.
Missing Account name: SugarCRM rejects an Account without a name. Resolution: ensure the Customer has a company name, or remap Name to a source that is always populated.
Request limit reached: SugarCRM reports that the API request limit has been reached. No action is required; the transfer is retried automatically once the limit window resets.

Testing & Validation

Test Scenarios

Create a Customer in iPaaS.com with a company name, email address, and contact name, then verify a matching Account is created in SugarCRM with a primary contact.
Update the Customer's company name and verify the change propagates to the SugarCRM Account Name field.
Create a Customer whose email matches an existing SugarCRM Account and verify that Account is linked and updated rather than a duplicate being created.
Run a Manual Sync using the iPaaS.com Customer id and confirm the transfer succeeds.
Add primary billing and shipping addresses to the Customer and verify both are written onto the SugarCRM Account's billing and shipping address fields.
Update the Customer twice and confirm the same primary contact is updated rather than a second contact being created.

Validation Checklist

The Customer create and update outbound triggers are enabled under Outbound Data Flows.
A custom field named SugarCRM PrimaryContactID exists on the iPaaS.com Customer model and is populated for Accounts whose contact should be maintained.
The Customer's addresses are flagged as primary billing and primary shipping.
The example custom-field mapping has been replaced with your own SugarCRM Studio field, or removed.
The behavior of SugarCRM Account fields outside this mapping set has been validated in staging before enabling automatic transfers.

SugarCRM from iPaaS.com Account Mapping Documentation