- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
A mapping decision applies to every record that follows it and is almost never revisited, so a field mapped wrongly in April is wrong in ten thousand rows by November.
How to do field mapping without corrupting the data you already have
Field mapping is deciding which piece of incoming data goes into which field on the record. It sounds like a clerical step and it is the point at which most data problems are created, because a mapping decision is applied to every record that follows it and is almost never revisited. A field mapped wrongly in April is still wrong in November, and by then it is wrong in ten thousand rows.
The mapping itself takes minutes. What follows is the set of decisions around it that determine whether the result is usable.
Map to what the field means, not to what it is called
Two fields with the same name in different systems frequently hold different things. One system’s “phone” is a mobile; another’s is a main switchboard line. One’s “company” is a free-text string the customer typed; another’s is a reference to a company record. Mapping by name is fast and produces a database where a filter returns a mixture.
Before mapping, write down what the destination field is for in one sentence. If the incoming data does not match that sentence, it needs a different field, not a looser interpretation of this one. Where a business rather than a person is the real entity, company records and their traps and associating records are the structures to map into rather than flattening everything onto a contact.
The four things that go wrong
| Problem | What it looks like | Prevention |
|---|---|---|
| Value against label | A field holding a code rather than readable text | Decide which the mapping carries — see below |
| Blank overwrite | A good value replaced by an empty one | Map to fill, never to replace, unless intended |
| Type mismatch | Dates, phone formats and numbers stored as text | Normalise on the way in, not in every report after |
| Vocabulary drift | Two sources writing different words to one field | A shared list of allowed values |
The first is the one that surprises people most. A dropdown usually has a label shown to the person and a value stored underneath, and a mapping normally carries the value. dropdown options, values and routing is where that is decided, and the fix is to make the stored values readable rather than to translate them later in every report and filter.
Blank is not a value, unless you decide it is
The most damaging mapping error is the silent overwrite. A short form collecting three fields, mapped to a record holding fifteen, can blank the other twelve if the mapping treats absent as empty rather than as absent. The record looks fine to whoever submitted the form and has quietly lost its history.
Prefer a rule that fills empty destination fields and leaves populated ones alone, and make exceptions deliberately for fields that genuinely should be updated — a current phone number, a latest status. This interacts directly with conditional fields that behave: a conditional question that was never displayed arrives empty, and without the rule that emptiness overwrites something real. splitting a form across steps raises the same issue whenever a person completes only the first step.
Normalise once, at the boundary
Phone numbers arrive with spaces, brackets and country codes in varying combinations; dates arrive in at least three orders; names arrive with inconsistent capitalisation. Fixing that at the point of entry is one piece of work. Leaving it produces a field that cannot be matched, deduplicated or sorted, and every later query has to compensate.
where to enforce required fields is the related control: a field that must be present should be enforced where it is collected rather than checked afterwards. Both are upstream versions of keeping the contact database usable, and the reason that article keeps pointing back to intake.
Mapping across an integration
When the data arrives from another system rather than from your own form, two extra questions apply. What is the stable identifier that says two records are the same person, and what happens when a field exists on one side and not the other?
reading a webhook payload is where you can see exactly what is being sent, which is the only reliable basis for a mapping — a field list from documentation and the payload in practice are not always the same. building an integration without code handles much of this for you at the cost of some control, and getting API access safely is the route when you need the control back. Either way, map from a real payload rather than from an assumption.
Custom fields: fewer than you want
Every custom field is something that has to be mapped, maintained and understood by whoever comes next. It is tempting to create one per question, which produces a record with sixty fields, most of them empty and none of them used in a filter.
Create a custom field when something will be filtered, reported on, or used in an automation. Everything else belongs in the submission record, which keeps it readable without adding a column to the whole database. pipeline stages and exit criteria is a good test: if a field does not help move a record between stages or explain why it is stuck, it probably does not need to be a field.
Test the mapping before it runs on everything
- Submit one record with every field populated and open the result.
- Submit one with the optional fields left out and confirm nothing was overwritten.
- Submit one where a conditional question was skipped.
- Submit one containing an apostrophe, an accent and a long value.
- Confirm each mapped field shows readable text rather than a code.
- Run an import of ten rows before running one of ten thousand.
Then write the mapping down — a log kept outside the platform is enough — with the destination field, the source, and the one-sentence description of what the field means. Six months later that document is what stops somebody mapping a second source into the same field with a different vocabulary, and it is what makes creating an opportunity from a survey predictable rather than a surprise every time a new form is added.
Frequently Asked Questions
What is field mapping?
Deciding which piece of incoming data goes into which field on the record. It looks clerical and it is where most data problems originate, because the decision applies to every record that follows and is almost never revisited once made.
Should I map fields by name?
No — map by meaning. Two fields called phone in different systems can hold a mobile and a switchboard line, and mapping by name produces a database where a filter returns a mixture. Write down what the destination field is for before you map anything into it.
Why did my form submission blank out existing data?
Because the mapping treated an absent field as an empty value rather than as absent, so a short form overwrote fields it never collected. Prefer a rule that fills empty destination fields and leaves populated ones alone, with deliberate exceptions.
Why does my mapped field show a code instead of the answer?
A dropdown has a label shown to the person and a value stored underneath, and the mapping normally carries the value. The fix is to make the stored values readable rather than translating them in every report and filter afterwards.
Where should phone numbers and dates be normalised?
At the boundary, as the data arrives. Doing it once at entry is a single piece of work; leaving it produces a field that cannot be matched, deduplicated or sorted, and every query afterwards has to compensate for the inconsistency.
How many custom fields should I create?
Only for data that will be filtered, reported on, or used in an automation. Everything else can live in the submission record. A record with sixty fields, most empty and none used in a filter, is harder for the next person to work with than a short one.
How do I map fields coming from another system?
From a real payload rather than from documentation, because the two do not always agree. Decide the stable identifier that says two records are the same person, and decide explicitly what happens when a field exists on one side and not on the other.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.