Summary
iPaaS.com Transactions can be written into Copper CRM as activities logged against a person, through outbound data flows or Manual Sync. Each transferred transaction produces one Copper CRM activity carrying a short summary line, so sales users see a record of the customer's orders on the person's activity feed. The activity is a summary rather than a full copy of the transaction.
ID Format
Manual Sync ID Format
Enter the iPaaS.com Transaction ID — the identifier iPaaS.com assigns to the transaction record.
External ID Format
After a successful transfer, iPaaS.com records the Copper CRM activity's identifier against the iPaaS.com Transaction on a dedicated external-ID record. That link is the primary match for later transfers, routing a repeat transfer of the same transaction to an update of the existing activity rather than adding a duplicate activity to the person's feed.
Deleted Record Support
Delete is supported. When a delete is dispatched for a linked Transaction, the integration removes the corresponding activity from Copper CRM using the recorded external-ID link.
Custom Field Support
Custom fields are not supported for this collection. Activity transfers carry the fields listed under Mappings below; there is no custom-field configuration step for Copper CRM activities.
Mapping Collection Status
Status: Enabled.
Trigger Events: the iPaaS.com Transaction change events the subscriber enables under Outbound Data Flows. Whether a change results in an activity being added or updated in Copper CRM depends on whether the transaction has already been transferred, not on which event fired.
Duplicate or Conflicting Mappings
No other mapping collection in this integration writes Copper CRM activities, and there is no inbound collection that brings Copper CRM activities back into iPaaS.com. Transactions therefore flow in one direction only, from iPaaS.com to Copper CRM.
Note that this collection depends on the Add/Update Copper Person FROM iPaaS.com collection, which it invokes automatically when the transaction's customer is not yet in Copper CRM. See Integration Flow below.
Supported Child Collections
This collection has no child collections. Transaction line items, payments and other child data are not written to Copper CRM.
System Caveats
Copper CRM Caveats
The activity type must already exist: activity types are defined in Copper CRM and the integration resolves the one named in the mapping by name. An activity type that does not exist causes every transfer through this collection to fail. Create the activity type in Copper CRM, or change the mapping to name one that already exists, before enabling the collection.
Activities are logged against people: activities written by this collection attach to a Copper CRM person. They are not attached to companies, opportunities or other record types.
API request limits: Copper CRM limits API traffic to 180 requests per minute on a rolling window and rejects requests beyond it. Rejected transfers appear under Dashboard → Integration Monitoring → Error Logs. Because a transaction transfer can also trigger a customer transfer, a single transaction may consume several requests. Set the subscription's API Throttle Limit, API Throttle Seconds, Concurrent Connections and Concurrent Batch Executions accordingly.
iPaaS.com Caveats
The transaction must carry a customer: the activity is logged against the Copper CRM person derived from the transaction's customer. A transaction with no customer cannot be transferred.
The customer's email address supports the fallback match: where the transaction's customer has no recorded link to a Copper CRM person, the email address carried on the transaction is what allows the integration to find the right person.
Integration-Specific Caveats
The customer is transferred automatically as a prerequisite: subscribers do not need to transfer the customer to Copper CRM first. See Integration Flow below.
A failed customer transfer blocks the activity: if the customer cannot be created in Copper CRM, the transfer ends with an error and no activity is written.
Setup Requirements
Copper CRM Configuration
Create the activity type that transferred transactions should be logged as, and confirm the mapping names it exactly as it is spelled in Copper CRM.
iPaaS.com Configuration
Enter the API URL, API Key and API Email on the Copper CRM subscription. See the Copper CRM Connections and Settings article for the full field reference.
Enable the relevant iPaaS.com Transaction events under Outbound Data Flows so transactions transfer automatically.
Confirm the Add/Update Copper Person FROM iPaaS.com collection is configured, since transactions whose customer is not yet in Copper CRM rely on it to create the person.
Integration Flow
A Transaction is created or changed in iPaaS.com and dispatched through the subscribed outbound data flow, or the transfer is started from the Manual Sync page using the iPaaS.com Transaction ID.
The integration determines which Copper CRM person the activity belongs to, from the transaction's customer:
It first looks for an existing link between the transaction's Customer and a Copper CRM person.
If no link exists, it transfers that customer to Copper CRM as part of the same operation, using the Add/Update Copper Person FROM iPaaS.com collection, and attaches the activity to the person that transfer creates or matches. If that customer transfer fails, the activity transfer stops with an error and nothing is written.
If the customer still cannot be resolved, it falls back to searching Copper CRM for a person with the same email address as the transaction.
The Copper CRM activity type named in the mapping is resolved by name. If no activity type matches, the transfer fails.
The integration checks whether this transaction has already produced an activity. If it has, that activity is updated; if not, a new one is created.
The activity is written against the person, with its summary line and category.
For a delete, the linked Copper CRM activity is removed rather than updated.
Mappings
Add/Update Copper Activity FROM iPaaS.com
Description. Writes the iPaaS.com Transaction into Copper CRM as an activity logged against the customer's person record.
This collection has no mapping filter, so all Transaction records dispatched through outbound data flows or Manual Sync are processed. Subscribers who only want certain transactions logged in Copper CRM — for example only completed orders — should add a mapping filter before enabling the collection.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Copper CRM) | Description |
Dynamic Formula |
| ParentId | Required. Identifies the Copper CRM person the activity is logged against. Looks for the recorded link first, then falls back to finding a person by email address. If the customer is not yet in Copper CRM the integration transfers it automatically; if that fails, the activity is not written. |
Dynamic Formula |
| Activity_TypeId | Required. Resolves the Copper CRM activity type by name. If the name does not match an activity type in Copper CRM the transfer fails. Placeholder value — replace during implementation: Phone Call is an example activity-type name; substitute the activity type these records should be logged as, spelled exactly as in Copper CRM. |
Dynamic Formula |
| Details | Recommended. Builds the summary line shown on the activity, producing text such as "Order 1042 Placed by name@example.com". This is the only part of the activity a Copper CRM user reads, so an activity without it carries no context. The wording can be customised. |
Static |
| Activity_Category | Records the activity as a user activity rather than a system-generated one, so it appears in the normal activity feed on the person's record. |
Dynamic Formula |
| Id | Supplies the Copper CRM activity identifier when an existing activity is being updated. Empty on a first transfer, so a new activity is created and the link recorded. Populated by the integration; it does not normally need changing. |
Field | CustomerId | CustomerId | Optional supporting field. Carries the iPaaS.com customer identifier onto the activity; it is the value the ParentId lookup uses. |
Field | EmailAddress | CustomerEmail | Optional supporting field. Carries the customer's email address; it is the value the ParentId fallback uses. |
Field | CustomerId | OldValue | Optional. Carries the iPaaS.com customer identifier onto the activity as a secondary reference. Validate in a staging environment whether this value is needed before relying on it. |
Dynamic Formula source. Three of the formulas above span multiple lines. They are reproduced here exactly as they are configured on the mapping collection:
ParentId
var customerId = await GetExternalIdAsync(CustomerId, "Customer", SpaceportSystemId); if (customerId == null || customerId == "") return await GetCustomerIdByEmail(EmailAddress); else return customerId ;
Activity_TypeId
await GetCopperActivityTypeIdByName("Phone Call");
// await GetCopperActivityTypeIdByName("Sales Order");The second line is an inactive comment. It has no effect unless a subscriber activates it, and the active line is the one that determines the activity type.
Id
var external = await GetExternalIdAsync(Id, "Transaction", SpaceportSystemId); return external;
Error Handling
Errors raised during these transfers appear under Dashboard → Integration Monitoring → Error Logs. The most common causes are:
The customer could not be created in Copper CRM: the activity depends on a person to attach to, so a failed customer prerequisite stops the order transferring.
The activity type does not exist in Copper CRM: the name in the mapping must match a Copper CRM activity type exactly. Create the activity type or change the mapping.
Copper CRM is unavailable or rejects the request: including when the 180 requests per minute limit is exceeded. The transfer fails and can be retried by dispatching a new change or using Manual Sync.
For the full catalogue of subscriber-visible messages, see the Copper CRM Error Messages article.
Testing & Validation
Test Scenarios
Transfer a Transaction whose customer is already linked to a Copper CRM person and verify a single activity appears on that person's feed with the expected summary line.
Transfer a Transaction whose customer is not yet in Copper CRM and verify the person is created automatically and the activity attached to it.
Transfer a Transaction whose customer has no link but whose email matches an existing Copper CRM person, and verify the activity attaches to that person rather than creating a duplicate.
Re-transfer the same Transaction and verify the existing activity is updated rather than a second activity being added.
Set the activity-type mapping to a name that does not exist in Copper CRM and confirm the transfer fails with a clear error.
Transfer a Transaction with no customer and confirm the transfer fails with a clear error.
Delete a linked Transaction and confirm the activity is removed from Copper CRM.
Validation Checklist
The activity type named in the mapping exists in Copper CRM, spelled identically.
The example activity-type name has been replaced with the intended one.
The relevant iPaaS.com Transaction events are enabled under Outbound Data Flows.
The Add/Update Copper Person FROM iPaaS.com collection is configured, since it is invoked as a prerequisite.
A mapping filter has been added if only certain transactions should be logged.
Throttle and concurrency values account for transfers that also trigger a customer transfer.
Additional Notes
Activities are summary records. Line items, payments, shipping detail and totals are not written to Copper CRM.
Transactions flow only from iPaaS.com to Copper CRM. Editing or deleting the activity in Copper CRM does not change the transaction in iPaaS.com.