Field Mapping Guide for a Business Card Scanner

January 14, 2026

Your scanner reads fields. Your CRM stores fields. Your field mapping is how the two talk. Here’s how to set it up so that every scan lands in the right place first time.

What gets read from the card

Your scanner’s field detection recognises standard business card content:

  • Name (full, first, last, middle initial)
  • Job title
  • Company
  • Email (multiple if present)
  • Phone numbers (office, mobile, fax)
  • Website
  • Address (street, city, region, postcode, country)
  • Social handles (LinkedIn, Twitter)

Your scanner also handles anything printed on the card as free-form text, which your mapping can pick up for specific custom fields.

Mapping to CRM standard fields

Your CRM’s standard Contact or Lead object has a known set of fields. Your scanner’s mapping defaults to the obvious pairs, FirstName to FirstName, Email to Email, and so on.

Your admin can override per-CRM if your org uses non-standard conventions.

Mapping to custom fields

Your CRM has custom fields specific to your business: Territory, Product Interest, Partner Type, Industry Segment. Your scanner can populate these too.

Your sources for custom-field values are: direct card content, qualifying question answers, Campaign defaults, territory rules based on address.

From card content

Your Industry custom field gets populated from the job title or company name via a simple regex or lookup table.

From qualifying answers

Your Product Interest field gets set by the answer to the qualifying question you asked on the stand.

From Campaign defaults

Your Source field gets a fixed value (“Exhibition 2026”) for every scan from a specific event.

Object chains: Contact, Account, Opportunity

Your scan doesn’t just create one record. Your mapping can chain: create Account by company name, create Contact linked to the Account, create Opportunity linked to the Contact with a starting amount.

Your CRM admin defines the chain once. Every scan follows it.

Validation rules and picklist enforcement

Your CRM probably has required fields, validation rules and picklist values your mapping has to respect. Your scanner enforces them all, at scan time, with clear error messages, not after the record has been created.

Your rep fixes the issue on the spot (change the picklist value, add the missing field) and saves. No records get created that your CRM would reject later.