CRM Field Mapping Validation Checklist

Map meaning, not just matching field names

Begin at the integration input, after the source has produced a record. This checklist is about destination write correctness, not the design of a customer-facing form or lead qualification. Ask the business owner to define each destination field in ordinary language before matching names. A source label such as “status” is not enough to decide whether it belongs in an inquiry category, service stage or account state.

Recommended approach: create one approved register row per mapping and separate create behavior from update behavior. Name the source field, destination field and business meaning explicitly. If two fields look similar but represent different decisions, leave the mapping unresolved rather than forcing a match. Record transformations as rules that another reviewer can reproduce, not notes such as “clean up as needed.”

OWASP distinguishes syntactic validation—whether a structured field has the correct format—from semantic validation—whether the value is correct in its business context. Use both questions in the mapping review: does the value have the expected type or format, and is that value allowed here? OWASP Input Validation Cheat Sheet.

Separate required, absent, empty and null values

In JSON Schema, defining properties alone does not make them required; the official object reference explains that leaving properties out is valid by default and describes the separate required keyword. A field's presence rule and its value/type rule answer different questions. A supplied value can still be the wrong type. JSON Schema: object properties and required properties.

An absent property is not the same as an explicit JSON null. The official null reference makes that distinction. An empty string is another explicit value: it supplies text with no characters, rather than omitting the property. These distinctions do not establish how your CRM interprets a write. JSON Schema: null.

• Absent: the source field is not supplied. Recommended update policy: preserve a populated destination unless an explicitly approved rule says otherwise.
• Empty string: the source explicitly supplies an empty text value. Decide whether to reject, hold or allow a deliberate clear; do not automatically convert it into permission to erase data.
• Null: the source explicitly supplies null. Verify the destination's documented semantics before writing; do not assume null always deletes, always preserves or is always accepted.
• Required: state when the field must be present, then separately state which values and types are acceptable. “Required on creation” need not mean “required on every update.”

The register below is an editorial planning tool, not a claim that any CRM uses JSON Schema. The actual source and destination contracts determine supported types, clearing behavior and conditional rules. Unverified semantics are a reason to hold the mapping, not an invitation to guess.

Validate allowed values and business rules before a CRM write

OWASP recommends validating external data as early as possible in the flow, preferably when it is received. Apply that guidance here by reviewing the incoming field against its approved mapping before allowing a destination write. OWASP: Goals of Input Validation.

Recommended controls: define allowed category values, numeric ranges where relevant, and the exact transformation for each accepted input. If a source introduces an unknown category, hold it for review rather than silently defaulting to a meaningful business state. A convenient default can conceal the fact that no approved mapping exists.

Review overwrite authority separately from validity. A perfectly valid incoming value does not by itself establish permission to replace a populated destination field. Specify whether the source owns the field, whether updates are permitted and whether a deliberate clearing request needs separate evidence. Use before-and-after destination read-back to verify the agreed outcome.

Define owner, rejection and correction paths

Assign one owner to each mapping or closely related field group. Name the review destination for unmapped values and a correction path that preserves the original synthetic input and the reason it was rejected. The reviewer should be able to tell whether a failure came from a missing value, an unexpected type, an unknown business category or an unapproved overwrite.

After a source field is renamed or added, compare the new input shape with the approved register. Do not route an unfamiliar field into a similarly named destination just to keep writes moving. Record the mapping revision, rerun affected cases and obtain the owner's decision before enabling that change.

Keep this review separate from record deduplication and transport recovery. The duplicate-actions guide covers repeated effects; the question here is whether the fields in a single intended write are correct.

Copyable field mapping register

Copy this record into your review document. Replace illustrative values with approved requirements; leave unresolved decisions visible. This page does not submit or store worksheet data.

Worked synthetic mapping row: this example maps a requested service category, not a sales stage. Its values are illustrative business choices, not a destination API specification.

The register has fourteen columns. On a narrow screen, focus the table region and use the arrow keys to scroll horizontally, or read the same row as labeled cards immediately below.

Same worked row, field by field

source field

inquiry_kind

business meaning

The requested service category, not sales stage or account status.

destination field

service_category

expected type

String from the approved category list.

required condition

Required for this illustrative create operation; updates follow a separately approved rule.

allowed values/range

For this synthetic example only: repair or inspection.

transformation rule

Map repair to Repair and inspection to Inspection; hold other values.

absent policy

Hold creation; preserve existing value on an update pending review.

empty-string policy

Hold; do not clear an existing category.

null policy

Hold until destination semantics and clearing authority are verified.

overwrite authority

No clearing or replacement of a populated value without the field owner's approved update rule.

rejection/review destination

Named mapping review queue; record field, rule and reason.

owner

Assigned CRM operations reviewer, to be named before use.

sample expected destination value

Input repair produces destination Repair; verify by destination read-back.

Eight synthetic acceptance tests

These are recommended test specifications, not completed tests or customer results. Use an approved non-sending test environment and synthetic records. Capture expected and observed outcomes separately, and keep the reviewer and test date with the evidence.

Require destination evidence before enabling writes

Run the matrix with synthetic records in an approved test destination, not real leads. Capture the initial destination values, expected disposition, observed disposition and final read-back. For a held or rejected input, verify the destination remains unchanged; a rejection message alone does not prove that no field was cleared.

Stop when a field's business meaning, absent/empty/null behavior, allowed values or overwrite authority is unresolved. Also stop if a successful response disagrees with read-back, or if an unknown source field is silently repurposed. Keep failed evidence and repeat the affected tests after a correction instead of changing the expected result to fit the implementation. These recommendations do not describe verified AI-Q product behavior.

Sources and scope

Public source material reviewed September 15, 2026. Standards and third-party guidance support the scoped explanations above; they do not identify AI-Q suppliers or establish a particular implementation.

• JSON Schema: null
• JSON Schema: object
• OWASP Input Validation Cheat Sheet