When two systems describe the same data differently, integration partners solve it with a documented mapping, explicit transformation rules and controls that stop bad data from being written. Each field is matched to its counterpart, differences in format, codes and structure are converted by rules rather than by hand, and every record carries a key that both systems recognise. Validation happens before data is written, sync direction is defined for each field and rejected records are logged for review. That combination is what keeps both systems clean as data moves between them.
Field Mapping and Transformation: A Worked Example
| External System Field | Salesforce Field | Transformation Rule |
|---|---|---|
| cust_name (single field) | Account Name | Copied as is, trimmed of extra spaces |
| contact_full_name | First Name and Last Name | Split into two fields, with a fallback when only one name exists |
| status_code (A, H, C) | Account Status picklist | Mapped to Active, On Hold and Closed |
| created (text date) | Created date field | Converted to a standard date format and time zone |
| country (free text) | Billing Country | Standardised to the picklist values used in Salesforce |
| amount and currency | Opportunity Amount and Currency | Currency code applied, with conversion only if agreed |
| ext_id | External ID field on Account | Stored and used as the matching key for updates |
A mapping document like this is reviewed by both business and technical owners before development, because it encodes business decisions as much as technical ones.
Using a Canonical Data Model
A canonical model is a shared, neutral format that sits between systems. Instead of translating Salesforce directly into each external system, each system is translated once into the canonical format. This is most useful when several systems exchange the same data, because adding a new system only requires one new mapping rather than one for every existing connection. For a single integration between two systems, a direct mapping is often enough.
Preventing Duplicates
- External ID fields: store each system’s record ID so updates match the existing record instead of creating a new one.
- Upsert operations: insert or update in one step based on the matching key.
- Matching rules: define how to match records that lack an ID, such as email or company name and postcode.
- Duplicate rules in Salesforce: block or flag likely duplicates at the point of entry.
- Initial clean-up: remove existing duplicates before the first sync, so they are not copied across.
Validation Before Data Is Written
Rules check required fields, formats and allowed values before a record is sent. Records that fail are held in an error queue with the reason, rather than being written partially or silently dropped. This keeps bad data out of both systems and gives someone a clear list to fix.
Sync Direction and Conflict Resolution
For each field, decide whether data flows one way or both ways. In two-way sync, conflicts happen when both systems change the same field between syncs. Common rules are that the system of record always wins, that the most recent change wins based on reliable timestamps, or that conflicts are routed to a person for review. One-way ownership per field is the simplest and most reliable option wherever the process allows it.
Monitoring Data Quality Over Time
Clean data at launch is not enough. Track rejected records, duplicate rates and sync failures, review them regularly and adjust mapping rules as systems change. Small, regular fixes keep both systems trustworthy.
Folio3’s Approach
Folio3’s Salesforce integration services include API integration, data mapping and synchronisation between Salesforce and external systems. Where historical data needs cleaning or moving first, Folio3 provides Salesforce data migration services, and integrations can be kept healthy through Salesforce support and maintenance services.
People Also Ask
- How do you map fields between Salesforce and another system?
- What is a canonical data model in integration?
- How do you prevent duplicate records in a Salesforce integration?
- How do you resolve sync conflicts in a two-way integration?
- We need to connect our CRM to an external system through APIs but our data models don’t match. How do integration partners handle transformation and keep both systems clean?
Connecting Salesforce to a system with a different data model? Talk to Folio3’s integration team about a mapping and transformation design that keeps both systems clean.









