CRM mapping and integration checklist

Form-to-CRM field mapping checklist

Map form fields into CRM properties with a nine-field contract, transform and overwrite matrix, worked consultation map and nine-case proof test.

Written and reviewed by The Form ReviewPublished October 7, 2026 at 12:44 PM EDT · Fact-checked October 7, 2026 at 12:44 PM EDT · 10 min read

Direct answer

A field map is a versioned contract between one submitted value and one CRM destination, not a list of similar-looking labels. Define the source key, destination object and property, type, transform, null behavior, write policy and provenance before sending production records.

Evidence basis

A nine-field source-to-target mapping contract, transform and overwrite matrix, worked consultation-form map and reproducible nine-case proof test, checked against current Salesforce Help and REST API documentation on October 7, 2026.

About the author Editorial policy Corrections

Key findings

Labels are presentation; a reliable integration maps stable source keys to stable destination object and property names under a named version.
Missing, blank and explicit-clear values are different states. Each field needs a null policy and a write policy before production data is sent.
Record identity, field transformation and downstream routing are separate controls; a correct field map cannot compensate for an ambiguous contact match or an unsafe retry.

Stable definition and boundary

Form-to-CRM field mapping specifies how one submitted value becomes data on a named CRM object and property. It is narrower than the wider CRM data model and separate from lead routing: mapping preserves meaning, while routing decides which person, queue or workflow should act next.

Direct answer

Visible labels can change for clarity or localization. Stable source keys and destination API names should not change silently with them. Store the map version with the submission or delivery event so a later investigation can reconstruct which contract was applied.

Nine-field mapping contract

Minimum source-to-target mapping contract
Contract field	Required question
`source_key`	Which stable form key produced the value?
`source_version`	Under which form and mapping contract was it collected?
`target_object`	Does the value belong on a contact, company, deal or activity?
`target_property`	Which stable destination API name receives it?
`value_type`	Is the accepted value text, number, date, Boolean or enumeration?
`transform`	Must the value be trimmed, normalized, translated or derived?
`null_policy`	Does missing, blank or explicit clear mean ignore, clear, default or reject?
`write_policy`	May the write create, replace, append or require review?
`provenance`	Which submission, rule version, actor and time explain the write?

Keep the contract beside the integration configuration and its proof-test results. A screenshot of two matching labels is not enough because labels do not establish type, allowed values, object ownership, overwrite behavior or failure handling.

Transform and overwrite matrix

Transform and write rules by source state
Source state	Transform rule	Write rule
Validated controlled value	Translate the form value to the destination enumeration	Replace only under the field's named authority policy
Validated free text	Trim and enforce the documented length; preserve meaning	Store on the submission or activity unless it is truly a durable profile fact
Valid date or number	Parse against one stated format and range	Reject malformed input rather than inventing a plausible value
Missing optional key	No transform	Do not write
Present but blank	Classify separately from missing	Ignore, reject or clear only according to the explicit null policy
Explicit correction	Validate the corrected value and correction authority	Replace the stale value while retaining provenance
Unknown enumeration	Do not silently coerce to a nearby label	Quarantine or route to review
Lower-authority enrichment	Normalize but retain its source and confidence	Do not overwrite direct, verified evidence automatically

Missing, blank and explicit clear are different states. Treating all three as an empty string can erase trustworthy data or make a requested correction impossible. Define that distinction for each destination field before the first production write.

Worked consultation-form map

A consultation form collects work email, company domain, team-size band, goals, phone and a qualification outcome. The implementation uses email only as the tested contact match key, normalizes the company domain before company matching, maps team size to a controlled CRM enumeration and stores free-text goals on the submission activity rather than treating them as a permanent contact property.

Illustrative form-to-CRM mapping
Form source	CRM destination	Transform and write policy
`work_email`	Contact.email	Lowercase the domain; reject invalid syntax; use the documented identity policy
`company_domain`	Company.domain	Normalize host; match or create only under the company identity rule
`team_size_band`	Contact.team_size_band	Translate stable values such as 1_10 or 11_50; reject unknown values
`primary_goals`	Submission activity	Trim and length-check; append as event context rather than overwriting profile data
`phone`	Contact.phone	Ignore missing or blank; replace only after a valid respondent-supplied value or correction
`qualification_status`	Contact.qualification_status	Write the derived state with the named rule version and reason codes

A blank phone does not erase an existing verified number. An explicit request to remove the number follows the correction path and records what was cleared, why and when. Qualification status remains a derived, versioned decision; it does not rewrite the original answers that produced it.

Identity and delivery boundaries

Resolve the intended record before applying field writes. A perfect transform can still corrupt data if it targets the wrong contact. Use an explicit record key or documented match rule, stop on ambiguous matches and keep submission idempotency separate from contact deduplication.

Delivery also needs observable states: accepted, rejected, quarantined and retryable. A timeout does not prove that the destination made no write, so replay must carry an idempotency key or perform a safe read-before-write check. Use the webhook reliability checklist for receipt, retry and replay controls, and the duplicate-control model for submission and contact identity.

Current source boundary

As checked October 7, 2026, Salesforce's current Data Import Wizard guidance treats each row as a record and each column as a field, recommends matching with Salesforce ID as a unique identifier and warns that editing certain identity fields can create duplicates. It also states that an empty import value does not automatically clear existing field data.

The current Salesforce REST API guide for sObject Rows distinguishes record selection from field updates and says provided field values replace existing values when a record is updated. These product-specific behaviors illustrate why identity, included fields and null semantics must be tested; they are not universal promises for every CRM or connector.

Exact objects, API names, validation rules, permissions, rate limits and retry behavior vary by destination and account. Inspect the actual schema and run the proof test against a non-production record before enabling production writes.

Nine-case field-mapping proof test

Valid complete submission:every intended value reaches the named object and property with the documented type.
Missing optional value:the destination field is untouched and the write result remains observable.
Explicit clear:only an authorized correction path clears the intended field and records provenance.
Unknown enumeration:the value is rejected or quarantined instead of becoming a misleading fallback.
Malformed date or number:the write fails visibly; no plausible but incorrect value is invented.
Duplicate submission:replay cannot append the same activity or repeat a downstream action.
Changed form version:the new source contract uses the intended mapping version while older evidence stays interpretable.
Existing higher-authority value:the lower-authority source cannot overwrite verified data without review.
Destination outage and retry:failure is visible, retry is bounded and the final state contains one intended write.

Pass condition

Types and controlled values stay stable; missing, blank and clear follow their separate policies; the intended record is unambiguous; failed writes are observable; replay cannot duplicate activity; and every accepted value can be traced to its source, contract version and time.

Record the synthetic inputs, destination record IDs, observed writes and failure evidence in the end-to-end form testing checklist. Repeat the mapping proof test after changing fields, labels, objects, validation rules, identity logic, connector permissions or retry behavior.

Evidence and limitations

Evidence used

What this does not prove

This is a mapping and QA framework, not a complete integration architecture, identity-resolution policy, data migration plan or legal assessment.
CRM objects, field types, validation rules, permissions and write semantics vary by destination and account configuration; verify the actual schema and credentials.
The worked map is illustrative, not evidence that a particular CRM or connector implements these policies automatically.

Sources and verification

Current product and plan claims use the primary sources below. Internal methodology links describe the publication's own frameworks and should not be read as vendor documentation.

Last materially verified October 7, 2026 at 12:44 PM EDT.