Field mapping is the set of rules that says which field in one system feeds which field in another: the “Postcode” box on your website form goes into the “Postal code” field in your CRM, the “Phone” answer from a Facebook lead form goes into “Mobile”, and so on. Whenever data moves between two tools, field mapping decides whether it arrives in the right place, in the right format.
How field mapping works
Every system stores data in named fields with a type: text, number, date, drop-down list, tick box. When you connect two systems, through a native integration, a webhook or a connector tool, you pair the fields up. Some pairs are obvious (email to email). Others need a decision:
- Splitting and joining. A form with a single “Full name” field has to be split into first and last name for a CRM that stores them separately.
- Value translation. A lead form answer of “Within 3 months” may need to become “Warm” in a CRM drop-down that uses different labels.
- Defaults. When a field is empty, the mapping decides whether to leave it blank, use a default or skip the record.
- Direction. In a two-way sync, the mapping also decides which system wins when both have changed the same field.
Fields that do not exist in the destination need creating first, usually as custom fields. Anything left unmapped is silently dropped.
Why it matters
Bad mapping causes problems that are slow to notice and expensive to fix. A lead from a Meta instant form arrives in the CRM without a phone number because the form called it “phone_number” and the integration expected “phone”. Sales never calls. Weeks later, someone asks why the campaign produced no customers.
UK formats cause their own trouble. Postcodes need to keep their space (“SW1A 1AA”) and be stored in a field long enough to hold them. Many UK addresses have no county, so a mandatory county field either blocks the record or fills with junk. Phone numbers arrive as 07…, +44 7… or 447…, and a number field may strip the leading zero entirely. Pick one format, ideally the international +44 form, and convert everything to it on the way in.
Consent is the most important field to get right. Under PECR, you need to know who agreed to marketing, when and through which form. If the consent tick box is not mapped, or is mapped into a general notes field, that permission is lost the moment the data syncs. Store marketing consent in its own fields, with the date and source, so an opt-in or an opt-out survives every transfer.
Common mistakes
- Mapping once and forgetting. When someone edits a form question or renames a CRM field, the mapping breaks quietly.
- Free text where a list belongs. Mapping a drop-down answer into a free text field makes reporting and segmentation unreliable.
- Losing the source. Not mapping UTM or campaign fields means you cannot tell which ad produced which lead.
- Overwriting good data. A sync that writes blank values over existing ones wipes information a salesperson typed in.
- No test record. Going live without sending a test lead through every field and checking it at the other end.
How to act on it
Write the mapping down in a simple table with four columns: source field, destination field, format or transformation, and owner. Include consent, lead source and campaign fields, not just contact details. Submit a test lead with realistic UK data, including a postcode, a mobile number in a different format and a consent tick, and check each value at the other end. Repeat the test whenever a form or field changes.
When I set up lead generation ads on Facebook and Instagram, checking that every form field reaches the CRM correctly is one of the first jobs, because a lead that lands without a phone number is a lead paid for twice.