Data Mapping
The documented correspondence between fields in two systems: what moves, in which direction, and what happens when both sides change. The artefact that decides whether an integration is maintainable.
Also called: field mapping
What it is
Data mapping is the explicit statement of how a field in one system corresponds to a field in another: source, destination, direction of travel, any transformation applied, and the rule for what happens when both sides have changed since the last sync.
The four things a mapping must state
Correspondence: which field goes to which. Names rarely match, and near-matches are where errors hide.
Direction: one-way or bidirectional. Bidirectional is far more expensive and should be chosen deliberately, not by default.
Transformation: picklist translation, date formats, currency, concatenation. This is where most silent corruption originates.
Conflict rule: which side wins when both changed. Without this, the answer is whichever synced last, which is not a decision anyone made.
Why it is worth writing down
Integrations fail quietly. A mapping that drops a field does not raise an error; it produces a record that looks complete and is not. Six months later somebody notices the numbers disagree, and without a written mapping the only way to find out what should have happened is to read the integration configuration and infer intent from it.
The mapping document is also what makes a migration reversible. If you cannot say what went where, you cannot verify the load, and you cannot roll it back.
RELATED TERMS
Systems of Record
The set of systems that each hold authoritative data for part of the business, and the map of which owns what. The architectural decision underneath every reporting question.
Data Hygiene
The continuous practice of keeping records accurate, complete and current — as distinct from data quality, which is the state that practice produces.
Data Governance
The rules determining who may change what, how changes are reviewed, and how they are recorded. The control that stops a designed system from drifting back to whatever it was before.
Single Source of Truth (SSOT)
The declared authority for a given piece of data — the system whose value wins when two systems disagree. Correctly applied it is decided per field, not per system.
COMMON QUESTIONS
- When should a sync be bidirectional?
- Only when both systems genuinely need to originate changes to that field and you have a defensible conflict rule. Most fields have one authoritative source, and a one-way mapping is cheaper to run and far easier to debug.
- What is the most common data mapping mistake?
- Unmapped picklist values. The source has an option the destination does not, the sync drops or defaults it, and the resulting records look valid while being wrong. Enumerate every value on both sides before going live.
- Who should own the mapping document?
- Revenue operations, kept alongside the integration itself rather than in someone's drive. It should be updated in the same change that alters the integration, or it becomes fiction.
WHERE THIS HAS BEEN APPLIED
Client work and research from RevOps HQ, our consulting practice.
Build the capability
Definitions are the vocabulary. The courses are where you learn to operate it, with the interactive audit tools.
See the courses