Your CRM calls it "company_name" but your ERP calls it "customer_org". Your shipping system uses "ship_to_address" while accounting expects "billing_addr". Your marketing platform sends dates as "MM/DD/YYYY" but your database needs "YYYY-MM-DD".
Every integration becomes a translation project. Your developers write one-off scripts to convert field names and formats. When something changes, someone has to remember which script handles which mapping.
Three months later, nobody remembers why 'status: 3' becomes 'Active' in one system but 'Approved' in another.
Data mapping is the Rosetta Stone between your systems - explicit rules for how every field translates.
TRANSFORMATION COMPONENT - Every integration eventually fails at mapping. Explicit mappings make failures debuggable.
Data mapping defines explicit relationships between fields in different systems: 'When you see first_name in Source A, put it in given_name in Target B. When you see status code 1, translate it to Active.' These rules handle the reality that no two systems ever agree on naming, format, or structure.
Simple mappings are one-to-one: field_a becomes field_b. Complex mappings involve transformations: concatenating first and last name into full_name, converting timestamps to different timezones, looking up codes in reference tables. The best mapping systems make these rules visible and editable, not buried in code.
A mapping configuration isn't just documentation - it's executable specification. When someone asks 'how does customer data flow from Salesforce to NetSuite?', you point them to the mapping file, not the code.
Data mapping separates the "what goes where" from the "how to move it." Change your source schema? Update the mapping. Change your integration code? The mapping stays stable.
Source Field → Mapping Rule → Target Field. The rule can be direct copy, transformation function, lookup table, or conditional logic. Every field that crosses system boundaries needs an explicit mapping.
Click each mapping level to see what happens when you skip transformations. The "Direct Copy" option shows why raw field renaming fails.
{
"customer_name": "Jane Smith",
"order_id": "SH-45892",
"order_date": "12/25/2024",
"ship_address": "123 main street, new york, ny 10001",
"total": "USD 1,234.56",
"status": "3"
}{
"custName": "Jane Smith",
"orderNumber": "SH-45892",
"tranDate": "12/25/2024",
"shipAddr": "123 main street, new york, ny 10001",
"amount": 1234.56,
"orderStatus": "3"
}customer_name → custName (direct copy)order_id → orderNumber (direct copy)order_date → tranDate (direct copy)ship_address → shipAddr (direct copy)total → amount (direct copy, kept as string)status → orderStatus (direct copy, code only)One field becomes another field
The simplest case: source.customer_id → target.cust_id. No transformation, just renaming. You're telling the system 'these are the same thing, just named differently.' Most mappings are this simple.
Convert format, structure, or type
When the data needs to change shape: split full_name into first_name and last_name, convert 'USD 1,234.56' into numeric 1234.56, parse '12/25/2024' into ISO format. The mapping includes the transformation logic.
Translate codes via reference tables
Your system uses status_id: 1, 2, 3. Their system uses status: 'active', 'pending', 'closed'. A lookup table maps between them. When they add status 4, you add one row to the lookup table, not code changes.
A new customer is created in your CRM. Instead of manually re-entering it into the ERP, data mapping translates the CRM's format into the ERP's expected structure. Field names, date formats, and all. The customer record appears in the ERP ready for billing.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
Your sync script has lines like 'target.name = source.company_name' scattered through 500 lines of code. When the source system renames company_name to org_name, you're hunting through code to find every reference.
Instead: Centralize mappings in configuration files or tables. The integration code reads the mapping, not the field names.
You mapped 'status: 1' to 'Active' once, and forgot about it. Six months later, the source system adds 'status: 4'. Your integration silently drops those records because there's no mapping.
Instead: Log unmapped values. Alert on new source values. Have a default handling strategy for unknown mappings.
Your mapping says source.phone → target.phone_number. But source.phone is sometimes null, sometimes empty string, sometimes 'N/A'. Target system rejects nulls but accepts empty strings. Integration fails unpredictably.
Instead: Define explicit null handling in each mapping: skip, default value, transform to empty string, or fail.
You've learned how to define field translations between systems. The natural next step is ensuring the mapped data meets quality standards - normalization makes sure data is consistent after it's mapped.