ListMatchGenie

Field mapping

When source and master files have different column names, map them explicitly. This page covers the mapping UI, auto-detection, and how to handle tricky cases like concatenated or split fields.

For the match engine to compare two records, it needs to know which source column corresponds to which master column. When both files use the same column names (or very similar ones), the Genie auto-maps them. When names diverge, you map them explicitly on the Configure step.

Auto-mapping

The Genie auto-maps columns when:

  • Names are exactly identical across files (case-insensitive): email ↔ Email is a match.
  • Names are very close (token-level similarity, common variants): first_name ↔ FirstName, zip ↔ zipcode ↔ postal_code.
  • Column types agree — a column named zip detected as integer doesn't auto-map to a column named zip detected as string (type mismatch flagged).

When auto-mapping succeeds, you see a solid line between the columns in the mapping UI. When it's uncertain, you see a dashed line and a prompt to confirm.

Manual mapping

Click any column on either side to start a mapping. Then click its counterpart on the other side. A line appears connecting them. To remove, click the line.

Mapping is always bi-directional — map in either direction, the engine treats them symmetrically.

Which columns need to be mapped

Only comparable columns need mapping:

  • Identity columns (name, email, phone, ID) must be mapped for comparison.
  • Columns you don't want the engine to use don't need mapping — leave unmapped and they're excluded from scoring.
  • Columns you want to pull through to output (enrichment columns) don't need mapping either — they flow through automatically.

Common mapping scenarios

Renamed columns

Your source has E-mail Address and master has email. Map them explicitly.

Different column splits

Your source has a single full_name column; your master has first_name and last_name. Two options:

  1. Pre-split the source — use the cleanse step's "Split column" action to separate full_name into first_name and last_name, then map normally.
  2. Combine the master — similar, combine first_name and last_name in the master into a temporary full_name for matching.

Concatenated addresses

Source has address_1, address_2, city, state, zip. Master has a single full_address column. Either split the master via a cleanse rule, or combine the source fields into a concatenated one for matching.

Multiple possible identifiers

Source has both email and alt_email. Master has email. Two options:

  1. Map source email to master email (primary). Ignore alt_email.
  2. Create a unioned identifier column in cleanse — one column containing either email (whichever isn't empty). Map that to master's email.

One-to-many enrichment

Source has phone_home and phone_mobile. Master has phone. Map the strongest signal (mobile is usually more current) to master's phone; keep home as a pull-through column.

Type checks

When you map two columns, the engine checks type compatibility:

  • email ↔ email: ok
  • email ↔ free_text: warning, but allowed
  • integer ↔ string: warning; type coercion is applied
  • date ↔ phone: blocked; mapping refused

Type warnings appear as amber badges next to the mapping. Don't ignore them — they indicate the engine will compare these columns but with less confidence.

Saving mappings

Column mappings are saved as part of the match profile. If you're running the same source-to-master match regularly, save a custom profile with the mappings baked in — subsequent runs auto-apply.

Mapping for identifier profile

The Identifier profile uses a single identifier column for exact matching. On Configure, pick which source column is the identifier and which master column it maps to. Other columns stay in the file for output but don't participate in matching.

Mapping for dedupe profile

Contact dedupe mode matches a file against itself. No cross-file mapping needed — the Genie uses the file's own column profile.

Pitfalls

Wrong mapping produces silently bad results

If you accidentally map first_name ↔ last_name across files, every pair will score very low. The engine won't flag this as an error (the mapping is technically valid), so double-check the mapping UI before running.

Ignoring unmapped columns isn't always right

If an unmapped column carries strong identity signal (e.g. a system ID), excluding it from matching hurts results. Map every identity-relevant column.

Over-mapping hurts too

Mapping every column, including noisy ones (free-text notes, timestamps), adds noise to the composite score. Only map columns that legitimately represent the same information across files.