Implementation model

CRM-ready form data model: fields, scores, routing and attribution

A reusable CRM-ready form schema for identity, qualification, routing, consent context and campaign attribution, with field types and update rules.

Written and reviewed by The Form ReviewPublished August 11, 2026 · Fact-checked August 11, 2026 · 10 min read

Direct answer

A form is CRM-ready when every submitted value has a stable field name, data type, allowed values, source of truth and update rule. The minimum model should separate identity, qualification, attribution, consent context, workflow state and immutable submission evidence instead of copying every answer into an unstructured note.

Evidence basis

A reusable 24-field schema and mapping checklist derived from current CRM property, unique-identifier, deduplication, hidden-field, lifecycle-stage and campaign-tagging documentation.

About the author Editorial policy Corrections

Key findings

Identity fields, submission evidence and current CRM state solve different jobs and should not overwrite one another.
Controlled option values are safer than free text for routing, segmentation and reporting.
Attribution needs both the captured campaign values and the landing-page or form context that explains where the submission occurred.

The six data layers

A CRM-ready form should not treat every answer as the same kind of data. Separate values by purpose so a later submission can update current information without destroying the evidence of what happened at an earlier moment.

Six layers in a CRM-ready form model
Layer	Purpose	Example
Identity	Match or create the correct person and company	Work email, external contact ID, company domain
Profile	Describe relatively stable characteristics	Role, company size, country, primary use case
Qualification	Record the current evaluation	Fit score, readiness band, disqualifier, outcome
Attribution	Preserve how this submission arrived	UTM source, medium, campaign, landing page, form ID
Consent context	Record what was presented and selected	Consent flag, statement version, captured timestamp
Workflow evidence	Explain what the system did	Submission ID, route, owner, automation status, error code

Identity and current CRM state belong on the contact or lead. Immutable submission evidence belongs in a submission, activity or related record whenever the CRM supports that separation.

Reusable CRM field dictionary

The template below is deliberately vendor-neutral. Use stable internal names, controlled values and ISO-style timestamps. Do not rename internal keys each time the visible question copy changes.

Minimum CRM-ready form schema
Internal field	Type	Write policy	Why it exists
contact_email	Email	Match, then update if valid	Primary person identifier in many marketing CRMs
external_contact_id	Text, unique	Never overwrite once assigned	Stable cross-system identifier when email changes
company_domain	Text	Normalize to lower case	Company match and association candidate
first_name	Text	Update when submitted value is non-empty	Personalization and review
last_name	Text	Update when submitted value is non-empty	Personalization and review
role_function	Single select	Replace from approved values	Segmentation and routing
company_size_band	Single select	Replace from approved bands	Fit and routing without false numeric precision
primary_use_case	Single select	Replace from approved values	Need-based segmentation
fit_score	Number	Replace on each completed assessment	Comparable current qualification result
readiness_band	Single select	Derived from current score	Explainable high, medium or low route
qualification_outcome	Single select	Replace on each completed flow	Named result used by follow-up
disqualifier_code	Single select	Blank or one controlled reason	Auditable hard-rule result
utm_source	Text	Write to submission; preserve first and latest separately if needed	Campaign source
utm_medium	Text	Same policy as source	Campaign medium
utm_campaign	Text	Same policy as source	Campaign name
landing_page_url	URL	Write per submission	Page context before the form began
form_id	Text	Write per submission	Canonical form or funnel identifier
form_version	Text	Write per submission	Connect the result to the rules shown at that time
consent_selected	Boolean	Write per submission	Records the captured choice
consent_text_version	Text	Write per submission	Identifies the statement presented
submitted_at	Date-time	Write once	Canonical event time
submission_id	Text, unique	Write once	Idempotency and troubleshooting key
route_code	Single select	Write per submission	Owner or workflow route selected
automation_status	Single select	Update by workflow	Pending, succeeded, failed or repaired

Write, update and deduplication rules

Field names alone do not make a reliable model. Every destination needs an explicit rule for matching, overwriting and preserving history.

Choose the primary identifier.Email is common for contacts, but a system-generated external ID is safer when the same person may change email addresses.
Normalize before matching.Trim spaces, lower-case emails and domains, standardize country or region values and reject impossible formats.
Make repeat submissions idempotent.A unique submission ID should prevent a retry from creating a second activity or firing the same follow-up twice.
Separate first, latest and current values.First-touch attribution, latest-touch attribution and the contact's current profile should not compete for one field.
Preserve controlled vocabularies.Use internal option values such as high, medium and low even when the form displays friendlier labels.
Record failures.An unmapped option or duplicate-rule block should create an exception state, not silently discard the submission.

HubSpot documents automatic contact deduplication by email and company deduplication by domain. Salesforce documents lead-field mapping during conversion and duplicate rules that can block Web-to-Lead records. These behaviors show why the matching and failure policy must be designed before connecting the form.

The CRM mapping test

Test the mapping with scenarios that reveal overwrite, duplication and attribution failures. A single successful new-contact submission is not enough.

CRM mapping test cases
Test case	Expected record behavior	Failure to watch for
New person, new company	Create the contact, associate or create the company, add one submission activity	Company text stored without a usable domain or association
Existing person, changed role	Update the approved profile field and keep earlier submission evidence	A second contact is created or history is overwritten
Same submission retried	Reuse the submission ID and avoid duplicate actions	Two records, notifications or nurture enrollments
Known person, new campaign	Preserve first-touch values and write latest-touch or submission attribution	Original attribution is overwritten
Unknown option value	Route to an exception queue with the original value	The value is dropped or forced into the wrong category
Automation unavailable	Keep the record and mark the workflow failed for repair	The contact exists but nobody knows follow-up failed

Use a low, medium and high score path from the lead qualification guide, then confirm the downstream behavior with the post-submission checklist.

Implementation order

Freeze the decision outcomes and routing codes before creating fields.
Reuse destination CRM properties where their definition already matches.
Create the remaining fields with internal names, types and allowed values.
Map visible answers, derived scores and hidden attribution values separately.
Set match, overwrite, append and error rules for each field.
Run the six mapping tests and inspect the contact, company, activity and automation result.
Save the field dictionary beside the workflow so later edits use the same contract.

Reader next step

Copy the field dictionary into a spreadsheet with five extra columns: visible question, destination object, destination field, transformation rule and test result. Then run the HubSpot Forms decision guide or the same mapping exercise against your chosen CRM.

Evidence and limitations

Evidence used

A reusable 24-field schema and mapping checklist derived from current CRM property, unique-identifier, deduplication, hidden-field, lifecycle-stage and campaign-tagging documentation.

What this does not prove

The schema is vendor-neutral and must be adapted to the destination CRM's objects, field limits and permissions.
The consent fields preserve context for review; they do not determine whether a collection or marketing activity is legally valid.

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 August 11, 2026.