Test Boolean and Picklist Import Mappings

Map booleans and picklists without turning unknowns into false values, test rejected options, and keep ambiguous source categories in a review queue.

10/23/20263 min read

A fictional mapping keeps negatives, unknowns and blanks distinct and reviews picklist meanings.
A fictional mapping keeps negatives, unknowns and blanks distinct and reviews picklist meanings.

A source column marked active can contain Yes, Y, 1, TRUE, blank, and “not reviewed”. Those values may look interchangeable to a hurried reviewer, but they do not necessarily describe the same state. Importing them into a boolean property can convert uncertainty into a definite answer. Picklists create a related problem when a familiar label maps to the wrong internal option.

Start with a mapping table owned by someone who understands the business meaning. The importer can enforce its accepted syntax, but it cannot decide whether “unknown” should become false or whether an old category still exists.

Name every state you intend to preserve

A true boolean represents two states. If the source needs yes, no, and unknown, decide whether the destination supports a separate unknown state, an unset value with defined semantics, or an additional review field. Do not force uncertainty into no merely because a report expects a complete column.

Picklists need both the source vocabulary and the destination's accepted labels or internal values. HubSpot's formatting guidance explains that enumeration values must match the supported option representations. Verify the current property configuration: a renamed visible label may coexist with an older internal value, and two properties can use similar labels for different purposes.

Write down whether blanks preserve an existing value or intentionally clear it. That decision belongs in the import contract, not in an operator's memory.

Fill in a fictional mapping table

Consider a synthetic supplier-research dataset with two fields: site_verified and service_region. The destination has a reviewed boolean for the first and approved region options for the second. The following is the working artifact, expressed as mapping rows.

  • site_verified, source “confirmed”: map to true; evidence required is a completed site check.

  • site_verified, source “checked and absent”: map to false; this describes an actual negative finding.

  • site_verified, source “not checked”: do not map to false; quarantine or route to the agreed unknown representation.

  • site_verified, source blank: preserve the existing value in this fictional update-only workflow.

  • service_region, source “Northern”: map to the documented North option after the business owner confirms equivalence.

  • service_region, source “North and East”: reject from a single-choice field; investigate whether the destination model should allow multiple values.

  • service_region, source “N/E”: quarantine because the abbreviation is ambiguous.

Include the reviewer, configuration date, and reason for every nonliteral mapping. A table that merely lists input and output strings loses the business decision that justified them.

Test accepted and rejected values together

Prepare synthetic rows covering every approved mapping and every rejection. For existing-record tests, give the destination a known starting value. That makes it possible to see whether a blank preserves, clears, or replaces it. For new-record tests, check how missing required properties behave.

Import the small fixture through the same route intended for production. Compare each property independently rather than checking only whether the record exists. HubSpot's import-error guidance distinguishes failures affecting a row from failures affecting a property, so an accepted record may still be missing the classification you expected.

Re-export the test records and compare the stored options with the mapping table. Check any downstream report or routing condition that depends on them. A readable label in the interface is not enough if an integration consumes a different internal value.

Resolve a failed category without broadening it

Suppose “North and East” is rejected in the illustrative pilot. Mapping it to North would eliminate an error but discard part of the source meaning. The steward should either obtain a justified single-region decision, adopt a supported multi-value model through an approved schema change, or leave the row outside this import.

Likewise, do not create new picklist options automatically from every unfamiliar string. Typographical variants would become permanent categories, and an unexpected value could begin triggering workflows nobody reviewed. Quarantine should record the original value, affected field, proposed decision, and owner.

Release the mapping only after unknowns remain unknown, deliberate negatives remain distinguishable, and every accepted option leads to the expected downstream behavior. Version the approved table. A later label change, new region, or different import tool requires a focused retest rather than an assumption that yesterday's mapping still applies.

If you are also choosing research access, ask about Leads Automation’s independent Sales Navigator offer at US$15/month on WhatsApp. Confirm the available plan, eligibility and terms before ordering; this is not LinkedIn’s official price or an assurance that any particular integration is included.

Sources and scope

Related guides