.png){kind=small}
Field-level mapping across CRM, ERP and warehouse
Field-level mapping decides whether your CRM data is the same data your ERP and warehouse see. This is the playbook we run, including the rules we wish we'd written down before we needed them.
- Author
- Ruben Burdin · Founder & CEO
- Published
- June 3, 2026
- Read time
- 12 min
Map at three levels, in this order
Field mapping isn't one decision. It's three, in sequence: object, field, value. Object mapping says "a Salesforce Account becomes a NetSuite Customer". Field mapping says "Account.BillingCountry becomes Customer.country_iso". Value mapping says "United States becomes US". Most teams collapse all three into a single spreadsheet and then can't explain why a record stopped syncing six months later.
Treat each level as its own configuration surface with its own audit trail. The cost is more configuration; the payoff is being able to answer "why did this record fail?" without having to read code.
Conflict resolution rules that survive contact with sales
Once both sides can write, every field needs a written rule for what happens when they both write at once. There are only four useful ones.
- 01Source-of-truth wins. The owning system always wins; the other side is read-only for that field.
- 02Most recent wins. Last write by wall-clock timestamp wins, with a configurable skew tolerance.
- 03Non-null wins. Whichever side has a value wins; nulls don't overwrite real data.
- 04Manual reconciliation. Both writes are queued; a human resolves the conflict, and the rule is logged so the next conflict on that field is automatic.
Custom records: the place every integration breaks
Standard objects map themselves. The cost is in custom objects, custom properties, and the dependency graph between them. A Salesforce custom object with a master-detail relationship to a Contact doesn't have a clean equivalent in HubSpot's association model — it has to be expressed as an association with constraints enforced by sync rules.
The rule we follow: every custom object pair gets a written contract before any data flows. The contract names the keys on both sides, the cardinality, the cascade behavior, and what happens when a parent is soft-deleted. Skip this step and you'll discover the missing constraint at quarter-end, when finance asks why two records think they're the same opportunity.
FAQ
Frequently asked questions
