Value maps

Your file says Tech. The picklist says Technology. This step is where you say they are the same thing.

Two kinds of field need it: picklists, which accept a fixed set of options, and lookups, which point at another record.

Picklists

Every distinct value your file produces for a picklist field is listed, with what it maps to. Unmapped values are counted in the header so you can see at a glance which fields still need work.

Three things you can do with a value:

• Map it to one of the destination’s options.
• Leave it blank — an explicit choice, recorded like any other mapping.
• Leave it unmapped — which validation will block on, because a value that reaches the CRM and is not a valid option fails the row.

Leaving a value blank is a real answer

If your file’s Misc has no equivalent in the CRM’s list, mapping it to blank is more honest than inventing a category to park it in. The field is empty for those rows and you have said so on purpose.

It shows up on the Validate step as a warning with a row count — “will import EMPTY on 40 rows” — so a decision that affects forty rows does not pass unnoticed.

Values produced by a formula

A field mapped by formula still produces picklist values, and they are checked the same way. If your expression can emit something that is not a valid option, validation catches it here rather than at the row.

Lookups

A lookup field points at a record in another module. Your file has a name; the CRM needs an id.

Two ways to bridge that:

Map the values. Each distinct source value maps to a specific record. Right when the set is small and stable — a dozen owners, five regions. It is explicit and it does not change under you.

Use search mode instead. Map the field on the Map step with a search rule, and the record is found at run time by whatever value the row carries. Right when the set is large or changes often — every account in your CRM.

Validation nudges you towards search mode when a lookup has many unmapped values, because hand-mapping four hundred account names is not a good use of an afternoon.

Dates, numbers and text

These need no value map. They are converted by type, using your org’s settings:

• Dates — ambiguous numeric dates (03/04/2024) are read using the org’s date format setting, which is DMY, MDY or YMD. Set it once, under organisation settings, to match where your files come from. Unambiguous formats like 2024-03-17 are read as written.
• Numbers — parsed leniently. helpers.num() is available in expressions when you need to be explicit.
• Text — passed through. Over-long values are caught at validation against the field’s length.

If a specific column needs different handling, that is a formula on the Map step, not a value map.

Auto-mapping values

Each field offers a pass that maps the values it can match confidently — exact matches, and near-matches on case and spacing. It leaves the rest to you, on the same principle as field auto-mapping: an obvious gap beats a plausible mistake.

Asking the AI

Where AI is configured, value mapping proposes the rest. It is the step the free pass genuinely cannot do — Tech → Technology is within reach of string distance, Aus → Australia is not.

What comes back is split in two, deliberately:

• Applied — the model was confident and clearly ahead of its second choice.
• Offered — everything else, as candidates, best first, with nothing written until you pick one.

Every option it names is checked against the field’s real options before you see it, so it cannot propose a value the CRM would reject. See What the AI does.

Saving the work

Value maps are part of the project. Save the project and the mappings come back next time with the next month’s file, so Tech → Technology is a decision you make once rather than every month.

See Save and reuse a project.