Start with one question: what should happen when an incoming value differs from the value you already have? Matching column names does not answer that question. A useful mapping pairs each field with an update rule, a validation check and a named decision owner.
Blog
CRM enrichment field mapping guide
A field mapping records where each incoming value belongs, how it changes before use, when it may update an existing record, and who reviews exceptions. Agree on these decisions before importing enrichment data into your CRM.
1. Define the record and destination
Specify whether you are updating an account, a contact or another record type. An account describes an organization; a contact describes a person. Keep their identifiers and destination fields separate. A company name on a contact does not, by itself, authorize an update to an account record.
Use the worksheet and fictional examples below to plan that review. The fields and policies are illustrative planning choices; they do not describe AvalenData integrations or available data fields.
Retain a stable internal identifier for the record you intend to update. Define what happens when that identifier is missing, matches nothing or matches more than one record. A name alone is insufficient to identify a person or organization: similar names need review rather than an assumed match.
For the fictional example in this guide, the file updates an existing account record. Its internal ID must resolve to exactly one account. A row that fails that check is held before any field changes are proposed.
2. Fill in the field mapping worksheet
Complete one worksheet entry for every proposed destination field. Copy the three blank entries below into your planning document and add more as needed. Keep the original incoming values alongside transformed candidates so reviewers can see what changed.
| Worksheet prompt | What to record | Entry 1 | Entry 2 | Entry 3 |
|---|---|---|---|---|
| Record type | Account, contact or another defined object | ___ | ___ | ___ |
| Source field | Exact incoming column name | ___ | ___ | ___ |
| Source meaning/type | What the value means and its format | ___ | ___ | ___ |
| Target field | Exact destination field name | ___ | ___ | ___ |
| Target meaning/type | Destination definition and accepted format | ___ | ___ | ___ |
| Transformation | Each change, in order | ___ | ___ | ___ |
| Validation | Conditions a candidate must pass | ___ | ___ | ___ |
| Blank rule | Action for missing or empty input | ___ | ___ | ___ |
| Existing-value/conflict rule | When to retain, propose or hold a value | ___ | ___ | ___ |
| Exception action | What stops and where the question goes | ___ | ___ | ___ |
| Decision owner | Person or team resolving that field’s exceptions | ___ | ___ | ___ |
| Approval/version | Approved rule version and approval record | ___ | ___ | ___ |
Write rules precisely. “Clean department” leaves room for different interpretations. “Trim outer whitespace, then map only the exact labels sales and marketing” gives a reviewer something to reproduce. An unrecognized label should remain an exception until someone decides how to handle it.
For a related commercial discussion, discuss CRM enrichment requirements using your completed mapping as the starting point.
3. Follow a worked source-to-target example
Fictional planning example. Field names and rules are illustrative; confirm your own schema and data availability. All records, role assignments and decisions in this section are synthetic. They contain no real personal records and show proposed decisions rather than an executed import.
The example policy is called Mapping v1. It allows a valid candidate to fill an empty destination only after policy approval. It preserves existing nonblank values when a different candidate arrives. Here, null represents an empty destination value; a string containing only spaces becomes blank after trimming.
Mapping v1: field rules
record_key → crm_record_id
- Record type: account. Both fields contain text representing the existing internal account ID.
- Transformation: trim outer whitespace; keep the remaining characters unchanged.
- Validation: require exactly one existing internal-ID match. Hold duplicate incoming IDs for resolution as well.
- Blank/conflict rule: a missing ID, no match or multiple matches holds the entire row. This is a lookup key, not a request to replace an ID.
- Exception owner: CRM administrator. Approval/version: record the administrator’s approval against Mapping v1 before use.
company_name → account_name
- Record type: account. Both fields contain organization-name text.
- Transformation: trim outer whitespace and retain original case.
- Validation: a proposed value must contain nonblank text.
- Blank/conflict rule: retain an existing name for blank input. An identical value requires no change. Hold a different nonblank name for field review; do not infer identity or merge accounts from names.
- Exception owner: account data owner. Approval/version: record that owner’s approval against Mapping v1.
department → department
- Record type: account. In this example only, the field stores an illustrative organizational department label as text.
- Transformation: trim outer whitespace; map the exact source label sales to Sales and marketing to Marketing.
- Validation: hold any other nonblank label for review; the dictionary does not infer case variants or synonyms.
- Blank/conflict rule: retain the existing value for blank input. A valid candidate may fill an empty field after policy approval. Hold a different nonblank value; retain the existing value pending review.
- Exception owner: RevOps owner. Approval/version: record that owner’s approval against Mapping v1.
Case A: propose a value for an empty field
Fictional planning example; illustrative fields and rules.
| Field | Incoming value | Existing destination | Normalized candidate |
|---|---|---|---|
| record_key → crm_record_id | " R-001 " | "R-001" | "R-001" |
| company_name → account_name | " Example Company " | "Example Company" | "Example Company" |
| department → department | " sales " | null | "Sales" |
Assume the ID matches exactly one account and occurs once in the incoming file. The name is unchanged. Under approved Mapping v1, the department candidate can fill the empty field.
Exact proposed record: crm_record_id="R-001"; account_name="Example Company"; department="Sales".
Keep a decision record with old department null, proposed department Sales, rule Mapping v1, and the actual approver. Until approval is recorded, this remains a proposal.
Case B: preserve a value when the input is blank
Fictional planning example; illustrative fields and rules. Incoming: record_key="R-001"; company_name="Example Company"; department=" ". Existing: crm_record_id="R-001"; account_name="Example Company"; department="Marketing".
The ID resolves once. Trimming leaves a blank department. Exact retained record: crm_record_id="R-001"; account_name="Example Company"; department="Marketing". Log the field decision as skipped-empty. No clearing is proposed.
Case C: hold a conflicting field
Fictional planning example; illustrative fields and rules. Incoming: record_key="R-001"; company_name="Example Company"; department="sales". Existing: crm_record_id="R-001"; account_name="Example Company"; department="Marketing".
The candidate is Sales, but Mapping v1 does not authorize replacing Marketing. Exact retained record: crm_record_id="R-001"; account_name="Example Company"; department="Marketing". Hold the department proposal Sales for the RevOps owner. Log both values and the conflict; do not silently overwrite.
Case D: hold a row without an identifier
Fictional planning example; illustrative fields and rules. Incoming: record_key=""; company_name="Example Company"; department="sales". The intended existing record is unknown because no valid lookup key is supplied.
Expected result: hold the entire row for the CRM administrator, with no proposed write. The name and department do not substitute for an ID. If two incoming rows instead carry R-001, hold both for duplicate resolution before an import. Duplicate input does not authorize deleting CRM records.
4. Decide what blanks and conflicts mean
Treat these states separately in your own rules:
Blank:
the source cell is missing or contains no text after the defined trimming step. In Mapping v1, preserve the destination value.
Unknown:
the source has a label you cannot interpret, such as an unmapped department. Hold it for review instead of guessing.
Invalid:
a candidate fails a required check, such as an ID that resolves to no record. Apply the documented field or row hold.
Explicitly cleared:
someone intentionally requests removal of a value. Handle this through a separate clearing request with the record ID, target field, current value, reason and recorded approval. A blank cell never means delete in this example.
For conflicts, identify who can decide which source takes precedence and what evidence they need. A newer file date alone should not become an overwrite policy without agreement. Record whether a decision applies to one field, one row or the entire batch.
5. Validate before approving updates
Review a small, controlled set of proposed changes before a broader import. Include unchanged records and exceptions as well as rows that appear ready to update.
- 01Check identity. Confirm the record type, exact ID lookup and unique match. Check repeated IDs in the incoming file before evaluating field updates.
- 02Check types and meanings. A text column may still contain the wrong kind of value. Confirm each destination definition, required length and accepted format against your system.
- 03Check transformations and allowed values. Reproduce each step from the original input. Confirm that unfamiliar dictionary values are held rather than discarded or guessed.
- 04Check empty and conflicting inputs. Re-run all four cases above using your own approved rules. Add an explicit-clearing case through its separate approval path.
- 05Compare proposed and retained values. Review the before/after record and confirm the number of changed fields. Every skipped or held value needs a reason.
- 06Confirm import behavior. In an appropriate test environment, verify how your system handles blank cells, held rows and rejected values. Confirm a recovery procedure before approving broader updates.
These checks test the mapping decisions. Passing a format or syntax check does not prove identity, email deliverability, data accuracy or permission to use the data. Review the relevant evidence separately for your intended use.
6. Assign ownership and keep the decision log
Name who proposes the mapping, who approves the rules, who runs the import and who resolves exceptions. One person may hold more than one operational role, but approval responsibilities should be explicit before work begins.
Keep the source reference, record ID, target field, original input, transformed candidate, old value, proposed value, decision, reason, rule version, reviewer and decision time in the log. Record whether a proposal was actually applied; approval and execution are different events.
Fictional decision-log example; illustrative fields and rules:
| Case | Target | Old → candidate | Decision | Owner / rule |
|---|---|---|---|---|
| A | R-001 department | null → Sales | Proposed fill; await recorded approval | RevOps owner / Mapping v1 |
| B | R-001 department | Marketing → blank | skipped-empty; retain Marketing | RevOps owner / Mapping v1 |
| C | R-001 department | Marketing → Sales | Hold field; retain Marketing | RevOps owner / Mapping v1 |
| D | Unknown record | No valid ID | Hold row; no proposed write | CRM administrator / Mapping v1 |
Before an import, retain an appropriate restricted-access snapshot of the affected values and agree on a recovery procedure for your CRM. Afterward, compare actual changes with approved proposals and route unexpected results to the named owner. Keep real records out of public worksheets and examples.
7. Discuss your mapping requirements
Bring your record types, source and target definitions, blank rules, conflict policy and unresolved questions to the conversation. That makes the requirements easier to discuss without assuming which fields or delivery methods are available.